RFC 6374

Bestie, we're starting RFC 6374 and it's a whole vibe!! 🎀

• RFC: 6374, Packet Loss and Delay Measurement for MPLS Networks 🦋
• Authors: D. Frost and S. Bryant, both from Cisco Systems 💅
• Category: Standards Track
• ISSN: 2070-1721
• Date: September 2011
• Obsoletes / Updates: the header doesn't list anything this one obsoletes or updates 🙈

Abstract ✨

Okay so service providers have these SLAs (service level agreements) that totally depend on measuring stuff like packet loss, one-way and two-way delay, plus delay variation and channel throughput 📊. Being able to measure all of that gives operators way more visibility into how their networks are actually performing, which makes planning, troubleshooting, and performance evaluation so much easier. This document lays out the protocol mechanisms that let you measure these metrics efficiently and accurately in MPLS networks. Iconic. 💖

Status of This Memo 🌸

This is an Internet Standards Track document, bestie. 💜

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more info on Internet Standards, check out Section 2 of RFC 5741.

For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6374 🧚

Copyright Notice 🎀

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 🫶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date this document was published. Please read these carefully, because they explain your rights and restrictions for this document 📜. Code Components pulled out of this document need to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🌈.

Table of Contents 🦋

1. Introduction ....................................................3
   1.1. Applicability and Scope ....................................5
   1.2. Terminology ................................................6
   1.3. Requirements Language ......................................6
2. Overview ........................................................6
   2.1. Basic Bidirectional Measurement ............................6
   2.2. Packet Loss Measurement ....................................7
   2.3. Throughput Measurement ....................................10
   2.4. Delay Measurement .........................................10
   2.5. Delay Variation Measurement ...............................12
   2.6. Unidirectional Measurement ................................12
   2.7. Dyadic Measurement ........................................13
   2.8. Loopback Measurement ......................................13
   2.9. Measurement Considerations ................................14
        2.9.1. Types of Channels ..................................14
        2.9.2. Quality of Service .................................14
        2.9.3. Measurement Point Location .........................14
        2.9.4. Equal Cost Multipath ...............................15
        2.9.5. Intermediate Nodes .................................15
        2.9.6. Different Transmit and Receive Interfaces ..........16
        2.9.7. External Post-Processing ...........................16
        2.9.8. Loss Measurement Modes .............................16
        2.9.9. Loss Measurement Scope .............................18
        2.9.10. Delay Measurement Accuracy ........................18
        2.9.11. Delay Measurement Timestamp Format ................18
3. Message Formats ................................................19
   3.1. Loss Measurement Message Format ...........................19
   3.2. Delay Measurement Message Format ..........................25
   3.3. Combined Loss/Delay Measurement Message Format ............27
   3.4. Timestamp Field Formats ...................................28
   3.5. TLV Objects ...............................................29
        3.5.1. Padding ............................................30
        3.5.2. Addressing .........................................31
        3.5.3. Loopback Request ...................................31
        3.5.4. Session Query Interval .............................32
4. Operation ......................................................33
   4.1. Operational Overview ......................................33
   4.2. Loss Measurement Procedures ...............................34
        4.2.1. Initiating a Loss Measurement Operation ............34
        4.2.2. Transmitting a Loss Measurement Query ..............34
        4.2.3. Receiving a Loss Measurement Query .................35
        4.2.4. Transmitting a Loss Measurement Response ...........35
        4.2.5. Receiving a Loss Measurement Response ..............36
        4.2.6. Loss Calculation ...................................36
        4.2.7. Quality of Service .................................37
        4.2.8. G-ACh Packets ......................................37
        4.2.9. Test Messages ......................................37
        4.2.10. Message Loss and Packet Misorder Conditions .......38
   4.3. Delay Measurement Procedures ..............................39
        4.3.1. Transmitting a Delay Measurement Query .............39
        4.3.2. Receiving a Delay Measurement Query ................39
        4.3.3. Transmitting a Delay Measurement Response ..........40
        4.3.4. Receiving a Delay Measurement Response .............41
        4.3.5. Timestamp Format Negotiation .......................41
               4.3.5.1. Single-Format Procedures ..................42
        4.3.6. Quality of Service .................................42
   4.4. Combined Loss/Delay Measurement Procedures ................42
5. Implementation Disclosure Requirements .........................42
6. Congestion Considerations ......................................44
7. Manageability Considerations ...................................44
8. Security Considerations ........................................45
9. IANA Considerations ............................................46
   9.1. Allocation of PW Associated Channel Types .................47
   9.2. Creation of Measurement Timestamp Type Registry ...........47
   9.3. Creation of MPLS Loss/Delay Measurement Control
        Code Registry .............................................47
   9.4. Creation of MPLS Loss/Delay Measurement TLV Object
        Registry ..................................................49
10. Acknowledgments ...............................................49
11. References ....................................................49
   11.1. Normative References .....................................49
   11.2. Informative References ...................................50
Appendix A. Default Timestamp Format Rationale ....................52

1. Introduction 💖

Okay so bestie, picture this: a ton of service provider SLAs (service level agreements) rely on being able to measure and watch performance metrics like packet loss and one-way and two-way delay ✨. Stuff like delay variation and channel throughput is in the mix too. Being able to measure all this gives operators way more visibility into how their networks are actually performing, which makes planning, troubleshooting, and evaluating performance so much easier 🧠. This document spells out the protocol mechanisms that make these measurements efficient and accurate in MPLS networks 🦋.

Two closely related protocols are defined here: one for packet loss measurement (LM) and one for packet delay measurement (DM) 🎀. They have these characteristics and capabilities:

• The LM and DM protocols are meant to be simple and to support efficient hardware processing 💅.
• The LM and DM protocols run over the MPLS Generic Associated Channel (G-ACh) [RFC5586] and support measurement of loss, delay, and related metrics over Label Switched Paths (LSPs), pseudowires, and MPLS sections (links) 🌸.
• The LM and DM protocols apply to LSPs, pseudowires, and sections of networks based on the MPLS Transport Profile (MPLS-TP), because MPLS-TP is built on a standard MPLS data plane 🔥. MPLS-TP is defined and described in [RFC5921], and MPLS-TP LSPs, pseudowires, and sections get the full breakdown in [RFC5960]. A profile describing the minimal functional subset of the LM and DM protocols in the MPLS-TP context is in [RFC6375] 🫶.
• The LM and DM protocols can be used for both continuous/proactive and selective/on-demand measurement ✨.
• The LM and DM protocols use a simple query/response model for bidirectional measurement, which lets a single node (the querier) measure the loss or delay in both directions 👑.
• The LM and DM protocols use query messages for unidirectional loss and delay measurement. The measurement can happen either at the downstream node(s) or at the querier, as long as an out-of-band return path is available 🦋.
• The LM and DM protocols do not require the transmit and receive interfaces to be the same when doing bidirectional measurement 💜.
• The DM protocol is stateless 🍓.
• The LM protocol is "almost" stateless 🙈: loss is computed as a delta between successive messages, so the data from the last message received has to be kept around 💀.
• The LM protocol can do two distinct kinds of loss measurement. It can measure the loss of specially generated test messages to infer the approximate data-plane loss level (inferred measurement), or it can directly measure data-plane packet loss (direct measurement) 😭. Direct measurement gives perfect loss accounting, but it may need specialized hardware support and only works for some LSP types. Inferred measurement gives only approximate loss accounting but is generally applicable 🌈.

The direct LM method is also known as "frame-based" in the context of Ethernet transport networks [Y.1731]. Inferred LM is a generalization of the "synthetic" measurement approach currently in development for Ethernet networks, in the sense that it lets test messages be decoupled from measurement messages 🧚.

• The LM protocol supports measurement in terms of both packet counts and octet counts 🎀.
• The LM protocol supports both 32-bit and 64-bit counters 💅.
• The LM protocol can measure channel throughput as well as packet loss ⭐.
• The DM protocol supports multiple timestamp formats and gives the two endpoints of a bidirectional connection a simple way to agree on a preferred format. For implementations that only support a single timestamp format, this procedure is a total triviality 💖.
• The DM protocol supports varying the measurement message size so it can measure delays for different packet sizes 🌸.

The One-Way Active Measurement Protocol (OWAMP) [RFC4656] and Two-Way Active Measurement Protocol (TWAMP) [RFC5357] handle measurement of various performance metrics in IP networks 🫶. They aren't streamlined for hardware processing, and they rely on IP and TCP, plus elements of the Network Time Protocol (NTP). Those may not be available or optimized in some network environments. They also lack support for IEEE 1588 timestamps and direct-mode LM, which some environments may need 😭. So the protocols defined in this document are similar in some ways to these IP-based ones, but they're also different 💅.

1.1. Applicability and Scope 🌷

This document defines measurement procedures and protocol messages meant to work in a wide variety of situations and to be implementable by a wide range of hardware- and software-based measurement systems 🦋. So it doesn't try to mandate measurement quality levels or analyze specific end-user applications 💅.

1.2. Terminology 📖

Term  Definition
----- -------------------------------------------
ACH   Associated Channel Header
DM    Delay Measurement
ECMP  Equal Cost Multipath
G-ACh Generic Associated Channel
LM    Loss Measurement
LSE   Label Stack Entry
LSP   Label Switched Path
NTP   Network Time Protocol
OAM   Operations, Administration, and Maintenance
PTP   Precision Time Protocol
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 🌈

This section starts with a summary of the basic methods for bidirectional measurement of packet loss and delay 💜. Those methods then get described in detail. Last, there's a list of practical considerations that might come into play and shape or tweak these simple procedures 🍓. This section is pure theory, so for protocol specifics, check out Sections 3 and 4 🧚.

2.1. Basic Bidirectional Measurement 🦋

Here's the reference scenario ✨:

                             T1              T2
                   +-------+/     Query       \+-------+
                   |       | - - - - - - - - ->|       |
                   |   A   |===================|   B   |
                   |       |<- - - - - - - - - |       |
                   +-------+\     Response    /+-------+
                             T4              T3

