draft-ietf-mpls-loss-delay-04.txt   rfc6374.txt 
MPLS D. Frost Internet Engineering Task Force (IETF) D. Frost
Internet-Draft S. Bryant Request for Comments: 6374 S. Bryant
Intended status: Standards Track Cisco Systems Category: Standards Track Cisco Systems
Expires: January 20, 2012 July 19, 2011 ISSN: 2070-1721 September 2011
Packet Loss and Delay Measurement for MPLS Networks Packet Loss and Delay Measurement for MPLS Networks
draft-ietf-mpls-loss-delay-04
Abstract Abstract
Many service provider service level agreements (SLAs) depend on the Many service provider service level agreements (SLAs) depend on the
ability to measure and monitor performance metrics for packet loss ability to measure and monitor performance metrics for packet loss
and one-way and two-way delay, as well as related metrics such as and one-way and two-way delay, as well as related metrics such as
delay variation and channel throughput. This measurement capability delay variation and channel throughput. This measurement capability
also provides operators with greater visibility into the performance also provides operators with greater visibility into the performance
characteristics of their networks, thereby facilitating planning, characteristics of their networks, thereby facilitating planning,
troubleshooting, and evaluation. This document specifies protocol troubleshooting, and network performance evaluation. This document
mechanisms to enable the efficient and accurate measurement of these specifies protocol mechanisms to enable the efficient and accurate
performance metrics in MPLS networks. measurement of these performance metrics in MPLS networks.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on January 20, 2012. 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/rfc6374.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 6 1.1. Applicability and Scope ....................................5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology ................................................6
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Requirements Language ......................................6
2.1. Basic Bidirectional Measurement . . . . . . . . . . . . . 6 2. Overview ........................................................6
2.2. Packet Loss Measurement . . . . . . . . . . . . . . . . . 8 2.1. Basic Bidirectional Measurement ............................6
2.3. Throughput Measurement . . . . . . . . . . . . . . . . . . 10 2.2. Packet Loss Measurement ....................................7
2.4. Delay Measurement . . . . . . . . . . . . . . . . . . . . 10 2.3. Throughput Measurement ....................................10
2.5. Delay Variation Measurement . . . . . . . . . . . . . . . 12 2.4. Delay Measurement .........................................10
2.6. Unidirectional Measurement . . . . . . . . . . . . . . . . 12 2.5. Delay Variation Measurement ...............................12
2.7. Dyadic Measurement . . . . . . . . . . . . . . . . . . . . 13 2.6. Unidirectional Measurement ................................12
2.8. Loopback Measurement . . . . . . . . . . . . . . . . . . . 13 2.7. Dyadic Measurement ........................................13
2.9. Measurement Considerations . . . . . . . . . . . . . . . . 14 2.8. Loopback Measurement ......................................13
2.9.1. Types of Channels . . . . . . . . . . . . . . . . . . 14 2.9. Measurement Considerations ................................14
2.9.2. Quality of Service . . . . . . . . . . . . . . . . . . 14 2.9.1. Types of Channels ..................................14
2.9.3. Measurement Point Location . . . . . . . . . . . . . . 14 2.9.2. Quality of Service .................................14
2.9.4. Equal Cost Multipath . . . . . . . . . . . . . . . . . 15 2.9.3. Measurement Point Location .........................14
2.9.5. Intermediate Nodes . . . . . . . . . . . . . . . . . . 15 2.9.4. Equal Cost Multipath ...............................15
2.9.6. Different Transmit and Receive Interfaces . . . . . . 15 2.9.5. Intermediate Nodes .................................15
2.9.7. External Post-Processing . . . . . . . . . . . . . . . 16 2.9.6. Different Transmit and Receive Interfaces ..........16
2.9.8. Loss Measurement Modes . . . . . . . . . . . . . . . . 16 2.9.7. External Post-Processing ...........................16
2.9.9. Loss Measurement Scope . . . . . . . . . . . . . . . . 18 2.9.8. Loss Measurement Modes .............................16
2.9.10. Delay Measurement Accuracy . . . . . . . . . . . . . . 18 2.9.9. Loss Measurement Scope .............................18
2.9.11. Delay Measurement Timestamp Format . . . . . . . . . . 18 2.9.10. Delay Measurement Accuracy ........................18
3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 19 2.9.11. Delay Measurement Timestamp Format ................18
3.1. Loss Measurement Message Format . . . . . . . . . . . . . 19 3. Message Formats ................................................19
3.2. Delay Measurement Message Format . . . . . . . . . . . . . 25 3.1. Loss Measurement Message Format ...........................19
3.3. Combined Loss/Delay Measurement Message Format . . . . . . 27 3.2. Delay Measurement Message Format ..........................25
3.4. Timestamp Field Formats . . . . . . . . . . . . . . . . . 28 3.3. Combined Loss/Delay Measurement Message Format ............27
3.5. TLV Objects . . . . . . . . . . . . . . . . . . . . . . . 29 3.4. Timestamp Field Formats ...................................28
3.5.1. Padding . . . . . . . . . . . . . . . . . . . . . . . 30 3.5. TLV Objects ...............................................29
3.5.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 31 3.5.1. Padding ............................................30
3.5.3. Loopback Request . . . . . . . . . . . . . . . . . . . 31 3.5.2. Addressing .........................................31
3.5.4. Session Query Interval . . . . . . . . . . . . . . . . 32 3.5.3. Loopback Request ...................................31
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.5.4. Session Query Interval .............................32
4.1. Operational Overview . . . . . . . . . . . . . . . . . . . 33 4. Operation ......................................................33
4.2. Loss Measurement Procedures . . . . . . . . . . . . . . . 34 4.1. Operational Overview ......................................33
4.2.1. Initiating a Loss Measurement Operation . . . . . . . 34 4.2. Loss Measurement Procedures ...............................34
4.2.2. Transmitting a Loss Measurement Query . . . . . . . . 34 4.2.1. Initiating a Loss Measurement Operation ............34
4.2.3. Receiving a Loss Measurement Query . . . . . . . . . . 35 4.2.2. Transmitting a Loss Measurement Query ..............34
4.2.4. Transmitting a Loss Measurement Response . . . . . . . 35 4.2.3. Receiving a Loss Measurement Query .................35
4.2.5. Receiving a Loss Measurement Response . . . . . . . . 36 4.2.4. Transmitting a Loss Measurement Response ...........35
4.2.6. Loss Calculation . . . . . . . . . . . . . . . . . . . 36 4.2.5. Receiving a Loss Measurement Response ..............36
4.2.7. Quality of Service . . . . . . . . . . . . . . . . . . 37 4.2.6. Loss Calculation ...................................36
4.2.8. G-ACh Packets . . . . . . . . . . . . . . . . . . . . 37 4.2.7. Quality of Service .................................37
4.2.9. Test Messages . . . . . . . . . . . . . . . . . . . . 37 4.2.8. G-ACh Packets ......................................37
4.2.10. Message Loss and Packet Misorder Conditions . . . . . 38 4.2.9. Test Messages ......................................37
4.3. Delay Measurement Procedures . . . . . . . . . . . . . . . 39 4.2.10. Message Loss and Packet Misorder Conditions .......38
4.3.1. Transmitting a Delay Measurement Query . . . . . . . . 39 4.3. Delay Measurement Procedures ..............................39
4.3.2. Receiving a Delay Measurement Query . . . . . . . . . 39 4.3.1. Transmitting a Delay Measurement Query .............39
4.3.3. Transmitting a Delay Measurement Response . . . . . . 40 4.3.2. Receiving a Delay Measurement Query ................39
4.3.4. Receiving a Delay Measurement Response . . . . . . . . 41 4.3.3. Transmitting a Delay Measurement Response ..........40
4.3.5. Timestamp Format Negotiation . . . . . . . . . . . . . 41 4.3.4. Receiving a Delay Measurement Response .............41
4.3.6. Quality of Service . . . . . . . . . . . . . . . . . . 42 4.3.5. Timestamp Format Negotiation .......................41
4.4. Combined Loss/Delay Measurement Procedures . . . . . . . . 42 4.3.5.1. Single-Format Procedures ..................42
5. Implementation Disclosure Requirements . . . . . . . . . . . . 42 4.3.6. Quality of Service .................................42
6. Congestion Considerations . . . . . . . . . . . . . . . . . . 43 4.4. Combined Loss/Delay Measurement Procedures ................42
7. Manageability Considerations . . . . . . . . . . . . . . . . . 44 5. Implementation Disclosure Requirements .........................42
8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 6. Congestion Considerations ......................................44
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 7. Manageability Considerations ...................................44
9.1. Allocation of PW Associated Channel Types . . . . . . . . 46 8. Security Considerations ........................................45
9.2. Creation of Measurement Timestamp Type Registry . . . . . 47 9. IANA Considerations ............................................46
9.3. Creation of MPLS Loss/Delay Measurement Control Code 9.1. Allocation of PW Associated Channel Types .................47
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 47 9.2. Creation of Measurement Timestamp Type Registry ...........47
9.4. Creation of MPLS Loss/Delay Measurement TLV Object 9.3. Creation of MPLS Loss/Delay Measurement Control
Registry . . . . . . . . . . . . . . . . . . . . . . . . . 48 Code Registry .............................................47
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 9.4. Creation of MPLS Loss/Delay Measurement TLV Object
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Registry ..................................................49
11.1. Normative References . . . . . . . . . . . . . . . . . . . 49 10. Acknowledgments ...............................................49
11.2. Informative References . . . . . . . . . . . . . . . . . . 50 11. References ....................................................49
Appendix A. Default Timestamp Format Rationale . . . . . . . . . 51 11.1. Normative References .....................................49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 11.2. Informative References ...................................50
Appendix A. Default Timestamp Format Rationale ....................52
1. Introduction 1. Introduction
Many service provider service level agreements (SLAs) depend on the Many service provider service level agreements (SLAs) depend on the
ability to measure and monitor performance metrics for packet loss ability to measure and monitor performance metrics for packet loss
and one-way and two-way delay, as well as related metrics such as and one-way and two-way delay, as well as related metrics such as
delay variation and channel throughput. This measurement capability delay variation and channel throughput. This measurement capability
also provides operators with greater visibility into the performance also provides operators with greater visibility into the performance
characteristics of their networks, thereby facilitating planning, characteristics of their networks, thereby facilitating planning,
troubleshooting, and evaluation. This document specifies protocol troubleshooting, and network performance evaluation. This document
mechanisms to enable the efficient and accurate measurement of these specifies protocol mechanisms to enable the efficient and accurate
performance metrics in MPLS networks. measurement of these performance metrics in MPLS networks.
This document specifies two closely-related protocols, one for packet This document specifies two closely related protocols, one for packet
loss measurement (LM) and one for packet delay measurement (DM). loss measurement (LM) and one for packet delay measurement (DM).
These protocols have the following characteristics and capabilities: These protocols have the following characteristics and capabilities:
o The LM and DM protocols are intended to be simple and to support o The LM and DM protocols are intended to be simple and to support
efficient hardware processing. efficient hardware processing.
o The LM and DM protocols operate over the MPLS Generic Associated o The LM and DM protocols operate over the MPLS Generic Associated
Channel (G-ACh) [RFC5586] and support measurement of loss, delay, Channel (G-ACh) [RFC5586] and support measurement of loss, delay,
and related metrics over Label Switched Paths (LSPs), pseudowires, and related metrics over Label Switched Paths (LSPs), pseudowires,
and MPLS sections (links). and MPLS sections (links).
o The LM and DM protocols are applicable to the LSPs, pseudowires, o The LM and DM protocols are applicable to the LSPs, pseudowires,
and sections of networks based on the MPLS Transport Profile and sections of networks based on the MPLS Transport Profile
(MPLS-TP), because the MPLS-TP is based on a standard MPLS data (MPLS-TP), because the MPLS-TP is based on a standard MPLS data
plane. The MPLS-TP is defined and described in [RFC5921], and plane. The MPLS-TP is defined and described in [RFC5921], and
MPLS-TP LSPs, pseudowires, and sections are discussed in detail in MPLS-TP LSPs, pseudowires, and sections are discussed in detail in
[RFC5960]. A profile describing the minimal functional subset of [RFC5960]. A profile describing the minimal functional subset of
the LM and DM protocols in the MPLS-TP context is provided in the LM and DM protocols in the MPLS-TP context is provided in
[I-D.ietf-mpls-tp-loss-delay-profile]. [RFC6375].
o The LM and DM protocols can be used both for continuous/proactive o The LM and DM protocols can be used both for continuous/proactive
and selective/on-demand measurement. and selective/on-demand measurement.
o The LM and DM protocols use a simple query/response model for o The LM and DM protocols use a simple query/response model for
bidirectional measurement that allows a single node - the querier bidirectional measurement that allows a single node -- the querier
- to measure the loss or delay in both directions. -- to measure the loss or delay in both directions.
o The LM and DM protocols use query messages for unidirectional loss o The LM and DM protocols use query messages for unidirectional loss
and delay measurement. The measurement can either be carried out and delay measurement. The measurement can be carried out either
at the downstream node(s) or at the querier if an out-of-band at the downstream node(s) or at the querier if an out-of-band
return path is available. return path is available.
o The LM and DM protocols do not require that the transmit and o The LM and DM protocols do not require that the transmit and
receive interfaces be the same when performing bidirectional receive interfaces be the same when performing bidirectional
measurement. measurement.
o The DM protocol is stateless. o The DM protocol is stateless.
o The LM protocol is "almost" stateless: loss is computed as a delta o The LM protocol is "almost" stateless: loss is computed as a delta
between successive messages, and thus the data associated with the between successive messages, and thus the data associated with the
last message received must be retained. last message received must be retained.
o The LM protocol can perform two distinct kinds of loss o The LM protocol can perform two distinct kinds of loss
measurement: it can measure the loss of specially generated test measurement: it can measure the loss of specially generated test
messages in order to infer the approximate data-plane loss level messages in order to infer the approximate data-plane loss level
(inferred measurement); or it can directly measure data-plane (inferred measurement) or it can directly measure data-plane
packet loss (direct measurement). Direct measurement provides packet loss (direct measurement). Direct measurement provides
perfect loss accounting, but may require specialized hardware perfect loss accounting, but may require specialized hardware
support and is only applicable to some LSP types. Inferred support and is only applicable to some LSP types. Inferred
measurement provides only approximate loss accounting but is measurement provides only approximate loss accounting but is
generally applicable. generally applicable.
The direct LM method is also known as "frame-based" in the context The direct LM method is also known as "frame-based" in the context
of Ethernet transport networks [Y.1731]. Inferred LM is a of Ethernet transport networks [Y.1731]. Inferred LM is a
generalization of the "synthetic" measurement approach currently generalization of the "synthetic" measurement approach currently
in development for Ethernet networks, in the sense that it allows in development for Ethernet networks, in the sense that it allows
skipping to change at page 5, line 51 skipping to change at page 5, line 35
o The DM protocol supports varying the measurement message size in o The DM protocol supports varying the measurement message size in
order to measure delays associated with different packet sizes. order to measure delays associated with different packet sizes.
The One-Way Active Measurement Protocol (OWAMP) [RFC4656] and Two-Way The One-Way Active Measurement Protocol (OWAMP) [RFC4656] and Two-Way
Active Measurement Protocol (TWAMP) [RFC5357] provide capabilities Active Measurement Protocol (TWAMP) [RFC5357] provide capabilities
for the measurement of various performance metrics in IP networks. for the measurement of various performance metrics in IP networks.
These protocols are not streamlined for hardware processing and rely These protocols are not streamlined for hardware processing and rely
on IP and TCP, as well as elements of the Network Time Protocol on IP and TCP, as well as elements of the Network Time Protocol
(NTP), which may not be available or optimized in some network (NTP), which may not be available or optimized in some network
environments; they also lack support for IEEE 1588 timestamps and environments; they also lack support for IEEE 1588 timestamps and
direct-mode LM, which in some environments may be required. The direct-mode LM, which may be required in some environments. The
protocols defined in this document thus are similar in some respects protocols defined in this document thus are similar in some respects
to, but also differ from, these IP-based protocols. to, but also differ from, these IP-based protocols.
1.1. Applicability and Scope 1.1. Applicability and Scope
This document specifies measurement procedures and protocol messages This document specifies measurement procedures and protocol messages
that are intended to be applicable in a wide variety of that are intended to be applicable in a wide variety of circumstances
circumstances, and amenable to implementation by a wide range of and amenable to implementation by a wide range of hardware- and
hardware- and software-based measurement systems. As such, it does software-based measurement systems. As such, it does not attempt to
not attempt to mandate measurement quality levels or analyze specific mandate measurement quality levels or analyze specific end-user
end-user applications. applications.
1.2. Terminology 1.2. Terminology
Term Definition Term Definition
----- ------------------------------------------- ----- -------------------------------------------
ACH Associated Channel Header ACH Associated Channel Header
DM Delay Measurement DM Delay Measurement
ECMP Equal Cost Multipath ECMP Equal Cost Multipath
G-ACh Generic Associated Channel G-ACh Generic Associated Channel
LM Loss Measurement LM Loss Measurement
LSE Label Stack Entry LSE Label Stack Entry
LSP Label Switched Path LSP Label Switched Path
NTP Network Time Protocol NTP Network Time Protocol
OAM Operations, Administration, and Maintenance OAM Operations, Administration, and Maintenance
PTP Precision Time Protocol PTP Precision Time Protocol
TC Traffic Class TC Traffic Class
1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Overview 2. Overview
This section begins with a summary of the basic methods used for the This section begins with a summary of the basic methods used for the
bidirectional measurement of packet loss and delay. These bidirectional measurement of packet loss and delay. These
measurement methods are then described in detail. Finally a list of measurement methods are then described in detail. Finally, a list of
practical considerations are discussed that may come into play to practical considerations is discussed that may come into play to
inform or modify these simple procedures. This section is limited to inform or modify these simple procedures. This section is limited to
theoretical discussion; for protocol specifics the reader is referred theoretical discussion; for protocol specifics, the reader is
to Section 3 and Section 4. referred to Sections 3 and 4.
2.1. Basic Bidirectional Measurement 2.1. Basic Bidirectional Measurement
The following figure shows the reference scenario. The following figure shows the reference scenario.
T1 T2 T1 T2
+-------+/ Query \+-------+ +-------+/ Query \+-------+
| | - - - - - - - - ->| | | | - - - - - - - - ->| |
| A |===================| B | | A |===================| B |
| |<- - - - - - - - - | | | |<- - - - - - - - - | |
+-------+\ Response /+-------+ +-------+\ Response /+-------+
T4 T3 T4 T3
Figure 1 This figure shows a bidirectional channel between two nodes, A and B,
The figure shows a bidirectional channel between two nodes, A and B,
and illustrates the temporal reference points T1-T4 associated with a and illustrates the temporal reference points T1-T4 associated with a
measurement operation that takes place at A. The operation consists measurement operation that takes place at A. The operation consists
of A sending a query message to B, and B sending back a response. of A sending a query message to B, and B sending back a response.
Each reference point indicates the point in time at which either the Each reference point indicates the point in time at which either the
query or the response message is transmitted or received over the query or the response message is transmitted or received over the
channel. channel.
In this situation, A can arrange to measure the packet loss over the In this situation, A can arrange to measure the packet loss over the
channel in the forward and reverse directions by sending Loss channel in the forward and reverse directions by sending Loss
Measurement (LM) query messages to B each of which contains the count Measurement (LM) query messages to B, each of which contains the
of packets transmitted prior to time T1 over the channel to B count of packets transmitted prior to time T1 over the channel to B
(A_TxP). When the message reaches B, it appends two values and (A_TxP). When the message reaches B, it appends two values and
reflects the message back to A: the count of packets received prior reflects the message back to A: the count of packets received prior
to time T2 over the channel from A (B_RxP), and the count of packets to time T2 over the channel from A (B_RxP) and the count of packets
transmitted prior to time T3 over the channel to A (B_TxP). When the transmitted prior to time T3 over the channel to A (B_TxP). When the
response reaches A, it appends a fourth value, the count of packets response reaches A, it appends a fourth value: the count of packets
received prior to time T4 over the channel from B (A_RxP). received prior to time T4 over the channel from B (A_RxP).
These four counter values enable A to compute the desired loss These four counter values enable A to compute the desired loss
statistics. Because the transmit count at A and the receive count at statistics. Because the transmit count at A and the receive count at
B (and vice versa) may not be synchronized at the time of the first B (and vice versa) may not be synchronized at the time of the first
message, and to limit the effects of counter wrap, the loss is message, and to limit the effects of counter wrap, the loss is
computed in the form of a delta between messages. computed in the form of a delta between messages.
To measure at A the delay over the channel to B, a Delay Measurement To measure at A the delay over the channel to B, a Delay Measurement
(DM) query message is sent from A to B containing a timestamp (DM) query message is sent from A to B containing a timestamp
recording the instant at which it is transmitted, i.e. T1. When the recording the instant at which it is transmitted, i.e., T1. When the
message reaches B, a timestamp is added recording the instant at message reaches B, a timestamp is added recording the instant at
which it is received (T2). The message can now be reflected from B which it is received (T2). The message can now be reflected from B
to A, with B adding its transmit timestamp (T3) and A adding its to A, with B adding its transmit timestamp (T3) and A adding its
receive timestamp (T4). These four timestamps enable A to compute receive timestamp (T4). These four timestamps enable A to compute
the one-way delay in each direction, as well as the two-way delay for the one-way delay in each direction, as well as the two-way delay for
the channel. The one-way delay computations require that the clocks the channel. The one-way delay computations require that the clocks
of A and B be synchronized; mechanisms for clock synchronization are of A and B be synchronized; mechanisms for clock synchronization are
outside the scope of this document. outside the scope of this document.
2.2. Packet Loss Measurement 2.2. Packet Loss Measurement
Suppose a bidirectional channel exists between the nodes A and B. The Suppose a bidirectional channel exists between the nodes A and B.
objective is to measure at A the following two quantities associated The objective is to measure at A the following two quantities
with the channel: associated with the channel:
A_TxLoss (transmit loss): the number of packets transmitted by A A_TxLoss (transmit loss): the number of packets transmitted by A
over the channel but not received at B; over the channel but not received at B;
A_RxLoss (receive loss): the number of packets transmitted by B A_RxLoss (receive loss): the number of packets transmitted by B
over the channel but not received at A. over the channel but not received at A.
This is accomplished by initiating a Loss Measurement (LM) operation This is accomplished by initiating a Loss Measurement (LM) operation
at A, which consists of transmission of a sequence of LM query at A, which consists of transmission of a sequence of LM query
messages (LM[1], LM[2], ...) over the channel at a specified rate, messages (LM[1], LM[2], ...) over the channel at a specified rate,
skipping to change at page 9, line 4 skipping to change at page 8, line 40
A_RxP[n]: the total count of packets received by A over the A_RxP[n]: the total count of packets received by A over the
channel at the time this response is received (excluding the channel at the time this response is received (excluding the
message itself). message itself).
The transmit loss A_TxLoss[n-1,n] and receive loss A_RxLoss[n-1,n] The transmit loss A_TxLoss[n-1,n] and receive loss A_RxLoss[n-1,n]
within the measurement interval marked by the messages LM[n-1] and within the measurement interval marked by the messages LM[n-1] and
LM[n] are computed by A as follows: LM[n] are computed by A as follows:
A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1]) A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])
A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1]) A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])
where the arithmetic is modulo the counter size. where the arithmetic is modulo the counter size.
(Strictly speaking, it is not necessary that the fourth count, (Strictly speaking, it is not necessary that the fourth count,
A_RxP[n], actually be written in the message, but this is convenient A_RxP[n], actually be written in the message, but this is convenient
for some implementations and useful if the message is to be forwarded for some implementations and useful if the message is to be forwarded
on to an external measurement system.) on to an external measurement system.)
The derived values The derived values
A_TxLoss = A_TxLoss[1,2] + A_TxLoss[2,3] + ... A_TxLoss = A_TxLoss[1,2] + A_TxLoss[2,3] + ...
A_RxLoss = A_RxLoss[1,2] + A_RxLoss[2,3] + ... A_RxLoss = A_RxLoss[1,2] + A_RxLoss[2,3] + ...
are updated each time a response to an LM message is received and are updated each time a response to an LM message is received and
processed, and represent the total transmit and receive loss over the processed, and they represent the total transmit and receive loss
channel since the LM operation was initiated. over the channel since the LM operation was initiated.
When computing the values A_TxLoss[n-1,n] and A_RxLoss[n-1,n] the When computing the values A_TxLoss[n-1,n] and A_RxLoss[n-1,n], the
possibility of counter wrap must be taken into account. Consider for possibility of counter wrap must be taken into account. For example,
example the values of the A_TxP counter at sequence numbers n-1 and consider the values of the A_TxP counter at sequence numbers n-1 and
n. Clearly if A_TxP[n] is allowed to wrap to 0 and then beyond to a n. Clearly if A_TxP[n] is allowed to wrap to 0 and then beyond to a
value equal to or greater than A_TxP[n-1], the computation of an value equal to or greater than A_TxP[n-1], the computation of an
unambiguous A_TxLoss[n-1,n] value will be impossible. Therefore the unambiguous A_TxLoss[n-1,n] value will be impossible. Therefore, the
LM message rate MUST be sufficiently high, given the counter size and LM message rate MUST be sufficiently high, given the counter size and
the speed and minimum packet size of the underlying channel, that the speed and minimum packet size of the underlying channel, that
this condition cannot arise. For example, a 32-bit counter for a 100 this condition cannot arise. For example, a 32-bit counter for a
Gbps link with a minimum packet size of 64 bytes can wrap in 2^32 / 100-Gbps link with a minimum packet size of 64 bytes can wrap in 2^32
(10^11/(64*8)) = ~22 seconds, which is therefore an upper bound on / (10^11/(64*8)) = ~22 seconds, which is therefore an upper bound on
the LM message interval under such conditions. This bound will be the LM message interval under such conditions. This bound will be
referred to as the MaxLMInterval of the channel. It is clear that referred to as the MaxLMInterval of the channel. It is clear that
the MaxLMInterval will be a more restrictive constraint in the case the MaxLMInterval will be a more restrictive constraint in the case
of direct LM and for smaller counter sizes. of direct LM and for smaller counter sizes.
The loss measurement approach described in this section has the The loss measurement approach described in this section has the
characteristic of being stateless at B and "almost" stateless at A. characteristic of being stateless at B and "almost" stateless at A.
Specifically, A must retain the data associated with the last LM Specifically, A must retain the data associated with the last LM
response received, in order to use it to compute loss when the next response received, in order to use it to compute loss when the next
response arrives. This data MAY be discarded, and MUST NOT be used response arrives. This data MAY be discarded, and MUST NOT be used
as a basis for measurement, if MaxLMInterval elapses before the next as a basis for measurement, if MaxLMInterval elapses before the next
response arrives, because in this case an unambiguous measurement response arrives, because in this case an unambiguous measurement
cannot be made. cannot be made.
The foregoing discussion has assumed the counted objects are packets, The foregoing discussion has assumed the counted objects are packets,
but this need not be the case. In particular, octets may be counted but this need not be the case. In particular, octets may be counted
instead. This will, of course, reduce the MaxLMInterval accordingly. instead. This will, of course, reduce the MaxLMInterval accordingly.
In addition to absolute aggregate loss counts, the individual loss In addition to absolute aggregate loss counts, the individual loss
counts yield additional metrics such as the average loss rate over counts yield other metrics, such as the average loss rate over any
any multiple of the measurement interval. An accurate loss rate can multiple of the measurement interval. An accurate loss rate can be
be determined over time even in the presence of anomalies affecting determined over time even in the presence of anomalies affecting
individual measurements, such as those due to packet misordering individual measurements, such as those due to packet misordering
(Section 4.2.10). (Section 4.2.10).
Note that an approach for conducting packet loss measurement in IP Note that an approach for conducting packet loss measurement in IP
networks is documented in [RFC2680]. This approach differs from the networks is documented in [RFC2680]. This approach differs from the
one described here, for example by requiring clock synchronization one described here, for example by requiring clock synchronization
between the measurement points and lacking support for direct-mode between the measurement points and lacking support for direct-mode
LM. LM.
2.3. Throughput Measurement 2.3. Throughput Measurement
skipping to change at page 10, line 33 skipping to change at page 10, line 29
messages (separated in time by not more than the MaxLMInterval), the messages (separated in time by not more than the MaxLMInterval), the
difference between the counter values tells the querier the number of difference between the counter values tells the querier the number of
units successfully transmitted and received in the interval between units successfully transmitted and received in the interval between
the timestamps. Absolute offered throughput is the number of data the timestamps. Absolute offered throughput is the number of data
units transmitted and absolute delivered throughput is the number of units transmitted and absolute delivered throughput is the number of
data units received. Throughput rate is the number of data units data units received. Throughput rate is the number of data units
sent or received per unit time. sent or received per unit time.
Just as for loss measurement, the interval counts can be accumulated Just as for loss measurement, the interval counts can be accumulated
to arrive at the absolute throughput of the channel since the start to arrive at the absolute throughput of the channel since the start
of the measurement operation, or used to derive related metrics such of the measurement operation or be used to derive related metrics
as the throughput rate. This procedure also enables out-of-service such as the throughput rate. This procedure also enables out-of-
throughput testing when combined with a simple packet generator. service throughput testing when combined with a simple packet
generator.
2.4. Delay Measurement 2.4. Delay Measurement
Suppose a bidirectional channel exists between the nodes A and B. The Suppose a bidirectional channel exists between the nodes A and B.
objective is to measure at A one or more of the following quantities The objective is to measure at A one or more of the following
associated with the channel: quantities associated with the channel:
o The one-way delay associated with the forward (A to B) direction o The one-way delay associated with the forward (A to B) direction
of the channel; of the channel;
o The one-way delay associated with the reverse (B to A) direction o The one-way delay associated with the reverse (B to A) direction
of the channel; of the channel;
o The two-way delay (A to B to A) associated with the channel. o The two-way delay (A to B to A) associated with the channel.
The one-way delay metric for packet networks is described in The one-way delay metric for packet networks is described in
skipping to change at page 11, line 4 skipping to change at page 10, line 49
o The one-way delay associated with the forward (A to B) direction o The one-way delay associated with the forward (A to B) direction
of the channel; of the channel;
o The one-way delay associated with the reverse (B to A) direction o The one-way delay associated with the reverse (B to A) direction
of the channel; of the channel;
o The two-way delay (A to B to A) associated with the channel. o The two-way delay (A to B to A) associated with the channel.
The one-way delay metric for packet networks is described in The one-way delay metric for packet networks is described in
[RFC2679]. In the case of two-way delay, there are actually two [RFC2679]. In the case of two-way delay, there are actually two
possible metrics of interest. The "two-way channel delay" is the sum possible metrics of interest. The "two-way channel delay" is the sum
of the one-way delays in each direction and reflects the delay of the of the one-way delays in each direction and reflects the delay of the
channel itself, irrespective of processing delays within the remote channel itself, irrespective of processing delays within the remote
endpoint B. The "round-trip delay" is described in [RFC2681] and endpoint B. The "round-trip delay" is described in [RFC2681] and
includes in addition any delay associated with remote endpoint includes in addition any delay associated with remote endpoint
processing. processing.
Measurement of the one-way delay quantities requires that the clocks Measurement of the one-way delay quantities requires that the clocks
of A and B be synchronized, whereas the two-way delay metrics can be of A and B be synchronized, whereas the two-way delay metrics can be
measured directly even when this is not the case (provided A and B measured directly even when this is not the case (provided A and B
have stable clocks). have stable clocks).
A measurement is accomplished by sending a Delay Measurement (DM) A measurement is accomplished by sending a Delay Measurement (DM)
query message over the channel to B which contains the following query message over the channel to B that contains the following
timestamp: timestamp:
T1: the time the DM query message is transmitted from A. T1: the time the DM query message is transmitted from A.
When the message arrives at B, the following timestamp is recorded in When the message arrives at B, the following timestamp is recorded in
the message: the message:
T2: the time the DM query message is received at B. T2: the time the DM query message is received at B.
At this point B transmits the message back to A, recording within it At this point, B transmits the message back to A, recording within it
the following timestamp: the following timestamp:
T3: the time the DM response message is transmitted from B. T3: the time the DM response message is transmitted from B.
When the message arrives back at A, the following timestamp is When the message arrives back at A, the following timestamp is
recorded in the message: recorded in the message:
T4: the time the DM response message is received back at A. T4: the time the DM response message is received back at A.
(Strictly speaking, it is not necessary that the fourth timestamp, (Strictly speaking, it is not necessary that the fourth timestamp,
skipping to change at page 12, line 39 skipping to change at page 12, line 39
IPDV and PDV measurements can therefore be derived from delay IPDV and PDV measurements can therefore be derived from delay
measurements obtained through the procedures in Section 2.4. An measurements obtained through the procedures in Section 2.4. An
important point regarding delay variation measurement, however, is important point regarding delay variation measurement, however, is
that it can be carried out based on one-way delay measurements even that it can be carried out based on one-way delay measurements even
when the clocks of the two systems involved in those measurements are when the clocks of the two systems involved in those measurements are
not synchronized with one another. not synchronized with one another.
2.6. Unidirectional Measurement 2.6. Unidirectional Measurement
In the case that the channel from A to (B1, ..., Bk) (where B2, ..., In the case that the channel from A to (B1, ..., Bk) (where B2, ...,
Bk refer to the point-to-multipoint case) is unidirectional, i.e. is Bk refers to the point-to-multipoint case) is unidirectional, i.e.,
a unidirectional LSP, LM and DM measurements can be carried out at is a unidirectional LSP, LM and DM measurements can be carried out at
B1, ..., Bk instead of at A. B1, ..., Bk instead of at A.
For LM this is accomplished by initiating an LM operation at A and For LM, this is accomplished by initiating an LM operation at A and
carrying out the same procedures as for bidirectional channels, carrying out the same procedures as used for bidirectional channels,
except that no responses from B1, ..., Bk to A are generated. except that no responses from B1, ..., Bk to A are generated.
Instead, each terminal node B uses the A_TxP and B_RxP values in the Instead, each terminal node B uses the A_TxP and B_RxP values in the
LM messages it receives to compute the receive loss associated with LM messages it receives to compute the receive loss associated with
the channel in essentially the same way as described previously, i.e. the channel in essentially the same way as described previously, that
is:
B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1]) B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])
For DM, of course, only the forward one-way delay can be measured and For DM, of course, only the forward one-way delay can be measured and
the clock synchronization requirement applies. the clock synchronization requirement applies.
Alternatively, if an out-of-band channel from a terminal node B back Alternatively, if an out-of-band channel from a terminal node B back
to A is available, the LM and DM message responses can be to A is available, the LM and DM message responses can be
communicated to A via this channel so that the measurements can be communicated to A via this channel so that the measurements can be
carried out at A. carried out at A.
2.7. Dyadic Measurement 2.7. Dyadic Measurement
skipping to change at page 13, line 14 skipping to change at page 13, line 15
the clock synchronization requirement applies. the clock synchronization requirement applies.
Alternatively, if an out-of-band channel from a terminal node B back Alternatively, if an out-of-band channel from a terminal node B back
to A is available, the LM and DM message responses can be to A is available, the LM and DM message responses can be
communicated to A via this channel so that the measurements can be communicated to A via this channel so that the measurements can be
carried out at A. carried out at A.
2.7. Dyadic Measurement 2.7. Dyadic Measurement
The basic procedures for bidirectional measurement assume that the The basic procedures for bidirectional measurement assume that the
measurement process is conducted by and for the querier node A. It is measurement process is conducted by and for the querier node A.
possible instead, with only minor variation of these procedures, to Instead, it is possible, with only minor variation of these
conduct a dyadic or "dual-ended" measurement process in which both procedures, to conduct a dyadic or "dual-ended" measurement process
nodes A and B perform loss or delay measurement based on the same in which both nodes A and B perform loss or delay measurement based
message flow. This is achieved by stipulating that A copy the third on the same message flow. This is achieved by stipulating that A
and fourth counter or timestamp values from a response message into copy the third and fourth counter or timestamp values from a response
the third and fourth slots of the next query, which are otherwise message into the third and fourth slots of the next query, which are
unused, thereby providing B with equivalent information to that otherwise unused, thereby providing B with equivalent information to
learned by A. that learned by A.
The dyadic procedure has the advantage of halving the number of The dyadic procedure has the advantage of halving the number of
messages required for both A and B to perform a given kind of messages required for both A and B to perform a given kind of
measurement, but comes at the expense of each node's ability to measurement, but comes at the expense of each node's ability to
control its own measurement process independently, and introduces control its own measurement process independently, and introduces
additional operational complexity into the measurement protocols. additional operational complexity into the measurement protocols.
The quantity of measurement traffic is also expected to be low The quantity of measurement traffic is also expected to be low
relative to that of user traffic, particularly when 64-bit counters relative to that of user traffic, particularly when 64-bit counters
are used for LM. Consequently this document does not specify a are used for LM. Consequently, this document does not specify a
dyadic operational mode. It is however still possible, and may be dyadic operational mode. However, it is still possible, and may be
useful, for A to perform the extra copy, thereby providing additional useful, for A to perform the extra copy, thereby providing additional
information to B even when its participation in the measurement information to B even when its participation in the measurement
process is passive. process is passive.
2.8. Loopback Measurement 2.8. Loopback Measurement
Some bidirectional channels may be placed into a loopback state such Some bidirectional channels may be placed into a loopback state such
that messages are looped back to the sender without modification. In that messages are looped back to the sender without modification. In
this situation, LM and DM procedures can be used to carry out this situation, LM and DM procedures can be used to carry out
measurements associated with the circular path. This is done by measurements associated with the circular path. This is done by
skipping to change at page 14, line 25 skipping to change at page 14, line 28
cases, LM and DM messages flow over the MPLS Generic Associated cases, LM and DM messages flow over the MPLS Generic Associated
Channel (G-ACh), which is described in detail in [RFC5586]. Channel (G-ACh), which is described in detail in [RFC5586].
Broadly, a channel in an MPLS network may be either a link, a Label Broadly, a channel in an MPLS network may be either a link, a Label
Switched Path (LSP) [RFC3031], or a pseudowire [RFC3985]. Links are Switched Path (LSP) [RFC3031], or a pseudowire [RFC3985]. Links are
bidirectional and are also referred to as MPLS sections; see bidirectional and are also referred to as MPLS sections; see
[RFC5586] and [RFC5960]. Pseudowires are bidirectional. Label [RFC5586] and [RFC5960]. Pseudowires are bidirectional. Label
Switched Paths may be either unidirectional or bidirectional. Switched Paths may be either unidirectional or bidirectional.
The LM and DM protocols discussed in this document are initiated from The LM and DM protocols discussed in this document are initiated from
a single node, the querier. A query message may be received either a single node: the querier. A query message may be received either
by a single node or by multiple nodes, depending on the nature of the by a single node or by multiple nodes, depending on the nature of the
channel. In the latter case these protocols provide point-to- channel. In the latter case, these protocols provide point-to-
multipoint measurement capabilities. multipoint measurement capabilities.
2.9.2. Quality of Service 2.9.2. Quality of Service
Quality of Service (QoS) capabilities, in the form of the Quality of Service (QoS) capabilities, in the form of the
Differentiated Services architecture, apply to MPLS as specified in Differentiated Services architecture, apply to MPLS as specified in
[RFC3270] and [RFC5462]. Different classes of traffic are [RFC3270] and [RFC5462]. Different classes of traffic are
distinguished by the three-bit Traffic Class (TC) field of an MPLS distinguished by the three-bit Traffic Class (TC) field of an MPLS
Label Stack Entry (LSE). Delay measurement therefore applies on a Label Stack Entry (LSE). Delay measurement applies on a per-traffic-
per-traffic-class basis, and the TC values of LSEs above the G-ACh class basis, and the TC values of LSEs above the G-ACh Label (GAL)
Label (GAL) that precedes a DM message are significant. Packet loss that precedes a DM message are significant. Packet loss can be
can be measured with respect either to the channel as a whole or to a measured with respect either to the channel as a whole or to a
specific traffic class. specific traffic class.
2.9.3. Measurement Point Location 2.9.3. Measurement Point Location
The location of the measurement points for loss and delay within the The location of the measurement points for loss and delay within the
sending and receiving nodes is implementation-dependent but directly sending and receiving nodes is implementation dependent but directly
affects the nature of the measurements. For example, a sending affects the nature of the measurements. For example, a sending
implementation may or may not consider a packet to be "lost", for LM implementation may or may not consider a packet to be "lost", for LM
purposes, that was discarded prior to transmission for queuing- purposes, that was discarded prior to transmission for queuing-
related reasons; conversely, a receiving implementation may or may related reasons; conversely, a receiving implementation may or may
not consider a packet to be "lost", for LM purposes, if it was not consider a packet to be "lost", for LM purposes, if it was
physically received but discarded during receive-path processing. physically received but discarded during receive-path processing.
The location of delay measurement points similarly determines what, The location of delay measurement points similarly determines what,
precisely, is being measured. The principal consideration here is precisely, is being measured. The principal consideration here is
that the behavior of an implementation in these respects MUST be made that the behavior of an implementation in these respects MUST be made
clear to the user. clear to the user.
2.9.4. Equal Cost Multipath 2.9.4. Equal Cost Multipath
Equal Cost Multipath (ECMP) is the behavior of distributing packets Equal Cost Multipath (ECMP) is the behavior of distributing packets
across multiple alternate paths toward a destination. The use of across multiple alternate paths toward a destination. The use of
ECMP in MPLS networks is described in BCP 128 [RFC4928]. The typical ECMP in MPLS networks is described in BCP 128 [RFC4928]. The typical
result of ECMP being performed on an LSP which is subject to delay result of ECMP being performed on an LSP that is subject to delay
measurement will be that only the delay of one of the available paths measurement will be that only the delay of one of the available paths
is and can be measured. is, and can be, measured.
The effects of ECMP on loss measurement will depend on the LM mode. The effects of ECMP on loss measurement will depend on the LM mode.
In the case of direct LM, the measurement will account for any In the case of direct LM, the measurement will account for any
packets lost between the sender and the receiver, regardless of how packets lost between the sender and the receiver, regardless of how
many paths exist between them. However, the presence of ECMP many paths exist between them. However, the presence of ECMP
increases the likelihood of misordering both of LM messages relative increases the likelihood of misordering both of LM messages relative
to data packets, and of the LM messages themselves. Such to data packets and of the LM messages themselves. Such misorderings
misorderings tend to create unmeasurable intervals and thus degrade tend to create unmeasurable intervals and thus degrade the accuracy
the accuracy of loss measurement. The effects of ECMP are similar of loss measurement. The effects of ECMP are similar for inferred
for inferred LM, with the additional caveat that, unless the test LM, with the additional caveat that, unless the test packets are
packets are specially constructed so as to probe all available paths, specially constructed so as to probe all available paths, the loss
the loss characteristics of one or more of the alternate paths cannot characteristics of one or more of the alternate paths cannot be
be accounted for. accounted for.
2.9.5. Intermediate Nodes 2.9.5. Intermediate Nodes
In the case of an LSP, it may be desirable to measure the loss or In the case of an LSP, it may be desirable to measure the loss or
delay to or from an intermediate node as well as between LSP delay to or from an intermediate node as well as between LSP
endpoints. This can be done in principle by setting the Time to Live endpoints. This can be done in principle by setting the Time to Live
(TTL) field in the outer LSE appropriately when targeting a (TTL) field in the outer LSE appropriately when targeting a
measurement message to an intermediate node. This procedure may measurement message to an intermediate node. This procedure may
fail, however, if hardware-assisted measurement is in use, because fail, however, if hardware-assisted measurement is in use, because
the processing of the packet by the intermediate node occurs only as the processing of the packet by the intermediate node occurs only as
the result of TTL expiry, and the handling of TTL expiry may occur at the result of TTL expiry, and the handling of TTL expiry may occur at
a later processing stage in the implementation than the hardware- a later processing stage in the implementation than the hardware-
assisted measurement function. Often the motivation for conducting assisted measurement function. The motivation for conducting
measurements to intermediate nodes is an attempt to localize a measurements to intermediate nodes is often an attempt to localize a
problem that has been detected on the LSP. In this case, if problem that has been detected on the LSP. In this case, if
intermediate nodes are not capable of performing hardware-assisted intermediate nodes are not capable of performing hardware-assisted
measurement, a less accurate - but usually sufficient - software- measurement, a less accurate -- but usually sufficient -- software-
based measurement can be conducted instead. based measurement can be conducted instead.
2.9.6. Different Transmit and Receive Interfaces 2.9.6. Different Transmit and Receive Interfaces
The overview of the bidirectional measurement process presented in The overview of the bidirectional measurement process presented in
Section 2 is also applicable when the transmit and receive interfaces Section 2 is also applicable when the transmit and receive interfaces
at A or B differ from one another. Some additional considerations, at A or B differ from one another. Some additional considerations,
however, do apply in this case: however, do apply in this case:
o If different clocks are associated with transmit and receive o If different clocks are associated with transmit and receive
skipping to change at page 16, line 22 skipping to change at page 16, line 27
timestamp formats used by the interfaces that receive a DM query timestamp formats used by the interfaces that receive a DM query
and transmit a DM response agree. and transmit a DM response agree.
o The LM protocol specified in this document supports both 32-bit o The LM protocol specified in this document supports both 32-bit
and 64-bit counter sizes, but the use of 32-bit counters at any of and 64-bit counter sizes, but the use of 32-bit counters at any of
the up to four interfaces involved in an LM operation will result the up to four interfaces involved in an LM operation will result
in 32-bit LM calculations for both directions of the channel. in 32-bit LM calculations for both directions of the channel.
2.9.7. External Post-Processing 2.9.7. External Post-Processing
In some circumstances it may be desirable to carry out the final In some circumstances, it may be desirable to carry out the final
measurement computation at an external post-processing device measurement computation at an external post-processing device
dedicated to the purpose. This can be achieved in supporting dedicated to the purpose. This can be achieved in supporting
implementations by, for example, configuring the querier, in the case implementations by, for example, configuring the querier, in the case
of a bidirectional measurement session, to forward each response it of a bidirectional measurement session, to forward each response it
receives to the post-processor via any convenient protocol. The receives to the post-processor via any convenient protocol. The
unidirectional case can be handled similarly through configuration of unidirectional case can be handled similarly through configuration of
the receiver, or by including an instruction in query messages for the receiver or by including an instruction in query messages for the
the receiver to respond out-of-band to the appropriate return receiver to respond out-of-band to the appropriate return address.
address.
Post-processing devices may have the ability to store measurement Post-processing devices may have the ability to store measurement
data for an extended period and to generate a variety of useful data for an extended period and to generate a variety of useful
statistics from them. External post-processing also allows the statistics from them. External post-processing also allows the
measurement process to be completely stateless at the querier and measurement process to be completely stateless at the querier and
responder. responder.
2.9.8. Loss Measurement Modes 2.9.8. Loss Measurement Modes
The summary of loss measurement at the beginning of Section 2 above The summary of loss measurement at the beginning of Section 2 made
made reference to the "count of packets" transmitted and received reference to the "count of packets" transmitted and received over a
over a channel. If the counted packets are the packets flowing over channel. If the counted packets are the packets flowing over the
the channel in the data plane, the loss measurement is said to channel in the data plane, the loss measurement is said to operate in
operate in "direct mode". If, on the other hand, the counted packets "direct mode". If, on the other hand, the counted packets are
are selected control packets from which the approximate loss selected control packets from which the approximate loss
characteristics of the channel are being inferred, the loss characteristics of the channel are being inferred, the loss
measurement is said to operate in "inferred mode". measurement is said to operate in "inferred mode".
Direct LM has the advantage of being able to provide perfect loss Direct LM has the advantage of being able to provide perfect loss
accounting when it is available. There are, however, several accounting when it is available. There are, however, several
constraints associated with direct LM. constraints associated with direct LM.
For accurate direct LM to occur, packets must not be sent between the For accurate direct LM to occur, packets must not be sent between the
time the transmit count for an outbound LM message is determined and time the transmit count for an outbound LM message is determined and
the time the message is actually transmitted. Similarly, packets the time the message is actually transmitted. Similarly, packets
skipping to change at page 18, line 11 skipping to change at page 18, line 14
Inferred LM provides only an approximate view of the loss level Inferred LM provides only an approximate view of the loss level
associated with a channel, but is typically applicable even in cases associated with a channel, but is typically applicable even in cases
where direct LM is not. where direct LM is not.
2.9.9. Loss Measurement Scope 2.9.9. Loss Measurement Scope
In the case of direct LM, where data-plane packets are counted, there In the case of direct LM, where data-plane packets are counted, there
are different possibilities for which kinds of packets are included are different possibilities for which kinds of packets are included
in the count and which are excluded. The set of packets counted for in the count and which are excluded. The set of packets counted for
LM is called the loss measurement scope. As noted above, one factor LM is called the "loss measurement scope". As noted above, one
affecting the LM scope is whether all data packets are counted or factor affecting the LM scope is whether all data packets are counted
only those belonging to a particular traffic class. Another is or only those belonging to a particular traffic class. Another is
whether various "auxiliary" flows associated with a data channel are whether various "auxiliary" flows associated with a data channel are
counted, such as packets flowing over the G-ACh. Implementations counted, such as packets flowing over the G-ACh. Implementations
MUST make their supported LM scopes clear to the user, and care must MUST make their supported LM scopes clear to the user, and care must
be taken to ensure that the scopes of the channel endpoints agree. be taken to ensure that the scopes of the channel endpoints agree.
2.9.10. Delay Measurement Accuracy 2.9.10. Delay Measurement Accuracy
The delay measurement procedures described in this document are The delay measurement procedures described in this document are
designed to facilitate hardware-assisted measurement and to function designed to facilitate hardware-assisted measurement and to function
in the same way whether or not such hardware assistance is used. The in the same way whether or not such hardware assistance is used. The
measurement accuracy will be determined by how closely the transmit measurement accuracy will be determined by how closely the transmit
and receive timestamps correspond to actual packet departure and and receive timestamps correspond to actual packet departure and
arrival times. arrival times.
As noted in Section 2.4, measurement of one-way delay requires clock As noted in Section 2.4, measurement of one-way delay requires clock
synchronization between the devices involved, while two-way delay synchronization between the devices involved, while two-way delay
measurement does not involve direct comparison between non-local measurement does not involve direct comparison between non-local
timestamps and thus has no synchronization requirement. The timestamps and thus has no synchronization requirement. The
measurement accuracy will be limited by the quality of the local measurement accuracy will be limited by the quality of the local
clock and, in the case of one-way delay measurement, by the quality clock and, in the case of one-way delay measurement, by the quality
of the synchonization. of the synchronization.
2.9.11. Delay Measurement Timestamp Format 2.9.11. Delay Measurement Timestamp Format
There are two significant timestamp formats in common use: the There are two significant timestamp formats in common use: the
timestamp format of the Network Time Protocol (NTP), described in timestamp format of the Network Time Protocol (NTP), described in
[RFC5905], and the timestamp format used in the IEEE 1588 Precision [RFC5905], and the timestamp format used in the IEEE 1588 Precision
Time Protocol (PTP) [IEEE1588]. Time Protocol (PTP) [IEEE1588].
The NTP format has the advantages of wide use and long deployment in The NTP format has the advantages of wide use and long deployment in
the Internet, and was specifically designed to make the computation the Internet, and it was specifically designed to make the
of timestamp differences as simple and efficient as possible. On the computation of timestamp differences as simple and efficient as
other hand, there is also now a significant deployment of equipment possible. On the other hand, there is now also a significant
designed to support the PTP format. deployment of equipment designed to support the PTP format.
The approach taken in this document is therefore to include in DM The approach taken in this document is therefore to include in DM
messages fields which identify the timestamp formats used by the two messages fields that identify the timestamp formats used by the two
devices involved in a DM operation. This implies that a node devices involved in a DM operation. This implies that a node
attempting to carry out a DM operation may be faced with the problem attempting to carry out a DM operation may be faced with the problem
of computing with and possibly reconciling different timestamp of computing with and possibly reconciling different timestamp
formats. To ensure interoperability it is necessary that support of formats. To ensure interoperability, it is necessary that support of
at least one timestamp format is mandatory. This specification at least one timestamp format is mandatory. This specification
requires the support of the IEEE 1588 PTP format. Timestamp format requires the support of the IEEE 1588 PTP format. Timestamp format
support requirements are discussed in detail in Section 3.4. support requirements are discussed in detail in Section 3.4.
3. Message Formats 3. Message Formats
Loss Measurement and Delay Measurement messages flow over the MPLS Loss Measurement and Delay Measurement messages flow over the MPLS
Generic Associated Channel (G-ACh) [RFC5586]. Thus, a packet Generic Associated Channel (G-ACh) [RFC5586]. Thus, a packet
containing an LM or DM message contains an MPLS label stack, with the containing an LM or DM message contains an MPLS label stack, with the
G-ACh Label (GAL) at the bottom of the stack. The GAL is followed by G-ACh Label (GAL) at the bottom of the stack. The GAL is followed by
an Associated Channel Header (ACH) which identifies the message type, an Associated Channel Header (ACH), which identifies the message
and the message body follows the ACH. type, and the message body follows the ACH.
This document defines the following ACH Channel Types: This document defines the following ACH Channel Types:
MPLS Direct Packet Loss Measurement (DLM) MPLS Direct Loss Measurement (DLM)
MPLS Inferred Packet Loss Measurement (ILM) MPLS Inferred Loss Measurement (ILM)
MPLS Packet Delay Measurement (DM) MPLS Delay Measurement (DM)
MPLS Direct Packet Loss and Delay Measurement (DLM+DM) MPLS Direct Loss and Delay Measurement (DLM+DM)
MPLS Inferred Packet Loss and Delay Measurement (ILM+DM) MPLS Inferred Loss and Delay Measurement (ILM+DM)
The message formats for direct and inferred LM are identical. The The message formats for direct and inferred LM are identical. The
formats of the DLM+DM and ILM+DM messages are also identical. formats of the DLM+DM and ILM+DM messages are also identical.
For these channel types, the ACH SHALL NOT be followed by the ACH TLV For these channel types, the ACH SHALL NOT be followed by the ACH TLV
Header defined in [RFC5586]. Header defined in [RFC5586].
The fixed-format portion of a message MAY be followed by a block of The fixed-format portion of a message MAY be followed by a block of
Type-Length-Value (TLV) fields. The TLV block provides an extensible Type-Length-Value (TLV) fields. The TLV block provides an extensible
way of attaching subsidiary information to LM and DM messages. way of attaching subsidiary information to LM and DM messages.
skipping to change at page 20, line 30 skipping to change at page 20, line 30
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 4 | | Counter 4 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~ ~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Loss Measurement Message Format Loss Measurement Message Format
Reserved fields MUST be set to 0 and ignored upon receipt. The Reserved fields MUST be set to 0 and ignored upon receipt. The
possible values for the remaining fields are as follows. possible values for the remaining fields are as follows.
Field Meaning Field Meaning
--------------------- ----------------------------------------------- --------------------- -----------------------------------------------
Version Protocol version Version Protocol version
Flags Message control flags Flags Message control flags
Control Code Code identifying the query or response type Control Code Code identifying the query or response type
Message Length Total length of this message in bytes Message Length Total length of this message in bytes
skipping to change at page 22, line 8 skipping to change at page 22, line 28
For a Response: For a Response:
Codes 0x0-0xF are reserved for non-error responses. Error Codes 0x0-0xF are reserved for non-error responses. Error
response codes imply that the response does not contain valid response codes imply that the response does not contain valid
measurement data. measurement data.
0x1: Success. Indicates that the operation was successful. 0x1: Success. Indicates that the operation was successful.
0x2: Notification - Data Format Invalid. Indicates that the 0x2: Notification - Data Format Invalid. Indicates that the
query was processed but the format of the data fields in this query was processed, but the format of the data fields in this
response may be inconsistent. Consequently these data fields response may be inconsistent. Consequently, these data fields
MUST NOT be used for measurement. MUST NOT be used for measurement.
0x3: Notification - Initialization In Progress. Indicates that 0x3: Notification - Initialization in Progress. Indicates that
the query was processed but this response does not contain the query was processed but this response does not contain
valid measurement data because the responder's initialization valid measurement data because the responder's initialization
process has not completed. process has not completed.
0x4: Notification - Data Reset Occurred. Indicates that the 0x4: Notification - Data Reset Occurred. Indicates that the
query was processed but a reset has recently occurred which may query was processed, but a reset has recently occurred that may
render the data in this response inconsistent relative to render the data in this response inconsistent relative to
earlier responses. earlier responses.
0x5: Notification - Resource Temporarily Unavailable. 0x5: Notification - Resource Temporarily Unavailable.
Indicates that the query was processed but resources were Indicates that the query was processed, but resources were
unavailable to complete the requested measurement, and that unavailable to complete the requested measurement and that,
consequently this response does not contain valid measurement consequently, this response does not contain valid measurement
data. data.
0x10: Error - Unspecified Error. Indicates that the operation 0x10: Error - Unspecified Error. Indicates that the operation
failed for an unspecified reason. failed for an unspecified reason.
0x11: Error - Unsupported Version. Indicates that the 0x11: Error - Unsupported Version. Indicates that the
operation failed because the protocol version supplied in the operation failed because the protocol version supplied in the
query message is not supported. query message is not supported.
0x12: Error - Unsupported Control Code. Indicates that the 0x12: Error - Unsupported Control Code. Indicates that the
skipping to change at page 23, line 37 skipping to change at page 24, line 10
administratively released. administratively released.
0x1C: Error - Invalid Message. Indicates that the operation 0x1C: Error - Invalid Message. Indicates that the operation
failed because the received query message was malformed. failed because the received query message was malformed.
0x1D: Error - Protocol Error. Indicates that the operation 0x1D: Error - Protocol Error. Indicates that the operation
failed because a protocol error was found in the received query failed because a protocol error was found in the received query
message. message.
Message Length: Set to the total length of this message in bytes, Message Length: Set to the total length of this message in bytes,
including the Version, Flags, Control Code, and Message Length including the Version, Flags, Control Code, and Message Length fields
fields. as well as the TLV Block, if any.
DFlags: The format of the DFlags field is shown below. DFlags: The format of the DFlags field is shown below.
+-+-+-+-+ +-+-+-+-+
|X|B|0|0| |X|B|0|0|
+-+-+-+-+ +-+-+-+-+
Loss Measurement Message Flags Data Format Flags
The meanings of the DFlags bits are: The meanings of the DFlags bits are:
X: Extended counter format indicator. Indicates the use of X: Extended counter format indicator. Indicates the use of
extended (64-bit) counter values. Initialized to 1 upon creation extended (64-bit) counter values. Initialized to 1 upon creation
(and prior to transmission) of an LM Query and copied from an LM (and prior to transmission) of an LM Query and copied from an LM
Query to an LM response. Set to 0 when the LM message is Query to an LM response. Set to 0 when the LM message is
transmitted or received over an interface that writes 32-bit transmitted or received over an interface that writes 32-bit
counter values. counter values.
B: Octet (byte) count. When set to 1, indicates that the Counter B: Octet (byte) count. When set to 1, indicates that the Counter
1-4 fields represent octet counts. The octet count applies to all 1-4 fields represent octet counts. The octet count applies to all
packets within the LM scope (Section 2.9.9), and the octet count packets within the LM scope (Section 2.9.9), and the octet count
of a packet sent or received over a channel includes the total of a packet sent or received over a channel includes the total
length of that packet (but excludes headers, labels or framing of length of that packet (but excludes headers, labels, or framing of
the channel itself). When set to 0, indicates that the Counter the channel itself). When set to 0, indicates that the Counter
1-4 fields represent packet counts. 1-4 fields represent packet counts.
0: Set to 0. 0: Set to 0.
Origin Timestamp Format: The format of the Origin Timestamp field, as Origin Timestamp Format: The format of the Origin Timestamp field, as
specified in Section 3.4. specified in Section 3.4.
Session Identifier: Set arbitrarily in a query and copied in the Session Identifier: Set arbitrarily in a query and copied in the
response, if any. This field uniquely identifies a measurement response, if any. This field uniquely identifies a measurement
skipping to change at page 24, line 47 skipping to change at page 25, line 20
message. message.
Counter 1-4: Referring to Section 2.2, when a query is sent from A, Counter 1-4: Referring to Section 2.2, when a query is sent from A,
Counter 1 is set to A_TxP and the other counter fields are set to 0. Counter 1 is set to A_TxP and the other counter fields are set to 0.
When the query is received at B, Counter 2 is set to B_RxP. At this When the query is received at B, Counter 2 is set to B_RxP. At this
point, B copies Counter 1 to Counter 3 and Counter 2 to Counter 4, point, B copies Counter 1 to Counter 3 and Counter 2 to Counter 4,
and re-initializes Counter 1 and Counter 2 to 0. When B transmits and re-initializes Counter 1 and Counter 2 to 0. When B transmits
the response, Counter 1 is set to B_TxP. When the response is the response, Counter 1 is set to B_TxP. When the response is
received at A, Counter 2 is set to A_RxP. received at A, Counter 2 is set to A_RxP.
The mapping of counter types such as A_TxP to the counter fields 1-4 The mapping of counter types such as A_TxP to the Counter 1-4 fields
is designed to ensure that transmit counter values are always written is designed to ensure that transmit counter values are always written
at the same fixed offset in the packet, and likewise for receive at the same fixed offset in the packet, and likewise for receive
counters. This property may be important for hardware processing. counters. This property may be important for hardware processing.
When a 32-bit counter value is written to one of the counter fields, When a 32-bit counter value is written to one of the counter fields,
that value SHALL be written to the low-order 32 bits of the field; that value SHALL be written to the low-order 32 bits of the field;
the high-order 32 bits of the field MUST, in this case, be set to 0. the high-order 32 bits of the field MUST, in this case, be set to 0.
TLV Block: Zero or more TLV fields. TLV Block: Zero or more TLV fields.
skipping to change at page 25, line 38 skipping to change at page 26, line 27
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp 4 | | Timestamp 4 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~ ~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Delay Measurement Message Format Delay Measurement Message Format
The meanings of the fields are summarized in the following table. The meanings of the fields are summarized in the following table.
Field Meaning Field Meaning
--------------------- ----------------------------------------------- --------------------- -----------------------------------------------
Version Protocol version Version Protocol version
Flags Message control flags Flags Message control flags
Control Code Code identifying the query or response type Control Code Code identifying the query or response type
Message Length Total length of this message in bytes Message Length Total length of this message in bytes
QTF Querier timestamp format QTF Querier timestamp format
skipping to change at page 26, line 35 skipping to change at page 27, line 11
possible values for the remaining fields are as follows. possible values for the remaining fields are as follows.
Version: Currently set to 0. Version: Currently set to 0.
Flags: As specified in Section 3.1. The T flag in a DM message is Flags: As specified in Section 3.1. The T flag in a DM message is
set to 1. set to 1.
Control Code: As specified in Section 3.1. Control Code: As specified in Section 3.1.
Message Length: Set to the total length of this message in bytes, Message Length: Set to the total length of this message in bytes,
including the Version, Flags, Control Code, and Message Length including the Version, Flags, Control Code, and Message Length fields
fields. as well as the TLV Block, if any.
Querier Timestamp Format: The format of the timestamp values written Querier Timestamp Format: The format of the timestamp values written
by the querier, as specified in Section 3.4. by the querier, as specified in Section 3.4.
Responder Timestamp Format: The format of the timestamp values Responder Timestamp Format: The format of the timestamp values
written by the responder, as specified in Section 3.4. written by the responder, as specified in Section 3.4.
Responder's Preferred Timestamp Format: The timestamp format Responder's Preferred Timestamp Format: The timestamp format
preferred by the responder, as specified in Section 3.4. preferred by the responder, as specified in Section 3.4.
skipping to change at page 27, line 4 skipping to change at page 27, line 29
Responder's Preferred Timestamp Format: The timestamp format Responder's Preferred Timestamp Format: The timestamp format
preferred by the responder, as specified in Section 3.4. preferred by the responder, as specified in Section 3.4.
Session Identifier: As specified in Section 3.1. Session Identifier: As specified in Section 3.1.
DS: As specified in Section 3.1. DS: As specified in Section 3.1.
Timestamp 1-4: Referring to Section 2.4, when a query is sent from A, Timestamp 1-4: Referring to Section 2.4, when a query is sent from A,
Timestamp 1 is set to T1 and the other timestamp fields are set to 0. Timestamp 1 is set to T1 and the other timestamp fields are set to 0.
When the query is received at B, Timestamp 2 is set to T2. At this When the query is received at B, Timestamp 2 is set to T2. At this
point, B copies Timestamp 1 to Timestamp 3 and Timestamp 2 to point, B copies Timestamp 1 to Timestamp 3 and Timestamp 2 to
Timestamp 4, and re-initializes Timestamp 1 and Timestamp 2 to 0. Timestamp 4, and re-initializes Timestamp 1 and Timestamp 2 to 0.
When B transmits the response, Timestamp 1 is set to T3. When the When B transmits the response, Timestamp 1 is set to T3. When the
response is received at A, Timestamp 2 is set to T4. The actual response is received at A, Timestamp 2 is set to T4. The actual
formats of the timestamp fields written by A and B are indicated by formats of the timestamp fields written by A and B are indicated by
the Querier Timestamp Format and Responder Timestamp Format fields the Querier Timestamp Format and Responder Timestamp Format fields
respectively. respectively.
The mapping of timestamps to the timestamp fields 1-4 is designed to The mapping of timestamps to the Timestamp 1-4 fields is designed to
ensure that transmit timestamps are always written at the same fixed ensure that transmit timestamps are always written at the same fixed
offset in the packet, and likewise for receive timestamps. This offset in the packet, and likewise for receive timestamps. This
property is important for hardware processing. property is important for hardware processing.
TLV Block: Zero or more TLV fields. TLV Block: Zero or more TLV fields.
3.3. Combined Loss/Delay Measurement Message Format 3.3. Combined Loss/Delay Measurement Message Format
The format of a combined Loss and Delay Measurement message, which The format of a combined Loss and Delay Measurement message, which
follows the Associated Channel Header (ACH), is as follows: follows the Associated Channel Header (ACH), is as follows:
skipping to change at page 28, line 37 skipping to change at page 28, line 37
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter 4 | | Counter 4 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TLV Block ~ ~ TLV Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Loss/Delay Measurement Message Format Loss/Delay Measurement Message Format
The fields of this message have the same meanings as the The fields of this message have the same meanings as the
corresponding fields in the LM and DM message formats, except that corresponding fields in the LM and DM message formats, except that
the roles of the OTF and Origin Timestamp fields for LM are here the roles of the OTF and Origin Timestamp fields for LM are here
played by the QTF and Timestamp 1 fields, respectively. played by the QTF and Timestamp 1 fields, respectively.
3.4. Timestamp Field Formats 3.4. Timestamp Field Formats
The following timestamp format field values are specified in this The following timestamp format field values are specified in this
document: document:
skipping to change at page 29, line 22 skipping to change at page 29, line 22
[RFC5905]. This format consists of a 32-bit seconds field [RFC5905]. This format consists of a 32-bit seconds field
followed by a 32-bit fractional seconds field, so that it can be followed by a 32-bit fractional seconds field, so that it can be
regarded as a fixed-point 64-bit quantity. regarded as a fixed-point 64-bit quantity.
3: Low-order 64 bits of the IEEE 1588-2008 (1588v2) Precision Time 3: Low-order 64 bits of the IEEE 1588-2008 (1588v2) Precision Time
Protocol timestamp format [IEEE1588]. This truncated format Protocol timestamp format [IEEE1588]. This truncated format
consists of a 32-bit seconds field followed by a 32-bit consists of a 32-bit seconds field followed by a 32-bit
nanoseconds field, and is the same as the IEEE 1588v1 timestamp nanoseconds field, and is the same as the IEEE 1588v1 timestamp
format. format.
Timestamp formats of n < 64 bits in size SHALL be encoded in the 64- Timestamp formats of n < 64 bits in size SHALL be encoded in the
bit timestamp fields specified in this document using the n high- 64-bit timestamp fields specified in this document using the n high-
order bits of the field. The remaining 64 - n low-order bits in the order bits of the field. The remaining 64 - n low-order bits in the
field SHOULD be set to 0 and MUST be ignored when reading the field. field SHOULD be set to 0 and MUST be ignored when reading the field.
To ensure that it is possible to find an interoperable mode between To ensure that it is possible to find an interoperable mode between
implementations it is necessary to select one timestamp format as the implementations, it is necessary to select one timestamp format as
default. The timestamp format chosen as the default is the truncated the default. The timestamp format chosen as the default is the
IEEE 1588 PTP format (format code 3 in the list above); this format truncated IEEE 1588 PTP format (format code 3 in the list above);
MUST be supported. The rationale for this choice is discussed in this format MUST be supported. The rationale for this choice is
Appendix A. Implementations SHOULD also be capable of reading discussed in Appendix A. Implementations SHOULD also be capable of
timestamps written in NTPv4 64-bit format and reconciling them reading timestamps written in NTPv4 64-bit format and reconciling
internally with PTP timestamps for measurement purposes. Support for them internally with PTP timestamps for measurement purposes.
other timestamp formats is OPTIONAL. Support for other timestamp formats is OPTIONAL.
The implementation MUST make clear which timestamp formats it The implementation MUST make clear which timestamp formats it
supports and the extent of its support for computation with and supports and the extent of its support for computation with and
reconciliation of different formats for measurement purposes. reconciliation of different formats for measurement purposes.
3.5. TLV Objects 3.5. TLV Objects
The TLV Block in LM and DM messages consists of zero or more objects The TLV Block in LM and DM messages consists of zero or more objects
with the following format: with the following format:
skipping to change at page 31, line 19 skipping to change at page 31, line 19
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address Family | | Type | Length | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~ ~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Addressing Object Format Addressing Object Format
The Address Family field indicates the type of the address, and SHALL The Address Family field indicates the type of the address, and it
be set to one of the assigned values in the IANA Address Family SHALL be set to one of the assigned values in the "IANA Address
Numbers registry. Family Numbers" registry.
The Source and Destination address objects indicate the addresses of The Source and Destination Address objects indicate the addresses of
the sender and the intended recipient of the message, respectively. the sender and the intended recipient of the message, respectively.
The Source Address of a query message SHOULD be used as the The Source Address of a query message SHOULD be used as the
destination for an out-of-band response unless some other out-of-band destination for an out-of-band response unless some other out-of-band
response mechanism has been configured, and unless a Return Address response mechanism has been configured, and unless a Return Address
object is present, in which case the Return Address specifies the object is present, in which case the Return Address specifies the
target of the response. The Return Address object MUST NOT appear in target of the response. The Return Address object MUST NOT appear in
a response. a response.
3.5.3. Loopback Request 3.5.3. Loopback Request
skipping to change at page 31, line 46 skipping to change at page 31, line 46
This object has a Length of 0. This object has a Length of 0.
Upon receiving the reflected query message back from the responder, Upon receiving the reflected query message back from the responder,
the querier MUST NOT retransmit the message. Information that the querier MUST NOT retransmit the message. Information that
uniquely identifies the original query source, such as a Source uniquely identifies the original query source, such as a Source
Address object, can be included to enable the querier to Address object, can be included to enable the querier to
differentiate one of its own loopback queries from a loopback query differentiate one of its own loopback queries from a loopback query
initiated by the far end. initiated by the far end.
This object may be useful, for example, when the querier is This object may be useful, for example, when the querier is
interested only in the round-trip delay metric. In this case no interested only in the round-trip delay metric. In this case, no
support for delay measurement is required at the responder at all, support for delay measurement is required at the responder at all,
other than the ability to recognize a DM query that includes this other than the ability to recognize a DM query that includes this
object and return it unmodified. object and return it unmodified.
3.5.4. Session Query Interval 3.5.4. Session Query Interval
The Value field of the Session Query Interval object is a 32-bit The Value field of the Session Query Interval object is a 32-bit
unsigned integer that specifies a time interval in milliseconds: unsigned integer that specifies a time interval in milliseconds.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Session Query > | Type | Length | Session Query >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
< Interval (ms) | < Interval (ms) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Session Query Interval Object Format Session Query Interval Object Format
skipping to change at page 33, line 5 skipping to change at page 33, line 5
including the SQI object in queries associated with this session. including the SQI object in queries associated with this session.
Similar procedures allow the query rate to be changed during the Similar procedures allow the query rate to be changed during the
course of the session by either the querier or the responder. For course of the session by either the querier or the responder. For
example, to inform the querier of a change in the minimum supported example, to inform the querier of a change in the minimum supported
query interval, the responder begins including a corresponding SQI query interval, the responder begins including a corresponding SQI
object in its responses, and the querier adjusts its query rate if object in its responses, and the querier adjusts its query rate if
necessary and includes a corresponding SQI object in its queries necessary and includes a corresponding SQI object in its queries
until a response is received. until a response is received.
Shorter query intervals (i.e. higher query rates) provide finer Shorter query intervals (i.e., higher query rates) provide finer
measurement granularity at the expense of additional load on measurement granularity at the expense of additional load on
measurement endpoints and the network; see Section 6 for further measurement endpoints and the network; see Section 6 for further
discussion. discussion.
4. Operation 4. Operation
4.1. Operational Overview 4.1. Operational Overview
A loss or delay measurement operation, also called a session, is A loss or delay measurement operation, also called a session, is
controlled by the querier and consists of a sequence of query controlled by the querier and consists of a sequence of query
skipping to change at page 33, line 28 skipping to change at page 33, line 28
request, then the receiving node or nodes will (under normal request, then the receiving node or nodes will (under normal
conditions) generate a response message for each query message conditions) generate a response message for each query message
received, and these responses are also considered part of the received, and these responses are also considered part of the
session. All query and response messages in a session carry a common session. All query and response messages in a session carry a common
session identifier. session identifier.
Measurement sessions are initiated at the discretion of the network Measurement sessions are initiated at the discretion of the network
operator and are terminated either at the operator's request or as operator and are terminated either at the operator's request or as
the result of an error condition. A session may be as brief as a the result of an error condition. A session may be as brief as a
single message exchange, for example when a DM query is used by the single message exchange, for example when a DM query is used by the
operator to "ping" a remote node, or may extend throughout the operator to "ping" a remote node, or it may extend throughout the
lifetime of the channel. lifetime of the channel.
When a session is initiated for which responses are requested, the When a session is initiated for which responses are requested, the
querier SHOULD initialize a timer, called the SessionResponseTimeout, querier SHOULD initialize a timer, called the SessionResponseTimeout,
that indicates how long the querier will wait for a response before that indicates how long the querier will wait for a response before
abandoning the session and notifying the user that a timeout has abandoning the session and notifying the user that a timeout has
occurred. This timer persists for the lifetime of the session and is occurred. This timer persists for the lifetime of the session and is
reset each time a response message for the session is received. reset each time a response message for the session is received.
When a query message is received that requests a response, a variety When a query message is received that requests a response, a variety
of exceptional conditions may arise that prevent the responder from of exceptional conditions may arise that prevent the responder from
generating a response that contains valid measurement data. Such generating a response that contains valid measurement data. Such
conditions fall broadly into two classes: transient exceptions from conditions fall broadly into two classes: transient exceptions from
which recovery is possible, and fatal exceptions that require which recovery is possible and fatal exceptions that require
termination of the session. When an exception arises, the responder termination of the session. When an exception arises, the responder
SHOULD generate a response with an appropriate Notification or Error SHOULD generate a response with an appropriate Notification or Error
control code according as the exception is, respectively, transient control code according to whether the exception is, respectively,
or fatal. When the querier receives an Error response, the session transient or fatal. When the querier receives an Error response, the
MUST be terminated and the user informed. session MUST be terminated and the user informed.
A common example of a transient exception occurs when a new session A common example of a transient exception occurs when a new session
is initiated and the responder requires a period of time to become is initiated and the responder requires a period of time to become
ready before it can begin providing useful responses. The response ready before it can begin providing useful responses. The response
control code corresponding to this situation is Notification - control code corresponding to this situation is Notification -
Initialization In Progress. Typical examples of fatal exceptions are Initialization in Progress. Typical examples of fatal exceptions are
cases where the querier has requested a type of measurement that the cases where the querier has requested a type of measurement that the
responder does not support, or where a query message is malformed. responder does not support or where a query message is malformed.
When initiating a session the querier SHOULD employ the Session Query When initiating a session, the querier SHOULD employ the Session
Interval mechanism (Section 3.5.4) to establish a mutually agreeable Query Interval mechanism (Section 3.5.4) to establish a mutually
query rate with the responder. Responders SHOULD employ rate- agreeable query rate with the responder. Responders SHOULD employ
limiting mechanisms to guard against the possibility of receiving an rate-limiting mechanisms to guard against the possibility of
excessive quantity of query messages. receiving an excessive quantity of query messages.
4.2. Loss Measurement Procedures 4.2. Loss Measurement Procedures
4.2.1. Initiating a Loss Measurement Operation 4.2.1. Initiating a Loss Measurement Operation
An LM operation for a particular channel consists of sending a An LM operation for a particular channel consists of sending a
sequence (LM[1], LM[2], ...) of LM query messages over the channel at sequence (LM[1], LM[2], ...) of LM query messages over the channel at
a specific rate and processing the responses received, if any. As a specific rate and processing the responses received, if any. As
described in Section 2.2, the packet loss associated with the channel described in Section 2.2, the packet loss associated with the channel
during the operation is computed as a delta between successive during the operation is computed as a delta between successive
messages; these deltas can be accumulated to obtain a running total messages; these deltas can be accumulated to obtain a running total
of the packet loss for the channel, or used to derive related metrics of the packet loss for the channel or be used to derive related
such as the average loss rate. metrics such as the average loss rate.
The query message transmission rate MUST be sufficiently high, given The query message transmission rate MUST be sufficiently high, given
the LM message counter size (which can be either 32 or 64 bits) and the LM message counter size (which can be either 32 or 64 bits) and
the speed and minimum packet size of the underlying channel, that the the speed and minimum packet size of the underlying channel, that the
ambiguity condition noted in Section 2.2 cannot arise. The ambiguity condition noted in Section 2.2 cannot arise. In evaluating
implementation SHOULD assume, in evaluating this rate, that the this rate, the implementation SHOULD assume that the counter size is
counter size is 32 bits unless explicitly configured otherwise, or 32 bits unless explicitly configured otherwise or unless (in the case
unless (in the case of a bidirectional channel) all local and remote of a bidirectional channel) all local and remote interfaces involved
interfaces involved in the LM operation are known to be 64-bit- in the LM operation are known to be 64-bit-capable, which can be
capable, which can be inferred from the value of the X flag in an LM inferred from the value of the X flag in an LM response.
response.
4.2.2. Transmitting a Loss Measurement Query 4.2.2. Transmitting a Loss Measurement Query
When transmitting an LM Query, the Version field MUST be set to 0. When transmitting an LM Query, the Version field MUST be set to 0.
The R flag MUST be set to 0. The T flag SHALL be set to 1 if, and The R flag MUST be set to 0. The T flag SHALL be set to 1 if, and
only if, the measurement is specific to a particular traffic class, only if, the measurement is specific to a particular traffic class,
in which case the DS field SHALL identify that traffic class. in which case the DS field SHALL identify that traffic class.
The X flag MUST be set to 1 if the transmitting interface writes 64- The X flag MUST be set to 1 if the transmitting interface writes
bit LM counters, and otherwise MUST be set to 0 to indicate that 32- 64-bit LM counters and otherwise MUST be set to 0 to indicate that
bit counters are written. The B flag SHALL be set to 1 to indicate 32-bit counters are written. The B flag SHALL be set to 1 to
that the counter fields contain octet counts, or to 0 to indicate indicate that the counter fields contain octet counts or to 0 to
packet counts. indicate packet counts.
The Control Code field MUST be set to one of the values for Query The Control Code field MUST be set to one of the values for Query
messages listed in Section 3.1; if the channel is unidirectional, messages listed in Section 3.1; if the channel is unidirectional,
this field MUST NOT be set to 0x0 (Query: in-band response this field MUST NOT be set to 0x0 (Query: In-band Response
requested). Requested).
The Session Identifier field can be set arbitrarily. The Session Identifier field can be set arbitrarily.
The Origin Timestamp field SHALL be set to the time at which this The Origin Timestamp field SHALL be set to the time at which this
message is transmitted, and the Origin Timestamp Format field MUST be message is transmitted, and the Origin Timestamp Format field MUST be
set to indicate its format, according to Section 3.4. set to indicate its format, according to Section 3.4.
The Counter 1 field SHOULD be set to the total count of units The Counter 1 field SHOULD be set to the total count of units
(packets or octets, according to the B flag) transmitted over the (packets or octets, according to the B flag) transmitted over the
channel prior to this LM Query, or to 0 if this is the beginning of a channel prior to this LM Query, or to 0 if this is the beginning of a
skipping to change at page 35, line 34 skipping to change at page 35, line 34
Counter 3 and Counter 4 fields MUST be set to 0. Counter 3 and Counter 4 fields MUST be set to 0.
4.2.3. Receiving a Loss Measurement Query 4.2.3. Receiving a Loss Measurement Query
Upon receipt of an LM Query message, the Counter 2 field SHOULD be Upon receipt of an LM Query message, the Counter 2 field SHOULD be
set to the total count of units (packets or octets, according to the set to the total count of units (packets or octets, according to the
B flag) received over the channel prior to this LM Query. If the B flag) received over the channel prior to this LM Query. If the
receiving interface writes 32-bit LM counters, the X flag MUST be set receiving interface writes 32-bit LM counters, the X flag MUST be set
to 0. to 0.
At this point the LM Query message must be inspected. If the Control At this point, the LM Query message must be inspected. If the
Code field is set to 0x2 (no response requested), an LM Response Control Code field is set to 0x2 (No Response Requested), an LM
message MUST NOT be transmitted. If the Control Code field is set to Response message MUST NOT be transmitted. If the Control Code field
0x0 (in-band response requested) or 0x1 (out-of-band response is set to 0x0 (In-band Response Requested) or 0x1 (Out-of-band
requested), then an in-band or out-of-band response, respectively, Response Requested), then an in-band or out-of-band response,
SHOULD be transmitted unless this has been prevented by an respectively, SHOULD be transmitted unless this has been prevented by
administrative, security or congestion control mechanism. an administrative, security, or congestion control mechanism.
In the case of a fatal exception that prevents the requested In the case of a fatal exception that prevents the requested
measurement from being made, the error SHOULD be reported, either via measurement from being made, the error SHOULD be reported, via either
a response if one was requested or else as a notification to the a response, if one was requested, or else as a notification to the
user. user.
4.2.4. Transmitting a Loss Measurement Response 4.2.4. Transmitting a Loss Measurement Response
When constructing a Response to an LM Query, the Version field MUST When constructing a Response to an LM Query, the Version field MUST
be set to 0. The R flag MUST be set to 1. The value of the T flag be set to 0. The R flag MUST be set to 1. The value of the T flag
MUST be copied from the LM Query. MUST be copied from the LM Query.
The X flag MUST be set to 0 if the transmitting interface writes 32- The X flag MUST be set to 0 if the transmitting interface writes
bit LM counters; otherwise its value MUST be copied from the LM 32-bit LM counters; otherwise, its value MUST be copied from the LM
Query. The B flag MUST be copied from the LM Query. Query. The B flag MUST be copied from the LM Query.
The Session Identifier, Origin Timestamp, and Origin Timestamp Format The Session Identifier, Origin Timestamp, and Origin Timestamp Format
fields MUST be copied from the LM Query. The Counter 1 and Counter 2 fields MUST be copied from the LM Query. The Counter 1 and Counter 2
fields from the LM Query MUST be copied to the Counter 3 and Counter fields from the LM Query MUST be copied to the Counter 3 and Counter
4 fields, respectively, of the LM Response. 4 fields, respectively, of the LM Response.
The Control Code field MUST be set to one of the values for Response The Control Code field MUST be set to one of the values for Response
messages listed in Section 3.1. The value 0x10 (Unspecified Error) messages listed in Section 3.1. The value 0x10 (Unspecified Error)
SHOULD NOT be used if one of the other more specific error codes is SHOULD NOT be used if one of the other more specific error codes is
skipping to change at page 36, line 34 skipping to change at page 36, line 34
4.2.5. Receiving a Loss Measurement Response 4.2.5. Receiving a Loss Measurement Response
Upon in-band receipt of an LM Response message, the Counter 2 field Upon in-band receipt of an LM Response message, the Counter 2 field
is set to the total count of units received over the channel prior to is set to the total count of units received over the channel prior to
this LM Response. If the receiving interface writes 32-bit LM this LM Response. If the receiving interface writes 32-bit LM
counters, the X flag is set to 0. (Since the life of the LM message counters, the X flag is set to 0. (Since the life of the LM message
in the network has ended at this point, it is up to the receiver in the network has ended at this point, it is up to the receiver
whether these final modifications are made to the packet. If the whether these final modifications are made to the packet. If the
message is to be forwarded on for external post-processing message is to be forwarded on for external post-processing
(Section 2.9.7) then these modifications MUST be made.) (Section 2.9.7), then these modifications MUST be made.)
Upon out-of-band receipt of an LM Response message, the Counter 1 and Upon out-of-band receipt of an LM Response message, the Counter 1 and
Counter 2 fields MUST NOT be used for purposes of loss measurement. Counter 2 fields MUST NOT be used for purposes of loss measurement.
If the Control Code in an LM Response is anything other than 0x1 If the Control Code in an LM Response is anything other than 0x1
(Success), the counter values in the response MUST NOT be used for (Success), the counter values in the response MUST NOT be used for
purposes of loss measurement. If the Control Code indicates an error purposes of loss measurement. If the Control Code indicates an error
condition, or if the response message is invalid, the LM operation condition, or if the response message is invalid, the LM operation
MUST be terminated and an appropriate notification to the user MUST be terminated and an appropriate notification to the user
generated. generated.
skipping to change at page 37, line 16 skipping to change at page 37, line 16
value, and 32-bit arithmetic is carried out using the low-order 32 value, and 32-bit arithmetic is carried out using the low-order 32
bits of each counter value. bits of each counter value.
Note that the semantics of the X flag allow all devices to Note that the semantics of the X flag allow all devices to
interoperate regardless of their counter size support. Thus, an interoperate regardless of their counter size support. Thus, an
implementation MUST NOT generate an error response based on the value implementation MUST NOT generate an error response based on the value
of this flag. of this flag.
4.2.7. Quality of Service 4.2.7. Quality of Service
The TC field of the LSE corresponding to the channel (e.g. LSP) The TC field of the LSE corresponding to the channel (e.g., LSP)
being measured SHOULD be set to a traffic class equal to or better being measured SHOULD be set to a traffic class equal to or better
than the best TC within the measurement scope to minimize the chance than the best TC within the measurement scope to minimize the chance
of out-of-order conditions. of out-of-order conditions.
4.2.8. G-ACh Packets 4.2.8. G-ACh Packets
By default, direct LM MUST exclude packets transmitted and received By default, direct LM MUST exclude packets transmitted and received
over the Generic Associated Channel (G-ACh). An implementation MAY over the Generic Associated Channel (G-ACh). An implementation MAY
provide the means to alter the direct LM scope to include some or all provide the means to alter the direct LM scope to include some or all
G-ACh messages. Care must be taken when altering the LM scope to G-ACh messages. Care must be taken when altering the LM scope to
skipping to change at page 37, line 42 skipping to change at page 37, line 42
test messages generated for this purpose, or of some other class of test messages generated for this purpose, or of some other class of
packets deemed to provide a good proxy for data packets flowing over packets deemed to provide a good proxy for data packets flowing over
the channel. The specification of test protocols and proxy packets the channel. The specification of test protocols and proxy packets
is outside the scope of this document, but some guidelines are is outside the scope of this document, but some guidelines are
discussed below. discussed below.
An identifier common to both the test or proxy messages and the LM An identifier common to both the test or proxy messages and the LM
messages may be required to make correlation possible. The combined messages may be required to make correlation possible. The combined
value of the Session Identifier and DS fields SHOULD be used for this value of the Session Identifier and DS fields SHOULD be used for this
purpose when possible. That is, test messages in this case will purpose when possible. That is, test messages in this case will
include a 32-bit field which can carry the value of the combined include a 32-bit field that can carry the value of the combined
Session Identifier + DS field present in LM messages. When TC- Session Identifier + DS field present in LM messages. When TC-
specific LM is conducted, the DS field of the LSE in the label stack specific LM is conducted, the DS field of the LSE in the label stack
of a test message corresponding to the channel (e.g. LSP) over which of a test message corresponding to the channel (e.g., LSP) over which
the message is sent MUST correspond to the DS value in the associated the message is sent MUST correspond to the DS value in the associated
LM messages. LM messages.
A separate test message protocol SHOULD include a timeout value in A separate test message protocol SHOULD include a timeout value in
its messages that informs the responder when to discard any state its messages that informs the responder when to discard any state
associated with a specific test. associated with a specific test.
4.2.10. Message Loss and Packet Misorder Conditions 4.2.10. Message Loss and Packet Misorder Conditions
Because an LM operation consists of a message sequence with state Because an LM operation consists of a message sequence with state
skipping to change at page 38, line 26 skipping to change at page 38, line 26
The first kind of anomaly that may occur is that one or more LM The first kind of anomaly that may occur is that one or more LM
messages may be lost in transit. The effect of such loss is that messages may be lost in transit. The effect of such loss is that
when an LM Response is next received at the querier, an unambiguous when an LM Response is next received at the querier, an unambiguous
interpretation of the counter values it contains may be impossible, interpretation of the counter values it contains may be impossible,
for the reasons described at the end of Section 2.2. Whether this is for the reasons described at the end of Section 2.2. Whether this is
so depends on the number of messages lost and the other variables so depends on the number of messages lost and the other variables
mentioned in that section, such as the LM message rate and the mentioned in that section, such as the LM message rate and the
channel parameters. channel parameters.
Another possibility is that LM messages are misordered in transit, so Another possibility is that LM messages are misordered in transit, so
that for instance the response to LM[n] is received prior to the that, for instance, the response to LM[n] is received prior to the
response to LM[n-1]. A typical implementation will discard the late response to LM[n-1]. A typical implementation will discard the late
response to LM[n-1], so that the effect is the same as the case of a response to LM[n-1], so that the effect is the same as the case of a
lost message. lost message.
Finally, LM is subject to the possibility that data packets are Finally, LM is subject to the possibility that data packets are
misordered relative to LM messages. This condition can result, for misordered relative to LM messages. This condition can result, for
example, in a transmit count of 100 and a corresponding receive count example, in a transmit count of 100 and a corresponding receive count
of 101. The effect here is that the A_TxLoss[n-1,n] value (for of 101. The effect here is that the A_TxLoss[n-1,n] value (for
example) for a given measurement interval will appear to be extremely example) for a given measurement interval will appear to be extremely
(if not impossibly) large. The other case, where an LM message (if not impossibly) large. The other case, where an LM message
arrives earlier than some of the packets, simply results in those arrives earlier than some of the packets, simply results in those
packets being counted as lost. packets being counted as lost.
An implementation SHOULD identify a threshold value that indicates An implementation SHOULD identify a threshold value that indicates
the upper bound of lost packets measured in a single computation the upper bound of lost packets measured in a single computation
beyond which the interval is considered unmeasurable. This is called beyond which the interval is considered unmeasurable. This is called
the MaxLMIntervalLoss threshold. It is clear that this threshold the "MaxLMIntervalLoss threshold". It is clear that this threshold
should be no higher than the maximum number of packets (or bytes) the should be no higher than the maximum number of packets (or bytes) the
channel is capable of transmitting over the interval, but it may be channel is capable of transmitting over the interval, but it may be
lower. Upon encountering an unmeasurable interval, the LM state lower. Upon encountering an unmeasurable interval, the LM state
(i.e. data values from the last LM message received) SHOULD be (i.e., data values from the last LM message received) SHOULD be
discarded. discarded.
With regard to lost LM messages, the MaxLMInterval (see Section 2.2) With regard to lost LM messages, the MaxLMInterval (see Section 2.2)
indicates the maximum amount of time that can elapse before the LM indicates the maximum amount of time that can elapse before the LM
state is discarded. If some messages are lost, but a message is state is discarded. If some messages are lost, but a message is
subsequently received within MaxLMInterval, its timestamp or sequence subsequently received within MaxLMInterval, its timestamp or sequence
number will quantify the loss, and it MAY still be used for number will quantify the loss, and it MAY still be used for
measurement, although the measurement interval will in this case be measurement, although the measurement interval will in this case be
longer than usual. longer than usual.
skipping to change at page 39, line 25 skipping to change at page 39, line 25
4.3. Delay Measurement Procedures 4.3. Delay Measurement Procedures
4.3.1. Transmitting a Delay Measurement Query 4.3.1. Transmitting a Delay Measurement Query
When transmitting a DM Query, the Version and Reserved fields MUST be When transmitting a DM Query, the Version and Reserved fields MUST be
set to 0. The R flag MUST be set to 0, the T flag MUST be set to 1, set to 0. The R flag MUST be set to 0, the T flag MUST be set to 1,
and the remaining flag bits MUST be set to 0. and the remaining flag bits MUST be set to 0.
The Control Code field MUST be set to one of the values for Query The Control Code field MUST be set to one of the values for Query
messages listed in Section 3.1; if the channel is unidirectional, messages listed in Section 3.1; if the channel is unidirectional,
this field MUST NOT be set to 0x0 (Query: in-band response this field MUST NOT be set to 0x0 (Query: In-band Response
requested). Requested).
The Querier Timestamp Format field MUST be set to the timestamp The Querier Timestamp Format field MUST be set to the timestamp
format used by the querier when writing timestamp fields in this format used by the querier when writing timestamp fields in this
message; the possible values for this field are listed in message; the possible values for this field are listed in
Section 3.4. The Responder Timestamp Format and Responder's Section 3.4. The Responder Timestamp Format and Responder's
Preferred Timestamp Format fields MUST be set to 0. Preferred Timestamp Format fields MUST be set to 0.
The Session Identifier field can be set arbitrarily. The DS field The Session Identifier field can be set arbitrarily. The DS field
MUST be set to the traffic class being measured. MUST be set to the traffic class being measured.
skipping to change at page 39, line 49 skipping to change at page 39, line 49
Timestamp Format field. The Timestamp 2 field MUST be set to 0. If Timestamp Format field. The Timestamp 2 field MUST be set to 0. If
a response was previously received in this measurement session, the a response was previously received in this measurement session, the
Timestamp 1 and Timestamp 2 fields of the most recent such response Timestamp 1 and Timestamp 2 fields of the most recent such response
MAY be copied to the Timestamp 3 and Timestamp 4 fields, MAY be copied to the Timestamp 3 and Timestamp 4 fields,
respectively, of this query; otherwise, the Timestamp 3 and Timestamp respectively, of this query; otherwise, the Timestamp 3 and Timestamp
4 fields MUST be set to 0. 4 fields MUST be set to 0.
4.3.2. Receiving a Delay Measurement Query 4.3.2. Receiving a Delay Measurement Query
Upon receipt of a DM Query message, the Timestamp 2 field SHOULD be Upon receipt of a DM Query message, the Timestamp 2 field SHOULD be
set to the time at which this DM Query is received. set to the time at which this DM Query was received.
At this point the DM Query message must be inspected. If the Control At this point, the DM Query message must be inspected. If the
Code field is set to 0x2 (no response requested), a DM Response Control Code field is set to 0x2 (No Response Requested), a DM
message MUST NOT be transmitted. If the Control Code field is set to Response message MUST NOT be transmitted. If the Control Code field
0x0 (in-band response requested) or 0x1 (out-of-band response is set to 0x0 (In-band Response Requested) or 0x1 (Out-of-band
requested), then an in-band or out-of-band response, respectively, Response Requested), then an in-band or out-of-band response,
SHOULD be transmitted unless this has been prevented by an respectively, SHOULD be transmitted unless this has been prevented by
administrative, security or congestion control mechanism. an administrative, security, or congestion control mechanism.
In the case of a fatal exception that prevents the requested In the case of a fatal exception that prevents the requested
measurement from being made, the error SHOULD be reported, either via measurement from being made, the error SHOULD be reported, via either
a response if one was requested or else as a notification to the a response, if one was requested, or else as a notification to the
user. user.
4.3.3. Transmitting a Delay Measurement Response 4.3.3. Transmitting a Delay Measurement Response
When constructing a Response to a DM Query, the Version and Reserved When constructing a Response to a DM Query, the Version and Reserved
fields MUST be set to 0. The R flag MUST be set to 1, the T flag fields MUST be set to 0. The R flag MUST be set to 1, the T flag
MUST be set to 1, and the remaining flag bits MUST be set to 0. MUST be set to 1, and the remaining flag bits MUST be set to 0.
The Session Identifier and Querier Timestamp Format (QTF) fields MUST The Session Identifier and Querier Timestamp Format (QTF) fields MUST
be copied from the DM Query. The Timestamp 1 and Timestamp 2 fields be copied from the DM Query. The Timestamp 1 and Timestamp 2 fields
from the DM Query MUST be copied to the Timestamp 3 and Timestamp 4 from the DM Query MUST be copied to the Timestamp 3 and Timestamp 4
fields, respectively, of the DM Response. fields, respectively, of the DM Response.
The Responder Timestamp Format (RTF) field MUST be set to the The Responder Timestamp Format (RTF) field MUST be set to the
timestamp format used by the responder when writing timestamp fields timestamp format used by the responder when writing timestamp fields
in this message, i.e. Timestamp 4 and (if applicable) Timestamp 1; in this message, i.e., Timestamp 4 and (if applicable) Timestamp 1;
the possible values for this field are listed in Section 3.4. the possible values for this field are listed in Section 3.4.
Furthermore, the RTF field MUST be set equal either to the QTF or the Furthermore, the RTF field MUST be set equal to either the QTF or the
RPTF field. See Section 4.3.5 for guidelines on selection of the RPTF field. See Section 4.3.5 for guidelines on the selection of the
value for this field. value for this field.
The Responder's Preferred Timestamp Format (RPTF) field MUST be set The Responder's Preferred Timestamp Format (RPTF) field MUST be set
to one of the values listed in Section 3.4 and SHOULD be set to to one of the values listed in Section 3.4 and SHOULD be set to
indicate the timestamp format with which the responder can provide indicate the timestamp format with which the responder can provide
the best accuracy for purposes of delay measurement. the best accuracy for purposes of delay measurement.
The Control Code field MUST be set to one of the values for Response The Control Code field MUST be set to one of the values for Response
messages listed in Section 3.1. The value 0x10 (Unspecified Error) messages listed in Section 3.1. The value 0x10 (Unspecified Error)
SHOULD NOT be used if one of the other more specific error codes is SHOULD NOT be used if one of the other more specific error codes is
skipping to change at page 41, line 10 skipping to change at page 41, line 13
set to 0. In either case, the Timestamp 2 field MUST be set to 0. set to 0. In either case, the Timestamp 2 field MUST be set to 0.
If the response is transmitted in-band and the Control Code in the If the response is transmitted in-band and the Control Code in the
message is 0x1 (Success), then the Timestamp 1 and Timestamp 4 fields message is 0x1 (Success), then the Timestamp 1 and Timestamp 4 fields
MUST have the same format, which will be the format indicated in the MUST have the same format, which will be the format indicated in the
Responder Timestamp Format field. Responder Timestamp Format field.
4.3.4. Receiving a Delay Measurement Response 4.3.4. Receiving a Delay Measurement Response
Upon in-band receipt of a DM Response message, the Timestamp 2 field Upon in-band receipt of a DM Response message, the Timestamp 2 field
is set to the time at which this DM Response is received. (Since the is set to the time at which this DM Response was received. (Since
life of the DM message in the network has ended at this point, it is the life of the DM message in the network has ended at this point, it
up to the receiver whether this final modification is made to the is up to the receiver whether this final modification is made to the
packet. If the message is to be forwarded on for external post- packet. If the message is to be forwarded on for external post-
processing (Section 2.9.7) then these modifications MUST be made.) processing (Section 2.9.7), then these modifications MUST be made.)
Upon out-of-band receipt of a DM Response message, the Timestamp 1 Upon out-of-band receipt of a DM Response message, the Timestamp 1
and Timestamp 2 fields MUST NOT be used for purposes of delay and Timestamp 2 fields MUST NOT be used for purposes of delay
measurement. measurement.
If the Control Code in a DM Response is anything other than 0x1 If the Control Code in a DM Response is anything other than 0x1
(Success), the timestamp values in the response MUST NOT be used for (Success), the timestamp values in the response MUST NOT be used for
purposes of delay measurement. If the Control Code indicates an purposes of delay measurement. If the Control Code indicates an
error condition, or if the response message is invalid, the DM error condition, or if the response message is invalid, the DM
operation MUST be terminated and an appropriate notification to the operation MUST be terminated and an appropriate notification to the
skipping to change at page 42, line 30 skipping to change at page 42, line 33
o All DM Responses are transmitted with the same RTF, and the RPTF o All DM Responses are transmitted with the same RTF, and the RPTF
is always set equal to the RTF; is always set equal to the RTF;
o All DM Responses received with RTF not equal to QTF are discarded; o All DM Responses received with RTF not equal to QTF are discarded;
o On a unidirectional channel, all DM Queries received with QTF not o On a unidirectional channel, all DM Queries received with QTF not
equal to the supported format are discarded. equal to the supported format are discarded.
4.3.6. Quality of Service 4.3.6. Quality of Service
The TC field of the LSE corresponding to the channel (e.g. LSP) The TC field of the LSE corresponding to the channel (e.g., LSP)
being measured MUST be set to the value that corresponds to the DS being measured MUST be set to the value that corresponds to the DS
field in the DM message. field in the DM message.
4.4. Combined Loss/Delay Measurement Procedures 4.4. Combined Loss/Delay Measurement Procedures
The combined LM/DM message defined in Section 3.3 allows loss and The combined LM/DM message defined in Section 3.3 allows loss and
delay measurement to be carried out simultaneously. This message delay measurement to be carried out simultaneously. This message
SHOULD be treated as an LM message which happens to carry additional SHOULD be treated as an LM message that happens to carry additional
timestamp data, with the timestamp fields processed as per delay timestamp data, with the timestamp fields processed as per delay
measurement procedures. measurement procedures.
5. Implementation Disclosure Requirements 5. Implementation Disclosure Requirements
This section summarizes the requirements placed on implementations This section summarizes the requirements placed on implementations
for capabilities disclosure. The purpose of these requirements is to for capabilities disclosure. The purpose of these requirements is to
ensure that end users have a clear understanding of implementation ensure that end users have a clear understanding of implementation
capabilities and characteristics that have a direct impact on how capabilities and characteristics that have a direct impact on how
loss and delay measurement mechanisms function in specific loss and delay measurement mechanisms function in specific
skipping to change at page 43, line 34 skipping to change at page 43, line 37
o LM-COUNTERS: Whether 64-bit counters are supported. o LM-COUNTERS: Whether 64-bit counters are supported.
o LM-ACCURACY: The expected measurement accuracy levels for the o LM-ACCURACY: The expected measurement accuracy levels for the
supported forms of LM, and the expected impact of exception supported forms of LM, and the expected impact of exception
conditions such as lost and misordered messages. conditions such as lost and misordered messages.
o LM-SYNC: The implementation's behavior in regard to the o LM-SYNC: The implementation's behavior in regard to the
synchronization conditions discussed in Section 2.9.8. synchronization conditions discussed in Section 2.9.8.
o LM-SCOPE: The supported LM scopes (Section 2.9.9 and o LM-SCOPE: The supported LM scopes (Sections 2.9.9 and 4.2.8).
Section 4.2.8).
o DM-ACCURACY: The expected measurement accuracy levels for the o DM-ACCURACY: The expected measurement accuracy levels for the
supported forms of DM. supported forms of DM.
o DM-TS-FORMATS: The supported timestamp formats and the extent of o DM-TS-FORMATS: The supported timestamp formats and the extent of
support for computation with and reconciliation of different support for computation with and reconciliation of different
formats. formats.
6. Congestion Considerations 6. Congestion Considerations
An MPLS network may be traffic-engineered in such a way that the An MPLS network may be traffic-engineered in such a way that the
bandwidth required both for client traffic and for control, bandwidth required both for client traffic and for control,
management and OAM traffic is always available. The following management, and OAM traffic is always available. The following
congestion considerations therefore apply only when this is not the congestion considerations therefore apply only when this is not the
case. case.
The proactive generation of Loss Measurement and Delay Measurement The proactive generation of Loss Measurement and Delay Measurement
messages for purposes of monitoring the performance of an MPLS messages for purposes of monitoring the performance of an MPLS
channel naturally results in a degree of additional load placed on channel naturally results in a degree of additional load placed on
both the network and the terminal nodes of the channel. When both the network and the terminal nodes of the channel. When
configuring such monitoring, operators should be mindful of the configuring such monitoring, operators should be mindful of the
overhead involved and should choose transmit rates that do not stress overhead involved and should choose transmit rates that do not stress
network resources unduly; such choices must be informed by the network resources unduly; such choices must be informed by the
deployment context. In case of slower links or lower-speed devices, deployment context. In case of slower links or lower-speed devices,
for example, lower Loss Measurement message rates can be chosen, up for example, lower Loss Measurement message rates can be chosen, up
to the limits noted at the end of Section 2.2. to the limits noted at the end of Section 2.2.
In general, lower measurement message rates place less load on the In general, lower measurement message rates place less load on the
network at the expense of reduced granularity. For delay measurement network at the expense of reduced granularity. For delay
this reduced granularity translates to a greater possibility that the measurement, this reduced granularity translates to a greater
delay associated with a channel temporarily exceeds the expected possibility that the delay associated with a channel temporarily
threshold without detection. For loss measurement, it translates to exceeds the expected threshold without detection. For loss
a larger gap in loss information in case of exceptional circumstances measurement, it translates to a larger gap in loss information in
such as lost LM messages or misordered packets. case of exceptional circumstances such as lost LM messages or
misordered packets.
When carrying out a sustained measurement operation such as an LM When carrying out a sustained measurement operation such as an LM
operation or continuous pro-active DM operation, the querier SHOULD operation or continuous proactive DM operation, the querier SHOULD
take note of the number of lost measurement messages (queries for take note of the number of lost measurement messages (queries for
which a response is never received) and set a corresponding which a response is never received) and set a corresponding
Measurement Message Loss Threshold. If this threshold is exceeded, Measurement Message Loss Threshold. If this threshold is exceeded,
the measurement operation SHOULD be suspended so as not to exacerbate the measurement operation SHOULD be suspended so as not to exacerbate
the possible congestion condition. This suspension SHOULD be the possible congestion condition. This suspension SHOULD be
accompanied by an appropriate notification to the user so that the accompanied by an appropriate notification to the user so that the
condition can be investigated and corrected. condition can be investigated and corrected.
From the receiver perspective, the main consideration is the From the receiver perspective, the main consideration is the
possibility of receiving an excessive quantity of measurement possibility of receiving an excessive quantity of measurement
messages. An implementation SHOULD employ a mechanism such as rate- messages. An implementation SHOULD employ a mechanism such as rate-
limiting to guard against the effects of this case. limiting to guard against the effects of this case.
7. Manageability Considerations 7. Manageability Considerations
The measurement protocols described in this document are intended to The measurement protocols described in this document are intended to
serve as infrastructure to support a wide range of higher-level serve as infrastructure to support a wide range of higher-level
monitoring and diagnostic applications, from simple command-line monitoring and diagnostic applications, from simple command-line
diagnostic tools to comprehensive network performance monitoring and diagnostic tools to comprehensive network performance monitoring and
analysis packages. The specific mechanisms and considerations for analysis packages. The specific mechanisms and considerations for
protocol configuration, initialization and reporting thus depend on protocol configuration, initialization, and reporting thus depend on
the nature of the application. the nature of the application.
In the case of on-demand diagnostics, the diagnostic application may In the case of on-demand diagnostics, the diagnostic application may
provide parameters such as the measurement type, the channel, the provide parameters such as the measurement type, the channel, the
query rate, and the test duration when initiating the diagnostic; query rate, and the test duration when initiating the diagnostic;
results and exception conditions are then reported directly to the results and exception conditions are then reported directly to the
application. The system may discard the statistics accumulated application. The system may discard the statistics accumulated
during the test after the results have been reported, or retain them during the test after the results have been reported or retain them
to provide a historical measurement record. to provide a historical measurement record.
Alternatively, measurement configuration may be supplied as part of Alternatively, measurement configuration may be supplied as part of
the channel configuration itself in order to support continuous the channel configuration itself in order to support continuous
monitoring of the channel's performance characteristics. In this monitoring of the channel's performance characteristics. In this
case the configuration will typically include quality thresholds case, the configuration will typically include quality thresholds
depending on the service-level agreement, the crossing of which will depending on the service level agreement, the crossing of which will
trigger warnings or alarms, and result reporting and exception trigger warnings or alarms, and result reporting and exception
notification will be integrated into the system-wide network notification will be integrated into the system-wide network
management and reporting framework. management and reporting framework.
8. Security Considerations 8. Security Considerations
This document describes procedures for the measurement of performance This document describes procedures for the measurement of performance
metrics over a pre-existing MPLS path (a pseudowire, LSP, or metrics over a pre-existing MPLS path (a pseudowire, LSP, or
section). As such it assumes that a node involved in a measurement section). As such, it assumes that a node involved in a measurement
operation has previously verified the integrity of the path and the operation has previously verified the integrity of the path and the
identity of the far end using existing MPLS mechanisms such as identity of the far end using existing MPLS mechanisms such as
Bidirectional Forwarding Detection (BFD) [RFC5884]; tools, Bidirectional Forwarding Detection (BFD) [RFC5884]; tools,
techniques, and considerations for securing MPLS paths are discussed techniques, and considerations for securing MPLS paths are discussed
in detail in [RFC5920]. in detail in [RFC5920].
When such mechanisms are not available, and where security of the When such mechanisms are not available, and where security of the
measurement operation is a concern, reception of Generic Associated measurement operation is a concern, reception of Generic Associated
Channel messages with the Channel Types specified in this document Channel messages with the Channel Types specified in this document
SHOULD be disabled. Implementations MUST provide the ability to SHOULD be disabled. Implementations MUST provide the ability to
disable these protocols on a per-Channel-Type basis. disable these protocols on a per-Channel-Type basis.
Even when the identity of the far end has been verified, the Even when the identity of the far end has been verified, the
measurement protocols remain vulnerable to injection and man-in-the- measurement protocols remain vulnerable to injection and man-in-the-
middle attacks. The impact of such an attack would be to compromise middle attacks. The impact of such an attack would be to compromise
the quality of performance measurements on the affected path. An the quality of performance measurements on the affected path. An
attacker positioned to disrupt these measurements is, however, attacker positioned to disrupt these measurements is, however,
capable of causing much greater damage by disrupting far more capable of causing much greater damage by disrupting far more
critical elements of the network such as the network control plane or critical elements of the network such as the network control plane or
user traffic flows. A disruption of the measurement protocols would user traffic flows. At worst, a disruption of the measurement
at worst interfere with the monitoring of the performance aspects of protocols would interfere with the monitoring of the performance
the service level agreement associated with the path; the existence aspects of the service level agreement associated with the path; the
of such a disruption would imply that a much more serious breach of existence of such a disruption would imply that a serious breach of
basic path integrity had already occurred. basic path integrity had already occurred.
Such attacks can be mitigated if desired by performing basic If desired, such attacks can be mitigated by performing basic
validation and sanity checks, at the querier, of the counter or validation and sanity checks, at the querier, of the counter or
timestamp fields in received measurement response messages. The timestamp fields in received measurement response messages. The
minimal state associated with these protocols also limits the extent minimal state associated with these protocols also limits the extent
of measurement disruption that can be caused by a corrupt or invalid of measurement disruption that can be caused by a corrupt or invalid
message to a single query/response cycle. message to a single query/response cycle.
Cryptographic mechanisms capable of signing or encrypting the Cryptographic mechanisms capable of signing or encrypting the
contents of the measurement packets without degrading the measurement contents of the measurement packets without degrading the measurement
performance are not currently available. In light of the preceding performance are not currently available. In light of the preceding
discussion, the absence of such cryptographic mechanisms does not discussion, the absence of such cryptographic mechanisms does not
raise significant security issues. raise significant security issues.
Users concerned with the security of out-of-band responses over IP Users concerned with the security of out-of-band responses over IP
networks SHOULD employ suitable security mechanisms such as IPsec networks SHOULD employ suitable security mechanisms such as IPsec
[RFC4301] to protect the integrity of the return path. [RFC4301] to protect the integrity of the return path.
9. IANA Considerations 9. IANA Considerations
This document makes the following requests of IANA: Per this document, IANA has completed the following actions:
o Allocation of Channel Types in the PW Associated Channel Type o Allocation of Channel Types in the "PW Associated Channel Type"
registry registry
o Creation of a Measurement Timestamp 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 Control Code" registry
o Creation of an MPLS Loss/Delay Measurement Type-Length-Value (TLV) o Creation of an "MPLS Loss/Delay Measurement Type-Length-Value
Object registry (TLV) Object" registry
9.1. Allocation of PW Associated Channel Types 9.1. Allocation of PW Associated Channel Types
As per the IANA considerations in [RFC5586], IANA is requested to As per the IANA considerations in [RFC5586], IANA has allocated the
allocate the following Channel Types in the PW Associated Channel following Channel Types in the "PW Associated Channel Type" registry:
Type registry:
Value Description TLV Follows Reference
----- -------------------------------------- ----------- ------------
TBD MPLS Direct Packet Loss Measurement No (this draft)
(DLM)
TBD MPLS Inferred Packet Loss Measurement No (this draft)
(ILM)
TBD MPLS Packet Delay Measurement (DM) No (this draft)
TBD MPLS Direct Packet Loss and Delay No (this draft)
Measurement (DLM+DM)
TBD MPLS Inferred Packet Loss and Delay No (this draft)
Measurement (ILM+DM)
The values marked TBD are to be allocated by IANA as appropriate. 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 9.2. Creation of Measurement Timestamp Type Registry
IANA is requested to create a new Measurement Timestamp Type IANA has created a new "Measurement Timestamp Type" registry, with
registry, with format and initial allocations as follows: format and initial allocations as follows:
Type Description Size in bits Reference Type Description Size in Bits Reference
---- -------------------------------------- ------------ ------------ ---- ----------------------------------------- ------------ ---------
0 Null Timestamp 64 (this draft) 0 Null Timestamp 64 RFC 6374
1 Sequence Number 64 (this draft) 1 Sequence Number 64 RFC 6374
2 Network Time Protocol version 4 64-bit 64 (this draft) 2 Network Time Protocol version 4 64-bit 64 RFC 6374
Timestamp Timestamp
3 Truncated IEEE 1588v2 PTP Timestamp 64 (this draft) 3 Truncated IEEE 1588v2 PTP Timestamp 64 RFC 6374
The range of the Type field is 0-15. The range of the Type field is 0-15.
The allocation policy for this registry is IETF Review. The allocation policy for this registry is IETF Review.
9.3. Creation of MPLS Loss/Delay Measurement Control Code Registry 9.3. Creation of MPLS Loss/Delay Measurement Control Code Registry
IANA is requested to create a new MPLS Loss/Delay Measurement Control IANA has created a new "MPLS Loss/Delay Measurement Control Code"
Code registry. This registry is divided into two separate parts, one registry. This registry is divided into two separate parts, one for
for Query Codes and the other for Response Codes, with formats and Query Codes and the other for Response Codes, with formats and
initial allocations as follows: initial allocations as follows:
Query Codes Query Codes
Code Description Reference Code Description Reference
---- ------------------------------ ------------ ---- ------------------------------ ---------
0x0 In-band Response Requested (this draft) 0x0 In-band Response Requested RFC 6374
0x1 Out-of-band Response Requested (this draft) 0x1 Out-of-band Response Requested RFC 6374
0x2 No Response Requested (this draft) 0x2 No Response Requested RFC 6374
Response Codes Response Codes
Code Description Reference Code Description Reference
---- ----------------------------------- ------------ ---- ----------------------------------- ---------
0x0 Reserved (this draft) 0x0 Reserved RFC 6374
0x1 Success (this draft) 0x1 Success RFC 6374
0x2 Data Format Invalid (this draft) 0x2 Data Format Invalid RFC 6374
0x3 Initialization In Progress (this draft) 0x3 Initialization in Progress RFC 6374
0x4 Data Reset Occurred (this draft) 0x4 Data Reset Occurred RFC 6374
0x5 Resource Temporarily Unavailable (this draft) 0x5 Resource Temporarily Unavailable RFC 6374
0x10 Unspecified Error (this draft) 0x10 Unspecified Error RFC 6374
0x11 Unsupported Version (this draft) 0x11 Unsupported Version RFC 6374
0x12 Unsupported Control Code (this draft) 0x12 Unsupported Control Code RFC 6374
0x13 Unsupported Data Format (this draft) 0x13 Unsupported Data Format RFC 6374
0x14 Authentication Failure (this draft) 0x14 Authentication Failure RFC 6374
0x15 Invalid Destination Node Identifier (this draft) 0x15 Invalid Destination Node Identifier RFC 6374
0x16 Connection Mismatch (this draft) 0x16 Connection Mismatch RFC 6374
0x17 Unsupported Mandatory TLV Object (this draft) 0x17 Unsupported Mandatory TLV Object RFC 6374
0x18 Unsupported Query Interval (this draft) 0x18 Unsupported Query Interval RFC 6374
0x19 Administrative Block (this draft) 0x19 Administrative Block RFC 6374
0x1A Resource Unavailable (this draft) 0x1A Resource Unavailable RFC 6374
0x1B Resource Released (this draft) 0x1B Resource Released RFC 6374
0x1C Invalid Message (this draft) 0x1C Invalid Message RFC 6374
0x1D Protocol Error (this draft) 0x1D Protocol Error RFC 6374
IANA is also requested to indicate that the values 0x0 - 0xF in the IANA has indicated that the values 0x0 - 0xF in the Response Code
Response Code section are reserved for non-error response codes. section are reserved for non-error response codes.
The range of the Code field is 0 - 255. The range of the Code field is 0 - 255.
The allocation policy for this registry is IETF Review. The allocation policy for this registry is IETF Review.
9.4. Creation of MPLS Loss/Delay Measurement TLV Object Registry 9.4. Creation of MPLS Loss/Delay Measurement TLV Object Registry
IANA is requested to create a new MPLS Loss/Delay Measurement TLV IANA has created a new "MPLS Loss/Delay Measurement TLV Object"
Object registry, with format and initial allocations as follows: registry, with format and initial allocations as follows:
Type Description Reference Type Description Reference
---- --------------------------------- ------------ ---- --------------------------------- ---------
0 Padding - copy in response (this draft) 0 Padding - copy in response RFC 6374
1 Return Address (this draft) 1 Return Address RFC 6374
2 Session Query Interval (this draft) 2 Session Query Interval RFC 6374
3 Loopback Request (this draft) 3 Loopback Request RFC 6374
127 Experimental use (this draft) 127 Experimental use RFC 6374
128 Padding - do not copy in response (this draft) 128 Padding - do not copy in response RFC 6374
129 Destination Address (this draft) 129 Destination Address RFC 6374
130 Source Address (this draft) 130 Source Address RFC 6374
255 Experimental use (this draft) 255 Experimental use RFC 6374
IANA is also requested to indicate that Types 0-127 are classified as IANA has indicated that Types 0-127 are classified as Mandatory, and
Mandatory, and that Types 128-255 are classified as Optional. that Types 128-255 are classified as Optional.
The range of the Type field is 0 - 255. The range of the Type field is 0 - 255.
The allocation policy for this registry is IETF Review. The allocation policy for this registry is IETF Review.
10. Acknowledgments 10. Acknowledgments
The authors wish to thank the many participants of the MPLS working The authors wish to thank the many participants of the MPLS working
group who provided detailed review and feedback on this document. group who provided detailed review and feedback on this document.
The authors offer special thanks to Alexander Vainshtein, Loa The authors offer special thanks to Alexander Vainshtein, Loa
Andersson, and Hiroyuki Takagi for many helpful thoughts and Andersson, and Hiroyuki Takagi for many helpful thoughts and
discussions, to Linda Dunbar for the idea of using LM messages for discussions, to Linda Dunbar for the idea of using LM messages for
throughput measurement, and to Ben Niven-Jenkins, Marc Lasserre, and throughput measurement, and to Ben Niven-Jenkins, Marc Lasserre, and
Ben Mack-Crane for their valuable comments. Ben Mack-Crane for their valuable comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[IEEE1588] [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock
IEEE, "1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and
Synchronization Protocol for Networked Measurement and Control Systems", March 2008.
Control Systems", March 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002. Services", RFC 3270, May 2002.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Switching (MPLS) Label Stack Entry: "EXP" Field Renamed
Class" Field", RFC 5462, February 2009. to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch,
Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
11.2. Informative References 11.2. Informative References
[I-D.ietf-mpls-tp-loss-delay-profile] [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Frost, D. and S. Bryant, "A Packet Loss and Delay Delay Metric for IPPM", RFC 2679, September 1999.
Measurement Profile for MPLS-based Transport Networks",
draft-ietf-mpls-tp-loss-delay-profile-03 (work in
progress), April 2011.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999. Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Packet Loss Metric for IPPM", RFC 2680, September 1999. Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
Delay Metric for IPPM", RFC 2681, September 1999. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3260] Grossman, D., "New Terminology and Clarifications for
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Diffserv", RFC 3260, April 2002.
Tunnels", RFC 3209, December 2001.
[RFC3260] Grossman, D., "New Terminology and Clarifications for [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Diffserv", RFC 3260, April 2002. Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Edge (PWE3) Architecture", RFC 3985, March 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Internet Protocol", RFC 4301, December 2005. Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding
Zekauskas, "A One-way Active Measurement Protocol Equal Cost Multipath Treatment in MPLS Networks",
(OWAMP)", RFC 4656, September 2006. BCP 128, RFC 4928, June 2007.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Cost Multipath Treatment in MPLS Networks", BCP 128, Specification", RFC 5036, October 2007.
RFC 4928, June 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Specification", RFC 5036, October 2007. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, October 2008.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", Applicability Statement", RFC 5481, March 2009.
RFC 5357, October 2008.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
Applicability Statement", RFC 5481, March 2009. "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
"Bidirectional Forwarding Detection (BFD) for MPLS Label Networks", RFC 5920, July 2010.
Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Networks", RFC 5920, July 2010. Berger, "A Framework for MPLS in Transport Networks",
RFC 5921, July 2010.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport
Berger, "A Framework for MPLS in Transport Networks", Profile Data Plane Architecture", RFC 5960, August 2010.
RFC 5921, July 2010.
[RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport [RFC6375] Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and
Profile Data Plane Architecture", RFC 5960, August 2010. Delay Measurement Profile for MPLS-Based Transport
Networks", RFC 6375, September 2011.
[Y.1731] ITU-T Recommendation Y.1731, "OAM Functions and Mechanisms [Y.1731] ITU-T Recommendation Y.1731, "OAM Functions and
for Ethernet based Networks", February 2008. Mechanisms for Ethernet based Networks", February 2008.
Appendix A. Default Timestamp Format Rationale Appendix A. Default Timestamp Format Rationale
This document initially proposed the Network Time Protocol (NTP) This document initially proposed the Network Time Protocol (NTP)
timestamp format as the mandatory default, as this is the normal timestamp format as the mandatory default, as this is the normal
default timestamp in IETF protocols and thus would seem the "natural" default timestamp in IETF protocols and thus would seem the "natural"
choice. However a number of considerations have led instead to the choice. However, a number of considerations have led instead to the
specification of the truncated IEEE 1588 Precision Time Protocol specification of the truncated IEEE 1588 Precision Time Protocol
(PTP) timestamp as the default. NTP has not gained traction in (PTP) timestamp as the default. NTP has not gained traction in
industry as the protocol of choice for high quality timing industry as the protocol of choice for high-quality timing
infrastructure, whilst IEEE 1588 PTP has become the de facto time infrastructure, whilst IEEE 1588 PTP has become the de facto time
transfer protocol in networks which are specially engineered to transfer protocol in networks that are specially engineered to
provide high accuracy time distribution service. The PTP timestamp provide high-accuracy time distribution service. The PTP timestamp
format is also the ITU-T format of choice for packet transport format is also the ITU-T format of choice for packet transport
networks, which may rely on MPLS protocols. Applications such as networks, which may rely on MPLS protocols. Applications such as
one-way delay measurement need the best time service available, and one-way delay measurement need the best time service available, and
converting between the NTP and PTP timestamp formats is not a trivial converting between the NTP and PTP timestamp formats is not a trivial
transformation, particularly when it is required that this be done in transformation, particularly when it is required that this be done in
real time without loss of accuracy. real time without loss of accuracy.
The truncated IEEE 1588 PTP format specified in this document is The truncated IEEE 1588 PTP format specified in this document is
considered to provide a more than adequate wrap time and greater time considered to provide a more than adequate wrap time and greater time
resolution than it is expected will be needed for the operational resolution than it is expected will be needed for the operational
lifetime of this protocol. By truncating the timestamp at both the lifetime of this protocol. By truncating the timestamp at both the
high and low order bits, the protocol achieves a worthwhile reduction high and low order bits, the protocol achieves a worthwhile reduction
in system resources. in system resources.
Authors' Addresses Authors' Addresses
Dan Frost Dan Frost
Cisco Systems Cisco Systems
Email: danfrost@cisco.com EMail: danfrost@cisco.com
Stewart Bryant Stewart Bryant
Cisco Systems Cisco Systems
Email: stbryant@cisco.com EMail: stbryant@cisco.com
 End of changes. 174 change blocks. 
487 lines changed or deleted 472 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/