This figure shows a bidirectional channel between two nodes, A and B, and illustrates the temporal reference points T1-T4 tied to a measurement operation that happens at A 🫶. The operation is A sending a query message to B, and B sending a response back 👑.

Each reference point marks the moment the query or the response message is transmitted or received over the channel 🌸.

Here's the situation: A can measure packet loss over the channel in the forward and reverse directions by sending Loss Measurement (LM) query messages to B 💖. Each one carries the count of packets transmitted before time T1 over the channel to B (A_TxP). When the message reaches B, it appends two values and reflects the message back to A: the count of packets received before time T2 over the channel from A (B_RxP), and the count of packets transmitted before time T3 over the channel to A (B_TxP) 💅. When the response reaches A, it appends a fourth value: the count of packets received before time T4 over the channel from B (A_RxP) ⭐.

These four counter values let A compute the loss statistics it wants 🔥. The transmit count at A and the receive count at B (and vice versa) might not be synchronized when the first message goes out, and to limit the effects of counter wrap, loss is computed as a delta between messages 🙈.

To measure the delay over the channel to B from A, a Delay Measurement (DM) query message is sent from A to B. It contains a timestamp recording the instant it's transmitted, i.e., T1 🧚. When the message reaches B, a timestamp gets added recording the instant it's received (T2) 🎀. Then the message can be reflected from B back to A, with B adding its transmit timestamp (T3) and A adding its receive timestamp (T4) 🌷. These four timestamps let A compute the one-way delay in each direction, as well as the two-way delay for the channel 😭. The one-way delay computations need the clocks of A and B to be synchronized, but clock synchronization mechanisms are outside the scope of this document 🍓.

2.2. Packet Loss Measurement

okay so picture a bidirectional channel between nodes A and B 🦋. the goal is for A to measure two things about that channel ✨

• A_TxLoss (transmit loss): the number of packets transmitted by A over the channel but not received at B;
• A_RxLoss (receive loss): the number of packets transmitted by B over the channel but not received at A.

A starts this by running a Loss Measurement (LM) operation 💅. that means sending a stream of LM query messages (LM[1], LM[2], ...) over the channel at a set rate, like one every 100 milliseconds. each message LM[n] carries this value:

• A_TxP[n]: the total count of packets A has transmitted over the channel before this message goes out.

when B receives the message, it writes down its own value:

• B_RxP[n]: the total count of packets B has received over the channel when this message arrives (not counting the message itself).

then B sends the message straight back to A and adds one more value:

• B_TxP[n]: the total count of packets B has transmitted over the channel before this response goes out.

when the response gets back to A, A records the last value:

• A_RxP[n]: the total count of packets A has received over the channel when this response arrives (not counting the message itself).

ngl this is so clean 🫶. the transmit loss A_TxLoss[n-1,n] and receive loss A_RxLoss[n-1,n] for the measurement interval between LM[n-1] and LM[n] get computed by A like this 🧮:

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])

the arithmetic is modulo the counter size, so the counters can wrap around and it still works 🌈.

quick note 🙈: technically A doesn't have to write A_RxP[n] into the message. it's just super convenient for some implementations, and it's useful if the message gets forwarded on to an external measurement system.

once a response is received and processed, A updates these running totals:

A_TxLoss = A_TxLoss[1,2] + A_TxLoss[2,3] + ...

A_RxLoss = A_RxLoss[1,2] + A_RxLoss[2,3] + ...

they show the total transmit and receive loss over the channel since the LM operation started. iconic 👑.

now the wrap situation is kind of the main drama 💀. if A_TxP[n] wraps back to 0 and then keeps going to a value equal to or greater than A_TxP[n-1], there's no way to get an unambiguous A_TxLoss[n-1,n]. so the LM message rate MUST be high enough, given the counter size and the speed and minimum packet size of the channel, that this can never happen. for example, a 32-bit counter on a 100-Gbps link with a minimum packet size of 64 bytes wraps in 2^32 / (10^11/(64*8)) = ~22 seconds, so that's the upper bound on the LM message interval in that setup ⏰. this bound is called the MaxLMInterval of the channel. the MaxLMInterval is an even stricter limit for direct LM and for smaller counter sizes 🎀.

LM is stateless at B and "almost" stateless at A 🧚. A has to hang on to the data from the last LM response it got, so it can work out the loss when the next response shows up. that data MAY be thrown away, and MUST NOT be used as the basis for a measurement, if the MaxLMInterval passes before the next response arrives. the reason is that an unambiguous measurement just isn't possible at that point 🙅‍♀️.

so far we've been talking about packets, but the counted objects don't have to be packets. you can count octets instead 🍓. just know that this will shrink the MaxLMInterval.

the individual loss counts are great, but they also give you other metrics, like the average loss rate over any multiple of the measurement interval. you can get an accurate loss rate over time even if some individual measurements get messed up, for example by packet misordering (Section 4.2.10). main character energy 💜.

fyi, there's a way to do packet loss measurement in IP networks documented in [RFC2680] 📚. it's different from this one, though. for example, it needs clock synchronization between the measurement points, and it doesn't support direct-mode LM.

2.3. Throughput Measurement

if LM query messages carry a timestamp of when they were sent, you can combine that with the packet or octet counts to measure the throughput offered and delivered over the channel during the interval, in terms of the counted units 📈.

for a bidirectional channel, say you have any two LM response messages (no more than the MaxLMInterval apart in time). the difference between their counter values tells the querier how many units were successfully transmitted and received between those timestamps 💖. absolute offered throughput is the number of data units transmitted, and absolute delivered throughput is the number of data units received. throughput rate is the number of data units sent or received per unit of time ⭐.

same energy as loss measurement 🫶: the interval counts can be added up to get the absolute throughput of the channel since the measurement started, or used to derive related metrics like throughput rate. this also lets you do out-of-service throughput testing when you pair it with a simple packet generator 🔥.

2.4. Delay Measurement

okay now delay 🕰️. suppose again there's a bidirectional channel between A and B. A wants to measure one or more of these:

• The one-way delay associated with the forward (A to B) direction of the channel;
• The one-way delay associated with the reverse (B to A) direction of the channel;
• The two-way delay (A to B to A) associated with the channel.

the one-way delay metric for packet networks is described in [RFC2679] 💅. two-way delay is a bit more complicated, because there are actually two metrics you might care about. the "two-way channel delay" is the sum of the one-way delays in each direction. it reflects the delay of the channel itself, no matter how much processing time the remote endpoint B takes 🧠. the "round-trip delay" is described in [RFC2681], and it also includes any delay from processing at the remote endpoint 🌸.

the one-way delay quantities need the clocks of A and B to be synchronized. the two-way delay metrics can be measured directly even when they aren't, as long as A and B both have stable clocks 🕰️✨.

to take a measurement, A sends a Delay Measurement (DM) query message to B with this timestamp in it:

• T1: the time the DM query message is transmitted from A.

when the message reaches B, B records:

• T2: the time the DM query message is received at B.

then B sends the message back to A, adding:

• T3: the time the DM response message is transmitted from B.

when the message gets back to A, A records:

• T4: the time the DM response message is received back at A.

(strictly speaking, T4 doesn't have to actually be written into the message, but it's handy for some implementations, and useful if the message is forwarded on to an external measurement system 🫶.)

now A can compute the two-way channel delay as:

two-way channel delay = (T4 - T1) - (T3 - T2)

and the round-trip delay as:

round-trip delay = T4 - T1

if A knows the clocks of A and B are synchronized, then A can compute both one-way delay values, plus the two-way channel delay, like this 🎀:

forward one-way delay = T2 - T1

reverse one-way delay = T4 - T3

two-way channel delay = forward delay + reverse delay

the two-way channel delay formula here reduces to the one from before, so clock synchronization isn't needed to get that metric 🦋.

2.5. Delay Variation Measurement

okay delay variation is giving a whole vibe 🌈. Inter-Packet Delay Variation (IPDV) and Packet Delay Variation (PDV) [RFC5481] are performance metrics derived from one-way delay measurement, and they matter a lot in some applications 💖. IPDV is the difference between the one-way delays of successive packets in a stream. PDV, for a given measurement test interval, is the difference between the one-way delay of a packet in that interval and the one-way delay of the packet with the minimum delay in that same interval 🧚.

you can get IPDV and PDV measurements from the delay measurements you get through the procedures in Section 2.4 🫶. the really cool part is that you can do delay variation measurement using one-way delay measurements even when the clocks of the two systems involved aren't synchronized with each other 🤯.

2.6. Unidirectional Measurement

what if the channel from A to (B1, ..., Bk) is one-way? (where B2, ..., Bk means the point-to-multipoint case) 👀 in other words, it's a unidirectional LSP. then LM and DM measurements can be done at B1, ..., Bk instead of at A ✨.

for LM, A starts an LM operation and follows the same procedures as for bidirectional channels 💅. the one difference is that B1, ..., Bk don't send any responses back to A. instead, each terminal node B uses the A_TxP and B_RxP values in the LM messages it receives to compute the receive loss for the channel, pretty much the same way as before:

B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])

for DM, obviously only the forward one-way delay can be measured, and the clock synchronization requirement still applies 🕰️.

and if there's an out-of-band channel from a terminal node B back to A, the LM and DM message responses can be sent to A over that channel. then the measurements can still be carried out at A 🎀🫶.

2.7. Dyadic Measurement

okay so the basic bidirectional vibe assumes the querier node A is running the whole show and measuring for itself 💅 but here's the plot twist: with only minor tweaks, you can do a dyadic or "dual-ended" measurement where BOTH nodes A and B do loss or delay measurement off the same message flow 🫶 The trick is that A copies the third and fourth counter or timestamp values from a response into the third and fourth slots of the next query. Those slots are otherwise unused, so B gets basically the same info A has ✨

The dyadic approach is lowkey amazing because it halves the number of messages that both A and B need for a given kind of measurement 🙌 But ngl it comes at a cost: each node can't control its own measurement process independently anymore, and it adds extra operational complexity 🥴 Also, measurement traffic is expected to be pretty small compared to user traffic, especially when 64-bit counters are used for LM 📉 So this document does not specify a dyadic operational mode. However, it's still possible, and may be useful, for A to do that extra copy anyway, so B gets additional info even when it's just hanging out passively 🦋

2.8. Loopback Measurement

Some bidirectional channels can get placed into a loopback state, where messages just get looped straight back to the sender without any modification 🔁 In that situation, LM and DM procedures can be used to measure the circular path. You do this by generating "queries" with the Response flag set to 1 🧚

For LM, the loss computation in this case is:

A_Loss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])

For DM, the round-trip delay gets computed. Here though, the remote endpoint processing time component only reflects the time it takes to loop the message from channel input to channel output 🌸

2.9. Measurement Considerations

A number of extra considerations apply in practice to the methods we just summarized 🎀

2.9.1. Types of Channels

There are several types of channels in MPLS networks where loss and delay measurement can happen 🌈 The channel type may restrict which kinds of measurement you can do. In all cases, LM and DM messages flow over the MPLS Generic Associated Channel (G-ACh), which is described in detail in [RFC5586] 💜

Broadly, a channel in an MPLS network may be a link, a Label Switched Path (LSP) [RFC3031], or a pseudowire [RFC3985]. Links are bidirectional and are also referred to as MPLS sections, so check out [RFC5586] and [RFC5960] for that 🔗 Pseudowires are bidirectional. Label Switched Paths may be either unidirectional or bidirectional 🛤️

The LM and DM protocols discussed in this document are initiated from a single node: the querier 👑 A query message may be received by a single node or by multiple nodes, depending on the nature of the channel. In the latter case, these protocols provide point-to-multipoint measurement capabilities 📡

2.9.2. Quality of Service

Quality of Service (QoS) capabilities, in the form of the Differentiated Services architecture, apply to MPLS as specified in [RFC3270] and [RFC5462] ⭐ Different classes of traffic are distinguished by the three-bit Traffic Class (TC) field of an MPLS Label Stack Entry (LSE). Delay measurement applies on a per-traffic-class basis, and the TC values of LSEs above the G-ACh Label (GAL) that precedes a DM message are significant 🍓 Packet loss can be measured with respect to either the channel as a whole or to a specific traffic class 💖

2.9.3. Measurement Point Location

The location of the measurement points for loss and delay within the sending and receiving nodes is implementation dependent, but it directly affects the nature of the measurements 🤓 For example, a sending implementation may or may not consider a packet to be "lost" for LM purposes if it was discarded before transmission for queuing-related reasons. Conversely, a receiving implementation may or may not consider a packet to be "lost" for LM purposes if it was physically received but discarded during receive-path processing 😭 The location of delay measurement points similarly determines what, precisely, is being measured. The principal consideration here is that the behavior of an implementation in these respects MUST be made clear to the user 🚨

2.9.4. Equal Cost Multipath

Equal Cost Multipath (ECMP) is the behavior of distributing packets across multiple alternate paths toward a destination 🛣️ The use of ECMP in MPLS networks is described in BCP 128 [RFC4928]. The typical result of ECMP being performed on an LSP that is subject to delay measurement is that only the delay of one of the available paths is, and can be, measured 🙈

The effects of ECMP on loss measurement depend on the LM mode. In the case of direct LM, the measurement accounts for any packets lost between the sender and the receiver, regardless of how many paths exist between them ✅ However, ECMP increases the likelihood of misordering both LM messages relative to data packets and the LM messages themselves. Such misorderings tend to create unmeasurable intervals and thus degrade the accuracy of loss measurement 😬 The effects of ECMP are similar for inferred LM, with the additional caveat that, unless the test packets are specially constructed so as to probe all available paths, the loss characteristics of one or more of the alternate paths cannot be accounted for 🫠

2.9.5. Intermediate Nodes

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 endpoints 🧭 This can be done in principle by setting the Time to Live (TTL) field in the outer LSE appropriately when targeting a measurement message to an intermediate node. This procedure may fail, however, if hardware-assisted measurement is in use, because 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 a later processing stage in the implementation than the hardware-assisted measurement function 🔧 The motivation for measuring intermediate nodes is often an attempt to localize a problem that has been detected on the LSP 🕵️‍♀️ In this case, if intermediate nodes are not capable of performing hardware-assisted measurement, a less accurate (but usually sufficient) software-based measurement can be conducted instead 💅

2.9.6. Different Transmit and Receive Interfaces

The overview of the bidirectional measurement process presented in Section 2 is also applicable when the transmit and receive interfaces at A or B differ from one another 🔀 Some additional considerations do apply in this case:

• If different clocks are associated with transmit and receive processing, these clocks must be synchronized in order to compute the two-way delay ⏰
• The DM protocol specified in this document requires that the timestamp formats used by the interfaces that receive a DM query and transmit a DM response agree 🧾
• 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 the up to four interfaces involved in an LM operation will result in 32-bit LM calculations for both directions of the channel 🔢

2.9.7. External Post-Processing

In some circumstances, it may be desirable to carry out the final measurement computation at an external post-processing device dedicated to the purpose 🧮 This can be achieved in supporting implementations by, for example, configuring the querier, in the case of a bidirectional measurement session, to forward each response it receives to the post-processor via any convenient protocol. The unidirectional case can be handled similarly through configuration of the receiver, or by including an instruction in query messages for the receiver to respond out-of-band to the appropriate return address 📬

Post-processing devices may be able to store measurement data for an extended period and generate a variety of useful statistics from it 📊 External post-processing also allows the measurement process to be completely stateless at the querier and responder 🫧

2.9.8. Loss Measurement Modes ✨

okay so the summary of loss measurement at the start of Section 2 talked about a "count of packets" being sent and received over a channel 📦. if the counted packets are the actual packets flowing over the channel in the data plane, the loss measurement is said to operate in "direct mode" 💖. but if the counted packets are selected control packets that we use to infer the loss characteristics of the channel, it's "inferred mode" 🔮.

Direct LM has the advantage of being able to provide perfect loss accounting when it's available 👑. there are, however, several constraints with direct LM, ngl 💀.

For accurate direct LM to happen, packets must not be sent between the time the transmit count for an outbound LM message is determined and the time the message is actually transmitted 🫶. similarly, packets must not be received and processed between the time an LM message is received and the time the receive count for the message is determined 🙈. if these "synchronization conditions" don't hold, the LM message counters won't reflect the true state of the data plane 😭. so, for example, the receive count of B might end up greater than the transmit count of A, and when you try to compute loss by subtracting, you get an invalid result 💅. this need for the LM message counters to stay in sync with the data plane may mean that hardware-based forwarding implementations need special support 🔥.

A limitation of direct LM is that it may be difficult or impossible to apply when the channel is an LSP and the LSP label at the receiver is either nonexistent or fails to identify a unique sending node 🧚. the first case happens when Penultimate Hop Popping (PHP) is used on the LSP. the second case generally holds for LSPs based on the Label Distribution Protocol (LDP) [RFC5036], as opposed to, for example, those based on Traffic Engineering extensions to the Resource Reservation Protocol (RSVP-TE) [RFC3209] 🌸. these conditions can make it infeasible for the receiver to identify the data-plane packets associated with a particular source and LSP so it can count them, or to infer the source and LSP context associated with an LM message 🙃. direct LM is also vulnerable to disruption if the ingress or egress interface associated with an LSP changes during the LSP's lifetime 💀.

Inferred LM works the same way as direct LM, except that the counted packets are special control packets, called test messages, generated by the sender 🦋. test messages may be either packets explicitly built and used for LM, or packets with a different primary purpose, such as those associated with a Bidirectional Forwarding Detection (BFD) [RFC5884] session 🍓.

The synchronization conditions discussed above for direct LM also apply to inferred LM 🧠. the only difference is that the required synchronization is now between the LM counters and the test message generation process ✨.

Protocol and application designers MUST take these synchronization requirements into account when developing tools for inferred LM, and MUST make their behavior in this regard clear to the user 🎀.

Inferred LM only gives an approximate view of the loss level associated with a channel, but it's typically applicable even in cases where direct LM isn't 💜.

---

2.9.9. Loss Measurement Scope 🌈

In the case of direct LM, where data-plane packets are counted, there are different possibilities for which kinds of packets are included 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 affecting the LM scope is whether all data packets are counted or only those belonging to a particular traffic class 🎯. another is whether various "auxiliary" flows associated with a data channel are counted, such as packets flowing over the G-ACh 🪄.

Implementations MUST make their supported LM scopes clear to the user, and care must be taken to make sure the scopes of the channel endpoints agree 🫶.

---

2.9.10. Delay Measurement Accuracy ⏱️

The delay measurement procedures in this document are designed to make hardware-assisted measurement easy 🔧, and they work the same way whether or not hardware assistance is used 💅. the measurement accuracy depends on how closely the transmit and receive timestamps match the actual packet departure and arrival times 🎯.

As noted in Section 2.4, measuring one-way delay requires clock synchronization between the devices involved 🕰️. two-way delay measurement doesn't directly compare non-local timestamps, so it has no synchronization requirement at all 🙌. the measurement accuracy is limited by the quality of the local clock and, for one-way delay measurement, by the quality of the synchronization 🔥.

---

2.9.11. Delay Measurement Timestamp Format 🕐

There are two significant timestamp formats in common use: the timestamp format of the Network Time Protocol (NTP), described in [RFC5905], and the timestamp format used in the IEEE 1588 Precision Time Protocol (PTP) [IEEE1588] 👑.

The NTP format has the advantages of wide use and long deployment in the Internet, and it was specifically designed to make computing timestamp differences as simple and efficient as possible 💗. on the other hand, there's now also a significant deployment of equipment designed to support the PTP format 🌷.

So the approach in this document is to include fields in DM messages that identify the timestamp formats used by the two devices involved in a DM operation 🦄. this means a node trying to carry out a DM operation may have to compute with, and possibly reconcile, different timestamp formats 😵‍💫. to keep things interoperable, support for at least one timestamp format needs to be mandatory 🤝. this specification requires support for the IEEE 1588 PTP format 💜. the timestamp format support requirements are discussed in detail in Section 3.4 📖.

---

3. Message Formats 📨

Loss Measurement and Delay Measurement messages flow over the MPLS Generic Associated Channel (G-ACh) [RFC5586] 🛣️. so a packet containing an LM or DM message has an MPLS label stack, with the G-ACh Label (GAL) at the bottom 🧱. the GAL is followed by an Associated Channel Header (ACH), which identifies the message type, and the message body comes after the ACH 🎁.

This document defines the following ACH Channel Types:

MPLS Direct Loss Measurement (DLM)
MPLS Inferred Loss Measurement (ILM)
MPLS Delay Measurement (DM)
MPLS Direct Loss and Delay Measurement (DLM+DM)
MPLS Inferred Loss and Delay Measurement (ILM+DM)

The message formats for direct and inferred LM are identical 👯. the 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 Header defined in [RFC5586] 🚫.

The fixed-format portion of a message MAY be followed by a block of Type-Length-Value (TLV) fields 🧩. the TLV block gives you an extensible way to attach extra info to LM and DM messages 🌟. several of these TLV fields are defined below 👀.

All integer values for fields defined in this document SHALL be encoded in network byte order 🔢. that's the vibe, bestie 🎀

3.1. Loss Measurement Message Format ✨

okay so this is the bit where the Loss Measurement message gets its outfit 💅 It sits right after the Associated Channel Header (ACH), and here's the full layout bestie 🎀

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version| Flags |  Control Code |        Message Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | DFlags|  OTF  |                   Reserved                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Session Identifier          |    DS     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Origin Timestamp                       |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Counter 1                           |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Counter 4                           |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                           TLV Block                           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Loss Measurement Message Format 🦋

Reserved fields MUST be set to 0 and ignored upon receipt. ✨ The rest of the fields have these possible values, and honestly the table is the whole vibe 💜

Field                 Meaning
--------------------- -----------------------------------------------
Version               Protocol version
Flags                 Message control flags
Control Code          Code identifying the query or response type
Message Length        Total length of this message in bytes
Data Format Flags     Flags specifying the format of message data
(DFlags)
Origin Timestamp      Format of the Origin Timestamp field
Format (OTF)
Reserved              Reserved for future specification
Session Identifier    Set arbitrarily by the querier
Differentiated        Differentiated Services Code Point (DSCP) being
Services (DS) Field   measured
Origin Timestamp      64-bit field for query message transmission
                      timestamp
Counter 1-4           64-bit fields for LM counter values
TLV Block             Optional block of Type-Length-Value fields

Here are the specific values, bestie 🌸

Version: currently set to 0. 🍓

Flags: the format of the Flags field looks like this 👑

                            +-+-+-+-+
                            |R|T|0|0|
                            +-+-+-+-+

Loss Measurement Message Flags 💖

The flag bits mean:

• R: Query/Response indicator. It's set to 0 for a Query and 1 for a Response. 🫶
• T: Traffic-class-specific measurement indicator. It's set to 1 when the measurement operation is scoped to packets of a particular traffic class (DSCP value), and 0 otherwise. When it's set to 1, the DS field of the message indicates the measured traffic class. 🧚
• 0: set to 0. 🙈

Control Code: this one gets set differently depending on whether the message is a Query or a Response, and the R flag tells you which one it is 😭

• For a Query:
  • 0x0: In-band Response Requested. This means the query was sent over a bidirectional channel and the response is expected over that same channel. 🔥
  • 0x1: Out-of-band Response Requested. The response should be sent via an out-of-band channel. ✨
  • 0x2: No Response Requested. No response to the query should be sent. This mode can be used, for example, if all nodes involved are being controlled by a Network Management System. 💅
• For a Response:
  • Codes 0x0-0xF are reserved for non-error responses. Error response codes imply that the response does not contain valid measurement data. 💀
  • 0x1: Success. The operation was successful. 🎀
  • 0x2: Notification - Data Format Invalid. The query was processed, but the format of the data fields in this response may be inconsistent. Consequently, these data fields MUST NOT be used for measurement. 🚫
  • 0x3: Notification - Initialization in Progress. The query was processed but this response does not contain valid measurement data because the responder's initialization process has not completed. ⏳
  • 0x4: Notification - Data Reset Occurred. The query was processed, but a reset has recently occurred that may render the data in this response inconsistent relative to earlier responses. 🌈
  • 0x5: Notification - Resource Temporarily Unavailable. The query was processed, but resources were unavailable to complete the requested measurement, so this response does not contain valid measurement data. 🥺
  • 0x10: Error - Unspecified Error. The operation failed for an unspecified reason. 😵
  • 0x11: Error - Unsupported Version. The operation failed because the protocol version supplied in the query message is not supported. 🙃
  • 0x12: Error - Unsupported Control Code. The operation failed because the Control Code requested an operation that is not available for this channel. 🫠
  • 0x13: Error - Unsupported Data Format. The operation failed because the data format specified in the query is not supported. 🧃
  • 0x14: Error - Authentication Failure. The operation failed because the authentication data supplied in the query was missing or incorrect. 🔐
  • 0x15: Error - Invalid Destination Node Identifier. The operation failed because the Destination Node Identifier supplied in the query is not an identifier of this node. 📍
  • 0x16: Error - Connection Mismatch. The operation failed because the channel identifier supplied in the query did not match the channel over which the query was received. 🔌
  • 0x17: Error - Unsupported Mandatory TLV Object. The operation failed because a TLV Object received in the query and marked as mandatory is not supported. 🧩
  • 0x18: Error - Unsupported Query Interval. The operation failed because the query message rate exceeded the configured threshold. 🚦
  • 0x19: Error - Administrative Block. The operation failed because it has been administratively disallowed. 🛑
  • 0x1A: Error - Resource Unavailable. The operation failed because node resources were not available. 📦
  • 0x1B: Error - Resource Released. The operation failed because node resources for this measurement session were administratively released. 👋
  • 0x1C: Error - Invalid Message. The operation failed because the received query message was malformed. 🤒
  • 0x1D: Error - Protocol Error. The operation failed because a protocol error was found in the received query message. 🪲

Message Length: set to the total length of this message in bytes, including the Version, Flags, Control Code, and Message Length fields as well as the TLV Block, if any. 📏

DFlags: the format of the DFlags field is shown below 🍭

                            +-+-+-+-+
                            |X|B|0|0|
                            +-+-+-+-+

Data Format Flags 🎀

The DFlags bits mean:

• X: Extended counter format indicator. It indicates the use of extended (64-bit) counter values. It's initialized to 1 upon creation (and prior to transmission) of an LM Query and copied from an LM Query to an LM response. It's set to 0 when the LM message is transmitted or received over an interface that writes 32-bit counter values. 💜
• B: Octet (byte) count. When set to 1, it indicates that the Counter 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 of a packet sent or received over a channel includes the total length of that packet (but excludes headers, labels, or framing of the channel itself). When set to 0, it indicates that the Counter 1-4 fields represent packet counts. 🧮
• 0: set to 0. 🙈

Origin Timestamp Format: the format of the Origin Timestamp field, as specified in Section 3.4. ⏰

Session Identifier: set arbitrarily in a query and copied in the response, if any. This field uniquely identifies a measurement operation (also called a session) that consists of a sequence of messages. All messages in the sequence have the same Session Identifier. It's giving ID card energy 🪪

DS: when the T flag is set to 1, this field is set to the DSCP value [RFC3260] that corresponds to the traffic class being measured. For MPLS, where the traffic class of a channel is identified by the three-bit Traffic Class in the channel's LSE [RFC5462], this field SHOULD be set to the Class Selector Codepoint [RFC2474] that corresponds to that Traffic Class. When the T flag is set to 0, the value of this field is arbitrary, and the field can be considered part of the Session Identifier. 🌷

Origin Timestamp: timestamp recording the transmit time of the query message. ⏱️

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. 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, 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 received at A, Counter 2 is set to A_RxP. 🔢

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 at the same fixed offset in the packet, and likewise for receive counters. This property may be important for hardware processing. 🧠✨

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; the high-order 32 bits of the field MUST, in this case, be set to 0. 🫧

TLV Block: zero or more TLV fields. 🎁

3.2. Delay Measurement Message Format ✨

okay bestie, so the Delay Measurement (DM) message sits right after the Associated Channel Header (ACH) 💅 here's the layout:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version| Flags |  Control Code |        Message Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  QTF  |  RTF  | RPTF  |              Reserved                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Session Identifier          |    DS     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Timestamp 1                         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Timestamp 4                         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                           TLV Block                           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Delay Measurement Message Format

here's what each field means, in a table 🍓

Field                 Meaning
--------------------- -----------------------------------------------
Version               Protocol version
Flags                 Message control flags
Control Code          Code identifying the query or response type
Message Length        Total length of this message in bytes
QTF                   Querier timestamp format
RTF                   Responder timestamp format
RPTF                  Responder's preferred timestamp format
Reserved              Reserved for future specification
Session Identifier    Set arbitrarily by the querier
Differentiated        Differentiated Services Code Point (DSCP) being
Services (DS) Field   measured

Timestamp 1-4         64-bit timestamp values
TLV Block             Optional block of Type-Length-Value fields

Reserved fields MUST be set to 0 and ignored upon receipt. The possible values for the remaining fields are below, so take notes 🫶

Version: it's giving 0 right now 🎀

Flags: as specified in Section 3.1. The T flag in a DM message is set to 1 🦋

Control Code: as specified in Section 3.1 💖

Message Length: this is the total length of the message in bytes 📏 It counts the Version, Flags, Control Code, and Message Length fields, plus the TLV Block if there is one ✨

Querier Timestamp Format: the format of the timestamp values the querier writes, as specified in Section 3.4 🌸

Responder Timestamp Format: the format of the timestamp values the responder writes, as specified in Section 3.4 🧚

Responder's Preferred Timestamp Format: the timestamp format the responder likes best, as specified in Section 3.4 👑

Session Identifier: as specified in Section 3.1 🌈

DS: as specified in Section 3.1 💅

Timestamp 1-4: okay this one is the main character moment 😭 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. When the query arrives at B, Timestamp 2 is set to T2. At this point, B copies Timestamp 1 to Timestamp 3 and Timestamp 2 to Timestamp 4, then re-initializes Timestamp 1 and Timestamp 2 to 0. When B transmits the response, Timestamp 1 is set to T3. When the response arrives at A, Timestamp 2 is set to T4. The actual formats of the timestamp fields written by A and B are indicated by the Querier Timestamp Format and Responder Timestamp Format fields, respectively 🔥

the way this mapping is designed is so transmit timestamps always land at the same fixed offset in the packet, and the same goes for receive timestamps 🤌 this matters a lot for hardware processing, so it's a big deal ⭐

TLV Block: zero or more TLV fields 💜

---

3.3. Combined Loss/Delay Measurement Message Format 🎀

the combined Loss and Delay Measurement message also sits right after the Associated Channel Header (ACH), and it looks like this:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version| Flags |  Control Code |        Message Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | DFlags|  QTF  |  RTF  | RPTF  |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Session Identifier          |    DS     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Timestamp 1                         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Timestamp 4                         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Counter 1                           |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Counter 4                           |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                           TLV Block                           ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Loss/Delay Measurement Message Format

the fields here mean the same things as the matching fields in the LM and DM formats 🦋 the one twist is that the roles of the OTF and Origin Timestamp fields for LM are played here by the QTF and Timestamp 1 fields, respectively ✨

---

3.4. Timestamp Field Formats 🌸

these timestamp format field values are specified in this document 🕰️

• 0: Null timestamp format. This is a placeholder meaning the timestamp field doesn't hold a meaningful timestamp 🙈
• 1: Sequence number. The timestamp field is treated as a plain 64-bit sequence number 🔢 This is a simple option for apps that don't need a real absolute timestamp and just want to know the message order. LM exception detection is an example ✨
• 2: Network Time Protocol version 4 64-bit timestamp format [RFC5905]. It's a 32-bit seconds field followed by a 32-bit fractional seconds field, so you can think of it as a fixed-point 64-bit quantity 💜
• 3: Low-order 64 bits of the IEEE 1588-2008 (1588v2) Precision Time Protocol timestamp format [IEEE1588]. This truncated version is a 32-bit seconds field followed by a 32-bit nanoseconds field, and it's the same as the IEEE 1588v1 timestamp format 🎀

okay so timestamp formats that are n < 64 bits long SHALL be encoded in the 64-bit timestamp fields using the n high-order bits 🫶 The remaining 64 - n low-order bits SHOULD be set to 0 and MUST be ignored when reading the field 🧠

so here's the big deal: to make sure implementations can always find a mode they both understand, one timestamp format has to be picked as the default 👑 The default is the truncated IEEE 1588 PTP format (format code 3 in the list above), and this format MUST be supported 🔥 The reasoning behind that choice is covered in Appendix A 📖 Implementations SHOULD also be able to read timestamps written in NTPv4 64-bit format and reconcile them internally with PTP timestamps for measurement purposes 💅 Support for other timestamp formats is OPTIONAL 🌈

last thing, and it's important: the implementation MUST make clear which timestamp formats it supports, and how far its support goes for computing with and reconciling different formats for measurement purposes 🙌

---

3.5. TLV Objects 🧚

the TLV Block in LM and DM messages is zero or more objects, each in the following format 💖

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     |        Value                  ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             TLV Format

the Type and Length fields are each 8 bits long 📦 The Length field tells you the size in bytes of the Value field, which means Value can be up to 255 bytes long 🌟

the Type space is split into Mandatory and Optional subspaces 🍰

Type Range     Semantics
-------------- ---------
0-127          Mandatory
128-255        Optional

okay this part is serious 😭 upon receipt of a query message that includes an unrecognized mandatory TLV object, the recipient MUST respond with an Unsupported Mandatory TLV Object error code 🚨

here are the types that are defined 🫧

Type           Definition
-------------- ---------------------------------
Mandatory
0              Padding - copy in response
1              Return Address
2              Session Query Interval
3              Loopback Request
4-126          Unallocated
127            Experimental use

Optional
128            Padding - do not copy in response
129            Destination Address
130            Source Address
131-254        Unallocated
255            Experimental use

3.5.1. Padding 🎀

the two padding objects let you bump up the packet size, which is mainly useful for delay measurement 📏 The type of padding tells you whether the padding from the querier gets copied into the response or left out of it 🧩 Asymmetrical padding can be handy when responses get delivered out-of-band, or when the two parts of a bidirectional channel have different maximum transmission unit sizes 🌊

more than one padding object MAY be present, but if there are several, they MUST be contiguous 💫 The Value field of a padding object is arbitrary, so put whatever you like in there 🦋

3.5.2. Addressing ✨

Okay bestie, the addressing objects have this exact shape 🎀:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |    Length     |        Address Family         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                           Address                             ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Addressing Object Format

The Address Family field tells you what kind of address you're looking at, and it SHALL be set to one of the assigned values in the "IANA Address Family Numbers" registry 🌸.

The Source and Destination Address objects are basically the "who sent this" and "who is it for" slots, so the Source Address is the sender and the Destination Address is the intended recipient. Here's the tea: 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 response mechanism has been configured, and unless a Return Address object is present. If there's a Return Address, that one is the target of the response instead 💅. The Return Address object MUST NOT appear in a response, so don't you dare put it there 🙈.

3.5.3. Loopback Request

The Loopback Request object is giving boomerang energy 🪃. When it shows up in a query, it's basically saying "please send this exact message back to me unmodified." It has a Length of 0, so there's no value to fuss over.

When the querier gets that reflected query back from the responder, it MUST NOT retransmit the message 🛑. Info that uniquely identifies the original query source, like a Source Address object, can be included so the querier can tell its own loopback queries apart from ones the far end started. Iconic self-awareness 👑.

This object may be useful when the querier only cares about the round-trip delay metric 🧚. In that case the responder doesn't need delay measurement support at all. It just needs to recognise a DM query that includes this object and return it unmodified. Low effort, high slay 💖.

3.5.4. Session Query Interval

The Value field of the Session Query Interval object is a 32-bit unsigned integer that specifies a time interval in milliseconds ⏱️.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |    Length     |            Session Query      >
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       <        Interval (ms)          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Session Query Interval Object Format

This time interval is the gap between successive query messages in a specific measurement session. The whole point of the Session Query Interval (SQI) object is so the querier and responder can agree on a query rate, like a little group-chat negotiation 🤝. The procedures for handling this object SHALL be as follows:

1. The querier tells the responder it wants to be informed of the responder's minimum query interval for this session by including the SQI object in its query messages, with a Value of 0.
2. When the responder receives a query that includes an SQI object with a Value of 0, it includes an SQI object in the response, with the Value set to the minimum query interval it supports for this session.
3. When the querier receives a response that includes an SQI object, it selects a query interval for the session that is greater than or equal to the Value specified in the SQI object, and adjusts its query transmission rate accordingly. It includes in each subsequent query an SQI object with a Value equal to the selected query interval. Once a response to one of these subsequent queries has been received, the querier infers that the responder has been apprised of the selected query interval, and it MAY then stop including the SQI object in queries associated with this session 🦋.

Similar procedures let the query rate change during the session, whether the querier or the responder starts it 🔄. For example, to inform the querier of a change in the minimum supported query interval, the responder begins including a corresponding SQI object in its responses. Then the querier adjusts its query rate if necessary and includes a corresponding SQI object in its queries until a response is received.

Shorter query intervals (i.e., higher query rates) give you finer measurement granularity, but they cost extra load on measurement endpoints and the network. See Section 6 for further discussion 🌈.

---

4. Operation ✨

4.1. Operational Overview

A loss or delay measurement operation, also called a session, is controlled by the querier. It's a sequence of query messages tied to a particular channel and a common set of measurement parameters 📡. If the session parameters include a response request, then the receiving node or nodes will (under normal conditions) generate a response message for each query message received, and those responses count as part of the session too. Every query and response in a session carries a common session identifier 🎀.

Measurement sessions get started at the discretion of the network operator, and they end either when the operator asks or when an error condition happens 💀. A session can be as brief as a single message exchange, like when an operator uses a DM query to "ping" a remote node. Or it can stick around for the whole lifetime of the channel 🧚.

When a session is started and responses are requested, the querier SHOULD initialise a timer called the SessionResponseTimeout. This timer tracks how long the querier will wait for a response before it gives up on the session and tells the user a timeout has happened ⏳. The timer lasts for the whole session and gets reset every time a response for the session comes in 💜.

When a query that requests a response arrives, a bunch of exceptional conditions can pop up and stop the responder from producing a response with valid measurement data 😭. These fall into two rough groups: transient exceptions, where recovery is possible, and fatal exceptions, which mean the session has to end. When an exception happens, the responder SHOULD generate a response with an appropriate Notification or Error control code, depending on whether the exception is transient or fatal, respectively. And if the querier gets an Error response, the session MUST be terminated and the user informed 🚨.

A classic transient exception is when a brand-new session starts and the responder needs a little time to get ready before it can give useful responses. The response control code for that situation is Notification - Initialization in Progress ⏳. Typical fatal exceptions are when the querier asks for a type of measurement the responder doesn't support, or when a query message is malformed 🙈.

When starting a session, the querier SHOULD employ the Session Query Interval mechanism (Section 3.5.4) to settle on a mutually agreeable query rate with the responder 🤝. Responders SHOULD employ rate-limiting mechanisms too, to guard against getting hit with an excessive quantity of query messages 🛡️.

4.2. Loss Measurement Procedures

4.2.1. Initiating a Loss Measurement Operation

An LM operation for a particular channel means sending a sequence (LM[1], LM[2], ...) of LM query messages over the channel at a specific rate, then processing whatever responses come back, if any 📦. As described in Section 2.2, the packet loss on the channel during the operation is computed as a delta between successive messages. Those deltas can be added up to get a running total of the packet loss for the channel, or used to derive related metrics like the average loss rate 📊.

The query message transmission rate MUST be sufficiently high 🏎️. It depends on the LM message counter size (which can be either 32 or 64 bits) and on the speed and minimum packet size of the underlying channel. The goal is that the ambiguity condition noted in Section 2.2 cannot happen. When evaluating this rate, the implementation SHOULD assume the counter size is 32 bits, unless it's explicitly configured otherwise. The exception is a bidirectional channel where all local and remote interfaces involved in the LM operation are known to be 64-bit-capable, which can be inferred from the value of the X flag in an LM response 🔍.

4.2.2. Transmitting a Loss Measurement Query

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 only if, the measurement is specific to a particular traffic class. In that case, the DS field SHALL identify that traffic class 🏷️.

The X flag MUST be set to 1 if the transmitting interface writes 64-bit LM counters. Otherwise it MUST be set to 0, to indicate that 32-bit counters are written. The B flag SHALL be set to 1 to indicate that the counter fields contain octet counts, or to 0 to indicate packet counts 🔢.

The Control Code field MUST be set to one of the values for Query messages listed in Section 3.1. And if the channel is unidirectional, this field MUST NOT be set to 0x0 (Query: In-band Response Requested) 🚫.

The Session Identifier field can be set arbitrarily 🎲.

The Origin Timestamp field SHALL be set to the time at which this message is transmitted. The Origin Timestamp Format field MUST be set to indicate its format, according to Section 3.4 ⏰.

The Counter 1 field SHOULD be set to the total count of units (packets or octets, according to the B flag) transmitted over the channel prior to this LM Query. Or it can be set to 0 if this is the beginning of a measurement session and counter data isn't available yet 🌱. The Counter 2 field MUST be set to 0. If a response was previously received in this measurement session, the Counter 1 and Counter 2 fields of the most recent such response MAY be copied to the Counter 3 and Counter 4 fields, respectively, of this query. Otherwise, the Counter 3 and Counter 4 fields MUST be set to 0 💅.

4.2.3. Receiving a Loss Measurement Query

When an LM Query message comes in, the Counter 2 field SHOULD be 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 receiving interface writes 32-bit LM counters, the X flag MUST be set to 0 🎯.

At this point, the LM Query message must be inspected 🔎. If the Control Code field is set to 0x2 (No Response Requested), an LM Response message MUST NOT be transmitted 🤐. If the Control Code field is set to 0x0 (In-band Response Requested) or 0x1 (Out-of-band Response Requested), then an in-band or out-of-band response, respectively, SHOULD be transmitted. The only time that's off the table is when an administrative, security, or congestion control mechanism has prevented it 🛑.

In the case of a fatal exception that stops the requested measurement from being made, the error SHOULD be reported. It goes via a response if one was requested, or else as a notification to the user 🚨✨

4.2.4. Transmitting a Loss Measurement Response ✨

okay bestie, this is where the responder builds its reply to an LM Query 💌 The Version field MUST be set to 0. The R flag MUST be set to 1. The T flag MUST be copied straight from the LM Query, no changes 🫶

The X flag depends on the interface. If the transmitting interface writes 32-bit LM counters, the X flag MUST be set to 0. If it doesn't, the X flag MUST be copied from the LM Query 🦋 The B flag MUST be copied from the LM Query too.

The Session Identifier, Origin Timestamp, and Origin Timestamp Format fields MUST be copied from the LM Query 💅 Then the Counter 1 and Counter 2 values from the LM Query MUST be copied into the Counter 3 and Counter 4 fields of the LM Response, in that order. It's giving reflection 🪞

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) SHOULD NOT be used if one of the other, more specific error codes applies. Be specific, bestie 🙈

Now the counters. If the response is sent in-band, the Counter 1 field SHOULD be set to the total count of units transmitted over the channel before this LM Response. If the response is sent out-of-band, the Counter 1 field MUST be set to 0 🌸 Either way, the Counter 2 field MUST be set to 0.

---

4.2.5. Receiving a Loss Measurement Response 🎀

When an LM Response comes in-band, the Counter 2 field gets set to the total count of units received over the channel before this LM Response. If the receiving interface writes 32-bit LM counters, the X flag is set to 0 💖 (The LM message's life in the network is over at this point, so the receiver decides whether these last changes get made to the packet. But if the message is going to be forwarded for external post-processing (Section 2.9.7), then these modifications MUST be made. Don't skip it, or the post-processing gets messy 😭)

When an LM Response comes out-of-band, the Counter 1 and Counter 2 fields MUST NOT be used for loss measurement. Not even a peek 🙈

If the Control Code in an LM Response is anything other than 0x1 (Success), the counter values in that response MUST NOT be used for loss measurement. And if the Control Code shows an error, or the response is invalid, the LM operation MUST be terminated and an appropriate notification MUST be generated for the user 🚨

---

4.2.6. Loss Calculation 🧮

Packet loss gets calculated using the procedures in Section 2.2. The X flag in an LM message tells the device doing the math whether to use 32-bit or 64-bit arithmetic. If the flag is equal to 1, every interface involved in the LM operation wrote 64-bit counter values, so 64-bit arithmetic can be used ✨ If the flag is equal to 0, at least one interface involved wrote a 32-bit counter value, so the math is done with the low-order 32 bits of each counter value.

Here's the iconic part: the X flag lets all devices interoperate no matter their counter size support 👑 So an implementation MUST NOT generate an error response based on the value of this flag. Zero drama, periodt 💅

---

4.2.7. Quality of Service 💜

The TC field of the LSE that corresponds to the channel being measured (e.g., LSP) SHOULD be set to a traffic class equal to or better than the best TC within the measurement scope. The goal is to minimize the chance of out-of-order conditions 🏃‍♀️💨

---

4.2.8. G-ACh Packets 🌈

By default, direct LM MUST exclude packets transmitted and received over the Generic Associated Channel (G-ACh). Lowkey important! 🙅‍♀️ An implementation MAY provide a way to alter the direct LM scope so it includes some or all G-ACh messages. Care must be taken when changing the LM scope, though, so that both endpoints are on the same page 🫶

---

4.2.9. Test Messages 🧪

For inferred LM, the packets that get counted consist of test messages made for this purpose, or some other class of packets that serve as a good proxy for data packets flowing over the channel. The details of test protocols and proxy packets are outside the scope of this document, but there are some guidelines below 📖

An identifier shared by the test or proxy messages and the LM messages may be required to make correlation possible. The combined value of the Session Identifier and DS fields SHOULD be used for this purpose when possible. So test messages will include a 32-bit field that can carry the value of the combined Session Identifier + DS field present in LM messages 🎯 When TC-specific LM is conducted, the DS field of the LSE in the label stack of a test message, for the channel (e.g., LSP) it travels over, MUST correspond to the DS value in the associated LM messages.

A separate test message protocol SHOULD include a timeout value in its messages. That tells the responder when to discard any state tied to a specific test ⏰

---

4.2.10. Message Loss and Packet Misorder Conditions 🌀

An LM operation is a message sequence with state carried from one message to the next. That means LM is affected by lost messages and misordered packets in a way that DM isn't 😤 Since this state only lives on the querier, handling these conditions is, strictly speaking, a local matter. This section still presents recommended procedures for handling them, though. And in the absence of ECMP, packet misordering within a traffic class is a pretty rare event 🌸

First up, one or more LM messages might get lost in transit. When an LM Response is next received at the querier, the counter values in it may be impossible to interpret unambiguously, for the reasons described at the end of Section 2.2. Whether that happens depends on how many messages were lost and on the other variables mentioned there, like the LM message rate and the channel parameters 📉

Another possibility is that LM messages get misordered in transit. For instance, the response to LM[n] might arrive before the response to LM[n-1]. A typical implementation will discard the late response to LM[n-1], so the effect is the same as a lost message 🙃

Finally, LM is subject to the possibility that data packets are misordered relative to LM messages 🌪️ This can result, for example, in a transmit count of 100 and a corresponding receive count of 101. The effect is that the A_TxLoss[n-1,n] value (for example) for a given measurement interval will look extremely (if not impossibly) large 😳 The other case, where an LM message arrives earlier than some of the packets, just means those packets get counted as lost.

An implementation SHOULD identify a threshold that indicates the upper bound of lost packets measured in a single computation. Past that bound, the interval is considered unmeasurable. This is called the "MaxLMIntervalLoss threshold". It's clear that this threshold should be no higher than the maximum number of packets (or bytes) the channel can transmit over the interval, but it may be lower 📏 When you hit an unmeasurable interval, the LM state (i.e., the data values from the last LM message received) SHOULD be discarded 🗑️

For lost LM messages, the MaxLMInterval (see Section 2.2) is the maximum amount of time that can pass before the LM state gets discarded ⏳ If some messages are lost but a message is later received within MaxLMInterval, its timestamp or sequence number will quantify the loss. That message MAY still be used for measurement, although the measurement interval will be longer than usual 💫

If an LM message arrives with a timestamp less than or equal to the timestamp of the last LM message received, that means an exception has occurred. The current interval SHOULD be considered unmeasurable, unless the implementation has some other way of handling this condition 🚫

---

4.3. Delay Measurement Procedures ⏱️

4.3.1. Transmitting a Delay Measurement Query 🚀

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, and the remaining flag bits MUST be set to 0 🎀

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, this field MUST NOT be set to 0x0 (Query: In-band Response Requested). No in-band requests on a one-way street 🛣️

The Querier Timestamp Format field MUST be set to the timestamp format the querier uses when writing timestamp fields in this message. The possible values for this field are listed in Section 3.4. The Responder Timestamp Format and Responder's Preferred Timestamp Format fields MUST be set to 0 🧸

The Session Identifier field can be set arbitrarily, so have fun with it 🦄 The DS field MUST be set to the traffic class being measured.

The Timestamp 1 field SHOULD be set to the time this DM Query is transmitted, in the format indicated by the Querier Timestamp Format field. The Timestamp 2 field MUST be set to 0. If a response was previously received in this measurement session, the Timestamp 1 and Timestamp 2 fields of the most recent such response MAY be copied to the Timestamp 3 and Timestamp 4 fields of this query, respectively. Otherwise, the Timestamp 3 and Timestamp 4 fields MUST be set to 0 🕰️

---

4.3.2. Receiving a Delay Measurement Query 📬

When a DM Query message arrives, the Timestamp 2 field SHOULD be set to the time at which this DM Query was received ⏲️

At this point, the DM Query message must be inspected. If the Control Code field is set to 0x2 (No Response Requested), a DM Response message MUST NOT be transmitted. If the Control Code field is set to 0x0 (In-band Response Requested) or 0x1 (Out-of-band Response Requested), then an in-band or out-of-band response, respectively, SHOULD be transmitted. The exception is when an administrative, security, or congestion control mechanism has prevented it 🚦

If there's a fatal exception that stops the requested measurement from happening, the error SHOULD be reported. It goes out via a response if one was requested, or else as a notification to the user 🚨

4.3.3. Transmitting a Delay Measurement Response 📤

okay so when you're building 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 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 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 fields, respectively, of the DM Response ✨.

The Responder Timestamp Format (RTF) field MUST be set to the timestamp format the responder uses when writing timestamp fields in this message, i.e., Timestamp 4 and (if applicable) Timestamp 1 🕰️. The possible values for this field are listed in Section 3.4. Furthermore, the RTF field MUST be set equal to either the QTF or the RPTF field. See Section 4.3.5 for guidelines on picking the value for this field 🧚.

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 whichever timestamp format the responder can provide the best accuracy with for delay measurement 🎀.

The Control Code field MUST be set to one of the Response message values listed in Section 3.1. The value 0x10 (Unspecified Error) SHOULD NOT be used if one of the other, more specific error codes applies 🙈.

If the response is sent in-band, the Timestamp 1 field SHOULD be set to the time this DM Response is transmitted ⏰. If the response is sent out-of-band, the Timestamp 1 field MUST be set to 0. In either case, the Timestamp 2 field MUST be set to 0 🌸.

If the response is sent in-band and the Control Code in the 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 Responder Timestamp Format field 👑.

4.3.4. Receiving a Delay Measurement Response 📥

Upon in-band receipt of a DM Response message, the Timestamp 2 field is set to the time this DM Response was received 🫧. (Since the life of the DM message in the network has ended at this point, it 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-processing (Section 2.9.7), then these modifications MUST be made.)

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 measurement 🚫.

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 purposes of delay measurement 💀. If the Control Code indicates an error condition, or if the response message is invalid, the DM operation MUST be terminated and an appropriate notification generated for the user 🚨.

4.3.5. Timestamp Format Negotiation 🤝

If either the querier or the responder in a DM transaction can support multiple timestamp formats, it's desirable to figure out the optimal format for delay measurement on a particular channel 🔍. The procedures for making this determination SHALL be as follows.

Upon sending an initial DM Query over a channel, the querier sets the Querier Timestamp Format (QTF) field to its preferred timestamp format 🎯.

Upon receiving any DM Query message, the responder determines whether it is capable of writing timestamps in the format specified by the QTF field. If so, the Responder Timestamp Format (RTF) field is set equal to the QTF field. If not, the RTF field is set equal to the Responder's Preferred Timestamp Format (RPTF) field 🪞.

Changing from one timestamp format to another at the responder may result in the Timestamp 1 and Timestamp 4 fields in an in-band DM Response having different formats 😭. If this is the case, the Control Code in the response MUST NOT be set to 0x1 (Success). Unless an error condition has occurred, the Control Code MUST be set to 0x2 (Notification - Data Format Invalid).

Upon receiving a DM Response, the querier knows from the RTF field in the message whether the responder is capable of supporting its preferred timestamp format: if it is, the RTF will be equal to the QTF. The querier also learns the responder's preferred timestamp format from the RPTF field. The querier can then decide whether to keep its current QTF or change it and repeat the negotiation procedures 🔁.

4.3.5.1. Single-Format Procedures 🎈

When an implementation supports only one timestamp format, the procedures above reduce to the following simple behavior:

• All DM Queries are transmitted with the same QTF;
• All DM Responses are transmitted with the same RTF, and the RPTF is always set equal to the RTF;
• All DM Responses received with RTF not equal to QTF are discarded;
• On a unidirectional channel, all DM Queries received with QTF not equal to the supported format are discarded.

4.3.6. Quality of Service 💜

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 field in the DM message 🌈.

4.4. Combined Loss/Delay Measurement Procedures 🧩

The combined LM/DM message defined in Section 3.3 lets you do loss and delay measurement at the same time ⏱️📦. This message SHOULD be treated as an LM message that happens to carry additional timestamp data, with the timestamp fields processed according to the delay measurement procedures 💖.

---

5. Implementation Disclosure Requirements 📢

This section sums up the requirements placed on implementations for capabilities disclosure 📝. The point of these requirements is to make sure end users clearly understand the implementation capabilities and characteristics that directly affect how loss and delay measurement mechanisms work in specific situations 🔎. Implementations are REQUIRED to state:

• METRICS: Which of the following metrics are supported: packet loss, packet throughput, octet loss, octet throughput, average loss rate, one-way delay, round-trip delay, two-way channel delay, packet delay variation 📊.
• MP-LOCATION: The location of loss and delay measurement points with respect to other stages of packet processing, such as queuing 📍.
• CHANNEL-TYPES: The types of channels for which LM and DM are supported, including LSP types, pseudowires, and sections (links) 🛣️.
• QUERY-RATE: The minimum supported query intervals for LM and DM sessions, in both the querier and responder roles 🐢.
• LOOP: Whether loopback measurement (Section 2.8) is supported 🔁.
• LM-TYPES: Whether direct or inferred LM is supported and, for the latter, which test protocols or proxy message types are supported 🧪.
• LM-COUNTERS: Whether 64-bit counters are supported 🔢.
• LM-ACCURACY: The expected measurement accuracy levels for the supported forms of LM, and the expected impact of exception conditions such as lost and misordered messages 🎯.
• LM-SYNC: The implementation's behavior regarding the synchronization conditions discussed in Section 2.9.8 🤸.
• LM-SCOPE: The supported LM scopes (Sections 2.9.9 and 4.2.8) 🔭.
• DM-ACCURACY: The expected measurement accuracy levels for the supported forms of DM 🎯.
• DM-TS-FORMATS: The supported timestamp formats, and the extent of support for computation with and reconciliation of different formats 🕰️.

---

6. Congestion Considerations 🚦

An MPLS network may be traffic-engineered so that the bandwidth needed for client traffic, and for control, management, and OAM traffic, is always available 🛤️. The following congestion considerations therefore apply only when that isn't the case.

Proactively generating Loss Measurement and Delay Measurement messages to monitor the performance of an MPLS channel naturally adds some load to both the network and the terminal nodes of the channel 📈. When configuring this kind of monitoring, operators should be mindful of the overhead involved and should choose transmit rates that don't stress network resources unduly; such choices must be informed by the deployment context 🧠. For slower links or lower-speed devices, for example, lower Loss Measurement message rates can be chosen, up to the limits noted at the end of Section 2.2 🐌.

In general, lower measurement message rates put less load on the network, but at the cost of reduced granularity 🍃. For delay measurement, that reduced granularity means a greater chance that the delay on a channel temporarily goes above the expected threshold without anyone noticing 😬. For loss measurement, it means a bigger gap in loss information during exceptional circumstances, such as lost LM messages or misordered packets 🕳️.

When carrying out a sustained measurement operation, such as an LM operation or continuous proactive DM operation, the querier SHOULD take note of the number of lost measurement messages (queries for which a response is never received) and set a corresponding Measurement Message Loss Threshold 📉. If this threshold is exceeded, the measurement operation SHOULD be suspended so it doesn't make the possible congestion condition worse 🛑. This suspension SHOULD be accompanied by an appropriate notification to the user, so the condition can be investigated and fixed 🔔.

From the receiver's perspective, the main concern is the possibility of receiving an excessive number of measurement messages 📬. An implementation SHOULD employ a mechanism such as rate-limiting to guard against the effects of this case 🛡️.

---

7. Manageability Considerations 🛠️

The measurement protocols described in this document are meant to serve as infrastructure for a wide range of higher-level monitoring and diagnostic applications 🏗️. That runs from simple command-line diagnostic tools all the way up to comprehensive network performance monitoring and analysis packages 💻. So the specific mechanisms and considerations for protocol configuration, initialization, and reporting depend on what the application is for 🎀.

For on-demand diagnostics, the diagnostic application may provide parameters such as the measurement type, the channel, the query rate, and the test duration when it starts the diagnostic 🩺. Results and exception conditions are then reported directly back to the application ✅. The system may discard the statistics gathered during the test once the results have been reported, or keep them to build a historical measurement record 📚.

Alternatively, measurement configuration may be supplied as part of the channel configuration itself, to support continuous monitoring of the channel's performance characteristics 🔄. In this case, the configuration will typically include quality thresholds based on the service level agreement. Crossing those thresholds triggers warnings or alarms, and result reporting and exception notification get folded into the system-wide network management and reporting framework 🚨🫶.

8. Security Considerations 🛡️

okay so this doc is all about measuring performance on an MPLS path that already exists (a pseudowire, LSP, or section) 🛤️ which means it assumes a node has already checked that the path is legit and confirmed who the far end is, using stuff like Bidirectional Forwarding Detection (BFD) [RFC5884]. the whole MPLS security toolbox gets the deep dive in [RFC5920] 💅

when those checks aren't available and security of the measurement is a concern, reception of Generic Associated Channel messages with the Channel Types from this doc SHOULD be disabled 🔒 and implementations MUST let you turn these protocols off on a per-Channel-Type basis. bestie, that's a must-have 💖

even when the far end is verified, the measurement protocols are still open to injection and man-in-the-middle attacks 😭 the damage? the quality of the performance measurements on that path gets compromised. BUT an attacker who can mess with measurements could do way worse by wrecking things like the control plane or user traffic flows. the worst case is that measurement gets disrupted and you can't watch the performance side of the SLA for that path, and honestly, that disruption would already mean a serious breach of basic path integrity had happened 💀

if you want, you can cut these attacks off with basic validation and sanity checks, done at the querier, on the counter or timestamp fields in received measurement response messages 🧠 and the minimal state these protocols keep means a corrupt or invalid message can only mess things up within a single query/response cycle 🌸

cryptographic mechanisms that can sign or encrypt the measurement packets without hurting measurement performance aren't currently available 😔 given everything above, not having them doesn't raise significant security issues ✨

users who care about the security of out-of-band responses over IP networks SHOULD use suitable security mechanisms like IPsec [RFC4301] to protect the integrity of the return path 🫶

---

9. IANA Considerations 🎀

okay IANA has already done the following things for this doc 📝

• Allocation of Channel Types in the "PW Associated Channel Type" registry
• Creation of a "Measurement Timestamp Type" registry
• Creation of an "MPLS Loss/Delay Measurement Control Code" registry
• Creation of an "MPLS Loss/Delay Measurement Type-Length-Value (TLV) Object" registry

9.1. Allocation of PW Associated Channel Types

as per the IANA considerations in [RFC5586], IANA has handed out these Channel Types in the "PW Associated Channel Type" registry 🦋

Value  Description                              TLV Follows Reference
------ ---------------------------------------- ----------- ---------
0x000A MPLS Direct Loss Measurement (DLM)       No          RFC 6374
0x000B MPLS Inferred Loss Measurement (ILM)     No          RFC 6374
0x000C MPLS Delay Measurement (DM)              No          RFC 6374
0x000D MPLS Direct Loss and Delay Measurement   No          RFC 6374
       (DLM+DM)
0x000E MPLS Inferred Loss and Delay Measurement No          RFC 6374
       (ILM+DM)

9.2. Creation of Measurement Timestamp Type Registry

IANA has created a brand new "Measurement Timestamp Type" registry 🌈 here's the format and the starter allocations:

Type Description                               Size in Bits Reference
---- ----------------------------------------- ------------ ---------
0    Null Timestamp                            64           RFC 6374
1    Sequence Number                           64           RFC 6374
2    Network Time Protocol version 4 64-bit    64           RFC 6374
     Timestamp
3    Truncated IEEE 1588v2 PTP Timestamp       64           RFC 6374

the range of the Type field is 0-15 🍓

the allocation policy for this registry is IETF Review 📋

9.3. Creation of MPLS Loss/Delay Measurement Control Code Registry

IANA has created a new "MPLS Loss/Delay Measurement Control Code" registry ✨ it's split into two parts, one for Query Codes and one for Response Codes, with these formats and starter allocations:

Query Codes

Code Description                    Reference
---- ------------------------------ ---------
0x0  In-band Response Requested     RFC 6374
0x1  Out-of-band Response Requested RFC 6374
0x2  No Response Requested          RFC 6374

Response Codes

Code Description                         Reference
---- ----------------------------------- ---------
0x0  Reserved                            RFC 6374
0x1  Success                             RFC 6374
0x2  Data Format Invalid                 RFC 6374
0x3  Initialization in Progress          RFC 6374
0x4  Data Reset Occurred                 RFC 6374
0x5  Resource Temporarily Unavailable    RFC 6374
0x10 Unspecified Error                   RFC 6374
0x11 Unsupported Version                 RFC 6374
0x12 Unsupported Control Code            RFC 6374
0x13 Unsupported Data Format             RFC 6374
0x14 Authentication Failure              RFC 6374
0x15 Invalid Destination Node Identifier RFC 6374
0x16 Connection Mismatch                 RFC 6374
0x17 Unsupported Mandatory TLV Object    RFC 6374
0x18 Unsupported Query Interval          RFC 6374
0x19 Administrative Block                RFC 6374
0x1A Resource Unavailable                RFC 6374
0x1B Resource Released                   RFC 6374
0x1C Invalid Message                     RFC 6374
0x1D Protocol Error                      RFC 6374

IANA has indicated that the values 0x0 - 0xF in the Response Code section are reserved for non-error response codes 🙌

the range of the Code field is 0 - 255 💅

the allocation policy for this registry is IETF Review 📋

9.4. Creation of MPLS Loss/Delay Measurement TLV Object Registry

IANA has created a new "MPLS Loss/Delay Measurement TLV Object" registry, with this format and these starter allocations 🧚

Type Description                       Reference
---- --------------------------------- ---------
0    Padding - copy in response        RFC 6374
1    Return Address                    RFC 6374
2    Session Query Interval            RFC 6374
3    Loopback Request                  RFC 6374
127  Experimental use                  RFC 6374
128  Padding - do not copy in response RFC 6374
129  Destination Address               RFC 6374
130  Source Address                    RFC 6374
255  Experimental use                  RFC 6374

IANA has indicated that Types 0-127 are classified as Mandatory, and Types 128-255 are classified as Optional 🎀

the range of the Type field is 0 - 255 🌸

the allocation policy for this registry is IETF Review 📋

---

10. Acknowledgments 💜

the authors want to thank the many people from the MPLS working group who gave super detailed reviews and feedback on this doc 🫶 they also give a special shoutout to Alexander Vainshtein, Loa Andersson, and Hiroyuki Takagi for all the helpful thoughts and discussions, to Linda Dunbar for the idea of using LM messages for throughput measurement (iconic 👑), and to Ben Niven-Jenkins, Marc Lasserre, and Ben Mack-Crane for their valuable comments ✨

11. References 📚

11.1. Normative References

• [IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", March 2008.
• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
• [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
• [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
• [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
• [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009.
• [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.

11.2. Informative References ✨

okay so these are the bonus reads, bestie 📚 they're not required to implement the thing, but they give you the full backstory on the measurement metrics, the MPLS architecture, and the security stuff 🧠

[RFC2679]   Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
            Delay Metric for IPPM", RFC 2679, September 1999.

[RFC2680]   Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
            Packet Loss Metric for IPPM", RFC 2680, September 1999.

[RFC2681]   Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
            Delay Metric for IPPM", RFC 2681, September 1999.

[RFC3209]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
            and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
            Tunnels", RFC 3209, December 2001.

[RFC3260]   Grossman, D., "New Terminology and Clarifications for
            Diffserv", RFC 3260, April 2002.

[RFC3985]   Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
            Edge (PWE3) Architecture", RFC 3985, March 2005.

[RFC4301]   Kent, S. and K. Seo, "Security Architecture for the
            Internet Protocol", RFC 4301, December 2005.

[RFC4656]   Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
            Zekauskas, "A One-way Active Measurement Protocol
            (OWAMP)", RFC 4656, September 2006.

[RFC4928]   Swallow, G., Bryant, S., and L. Andersson, "Avoiding
            Equal Cost Multipath Treatment in MPLS Networks",
            BCP 128, RFC 4928, June 2007.

[RFC5036]   Andersson, L., Minei, I., and B. Thomas, "LDP
            Specification", RFC 5036, October 2007.

[RFC5357]   Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
            Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
            RFC 5357, October 2008.

[RFC5481]   Morton, A. and B. Claise, "Packet Delay Variation
            Applicability Statement", RFC 5481, March 2009.

[RFC5884]   Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
            "Bidirectional Forwarding Detection (BFD) for MPLS Label
            Switched Paths (LSPs)", RFC 5884, June 2010.

[RFC5920]   Fang, L., "Security Framework for MPLS and GMPLS
            Networks", RFC 5920, July 2010.

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

[RFC5960]   Frost, D., Bryant, S., and M. Bocci, "MPLS Transport
            Profile Data Plane Architecture", RFC 5960, August 2010.

[RFC6375]   Frost, D., Ed. and S. Bryant, Ed., "A Packet Loss and
            Delay Measurement Profile for MPLS-Based Transport
            Networks", RFC 6375, September 2011.

[Y.1731]    ITU-T Recommendation Y.1731, "OAM Functions and
            Mechanisms for Ethernet based Networks", February 2008.

Appendix A. Default Timestamp Format Rationale 🕰️

okay the timestamp drama is actually so iconic 😭 this document originally wanted the Network Time Protocol (NTP) timestamp format to be the mandatory default, because that's the usual default in IETF protocols, so it felt like the "natural" pick 💅 but then a bunch of stuff happened and the vibe shifted 🔄

NTP never really caught on in industry as the go-to for high-quality timing infrastructure, meanwhile IEEE 1588 Precision Time Protocol (PTP) basically became the de facto time transfer protocol in networks that are specially engineered for high-accuracy time distribution 🎯 the PTP timestamp format is also the ITU-T format of choice for packet transport networks, which may rely on MPLS protocols 🌐 and applications like one-way delay measurement need the best time service available ⏱️ converting between NTP and PTP isn't a trivial glow-up either, especially when it has to happen in real time without losing accuracy 😵‍💫

so the truncated IEEE 1588 PTP format in this document is considered more than adequate 💖 it gives a wrap time and time resolution that's way more than the operational lifetime of this protocol is expected to need ✨ and by truncating the timestamp at both the high and low order bits, you get a really worthwhile reduction in system resources 🧚

---

Authors' Addresses 🎀

Dan Frost
Cisco Systems

EMail: danfrost@cisco.com


Stewart Bryant
Cisco Systems

EMail: stbryant@cisco.com