RFC 9779

Performance Measurement for Segment Routing Networks with the MPLS Data Plane

📅 published May 2025, from ietf

RFC 9779: Performance Measurement for Segment Routing Networks with the MPLS Data Plane 🎀

Okay bestie, the title block first 💅 This is an IETF document on the Standards Track (ISSN 2070-1721), dated May 2025. The authors are R. Gandhi (Ed.) and C. Filsfils and D. Voyer at Cisco Systems, Inc., S. Salsano at Universita di Roma "Tor Vergata", and M. Chen at Huawei. The header doesn't list any Obsoletes or Updates entries, so this doesn't replace or change any earlier RFC, per the header 🫶

Abstract ✨

Okay so this doc takes the MPLS loss and delay measurement tools from RFCs 6374, 7876, and 9341 and makes them work inside Segment Routing (SR) networks that run on the MPLS data plane, which people call Segment Routing over MPLS (SR-MPLS) 🦋 SR lets packets follow an ordered list of instructions called segments, and those get stuck on at the ingress node. The whole point is giving operators the procedures and extensions they need to measure packet loss and delay accurately, so they can keep an eye on quality of service across their SR-MPLS networks 👑 It covers links, end-to-end SR-MPLS paths, and SR Policies, obsessed.

Status of This Memo ✨

This is an Internet Standards Track document 🌸

It's a product of the Internet Engineering Task Force (IETF), it reflects what the IETF community agreed on, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. More info on Internet Standards is in Section 2 of RFC 7841.

Info about the current status, any errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc9779 🧚

Copyright (c) 2025 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 (https://trustee.ietf.org/license-info) as they stand on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Revised BSD License 🍓

Table of Contents 🌈

1.  Introduction
2.  Conventions Used in This Document
  2.1.  Requirements Language
  2.2.  Abbreviations
  2.3.  Reference Topology
3.  Overview
4.  Query and Response Messages
  4.1.  Query Message for Links and SR-MPLS Policies
    4.1.1.  Query Message for Links
    4.1.2.  Query Message for SR-MPLS Policies
  4.2.  Response Message for Links and SR-MPLS Policies
    4.2.1.  One-Way Measurement Mode
    4.2.2.  Two-Way Measurement Mode
    4.2.3.  Loopback Measurement Mode
5.  Delay and Loss Measurement
  5.1.  Delay Measurement Message
  5.2.  Loss Measurement Message
  5.3.  Combined Loss/Delay Measurement Message
  5.4.  Counters
  5.5.  Block Number for Counters
6.  TLV Extensions
  6.1.  Return Path TLV Extension
    6.1.1.  Return Path Sub-TLV Extension
  6.2.  Block Number TLV Extension
7.  ECMP for SR-MPLS Policies
8.  Extended TE Link Metrics Advertisement
9.  Backwards Compatibility
10. Manageability Considerations
11. Security Considerations
12. IANA Considerations
13. References
  13.1.  Normative References
  13.2.  Informative References
Acknowledgments
Contributors
Authors' Addresses

1. Introduction 🦋

Segment Routing (SR), as specified in [RFC8402], uses the source routing paradigm and works with both the Multiprotocol Label Switching (MPLS) and Internet Protocol version 6 (IPv6) data planes. Those are called Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6). SR takes advantage of Equal-Cost Multipaths (ECMPs) between source and transit nodes, between transit nodes, and between transit and destination nodes. SR Policies, defined in [RFC9256], steer traffic along specific, user-defined paths using a list of segments 💅

A full SR Performance Measurement toolset is one of the essentials if you want to measure network performance for Service Level Agreements (SLAs) 🫶

[RFC6374] defines protocol mechanisms for measuring packet loss, one-way and two-way delay, and related metrics like delay-variation in MPLS networks, all done efficiently and accurately 🔥

[RFC7876] defines how to send and process out-of-band responses over a UDP return path when query messages from [RFC6374] come in. Those mechanisms can be applied to SR-MPLS networks ✨

[RFC9341] defines the Alternate-Marking Method using Block Numbers as a data correlation mechanism for packet loss measurement 🌸

This document uses the mechanisms from [RFC6374], [RFC7876], and [RFC9341] for delay and loss measurements in SR-MPLS networks. That covers links, end-to-end SR-MPLS paths, and SR Policies 💖

This document extends [RFC6374] by defining Return Path and Block Number TLVs (see Section 6) for delay and loss measurement in SR-MPLS networks. These TLVs can also be used in MPLS Label Switched Paths (LSPs) [RFC3031]. However, the procedure for delay and loss measurement of MPLS LSPs is outside the scope of this document 🧚

2. Conventions Used in This Document ✨

2.1. Requirements Language 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Lowercase versions don't count, bestie 🙈

2.2. Abbreviations 🌈

  • ACH: Associated Channel Header
  • DM: Delay Measurement
  • ECMP: Equal-Cost Multipath
  • G-ACh: Generic Associated Channel
  • GAL: Generic Associated Channel Label
  • LM: Loss Measurement
  • LSE: Label Stack Entry
  • MPLS: Multiprotocol Label Switching
  • PSID: Path Segment Identifier
  • SID: Segment Identifier
  • SL: Segment List
  • SR: Segment Routing
  • SR-MPLS: Segment Routing over MPLS
  • TC: Traffic Class
  • TE: Traffic Engineering
  • TTL: Time to Live
  • URO: UDP Return Object

2.3. Reference Topology 🍓

In the reference topology in Figure 1, the querier node Q1 starts a query message, and the responder node R1 sends back a response message for the query it got. The response message may go back to Q1 on the same path (same set of links and nodes), or on a different path in the reverse direction from the path taken toward R1 🦋

T1 is a transmit timestamp and T4 is a receive timestamp, and both get added by Q1. T2 is a receive timestamp and T3 is a transmit timestamp, and both get added by R1 💜

SR is enabled with the MPLS data plane on Q1 and R1. Q1 and R1 are connected via a channel (Section 2.9.1 of [RFC6374]). That channel may be a directly connected link enabled with MPLS (Section 2.9.1 of [RFC6374]) or an SR-MPLS path [RFC8402]. The link may be a physical interface, a virtual link, a Link Aggregation Group (LAG) [IEEE802.1AX], or a LAG member link. The SR-MPLS path may be an SR-MPLS Policy [RFC9256] on node Q1 (called the "head-end") with the destination at node R1 (called the "tail-end") 👑

          T1                T2
         /                   \
+-------+       Query         +-------+
|       | - - - - - - - - - ->|       |
|   Q1  |=====================|   R1  |
|       |<- - - - - - - - - - |       |
+-------+       Response      +-------+
         \                   /
          T4                T3
 Querier                       Responder

                    Figure 1: Reference Topology

3. Overview 🌸

In this document, the procedures from [RFC6374], [RFC7876], and [RFC9341] are used for delay and loss measurement in SR-MPLS networks. Specifically, the one-way, two-way, and round-trip delay measurements described in Section 2.4 of [RFC6374] get elaborated further for SR-MPLS networks. Similarly, the packet loss measurement procedures in Section 2.2 of [RFC6374] get extended for SR-MPLS networks 🔥

Packet loss measurement using the Alternate-Marking Method from [RFC9341] may use the Block Number for data correlation. That happens with the Block Number TLV extension defined in this document ✨

In SR-MPLS networks, the query messages defined in [RFC6374] MUST be sent along the same path as the data traffic for links and end-to-end SR-MPLS paths. This way, delay measurement collects both transmit and receive timestamps, and loss measurement collects both transmit and receive traffic counters 💖

If the querier and responder need the same path (same set of links and nodes) in both directions of the measurement, the Return Path TLV extension defined in this document can get that done 🧚

The performance measurement procedures for links can compute extended Traffic Engineering (TE) metrics for delay and loss, as described here. These metrics get advertised in the network using the routing protocol extensions defined in [RFC7471], [RFC8570], and [RFC8571] 👑

4. Query and Response Messages ✨

The query message, as defined in [RFC6374], gets sent over links for both delay and loss measurement. In each Label Stack Entry (LSE) [RFC3032] in the MPLS label stack, the TTL value MUST be set to 255 [RFC5082] 🫶

4.1.2. Query Message for SR-MPLS Policies 🎀

okay so bestie, an SR-MPLS Policy Candidate-Path can hold a bunch of Segment Lists (SLs), and each SL is basically a stack of MPLS labels [RFC9256] 🧚. For delay and/or loss measurement on an end-to-end SR-MPLS Policy, you MUST send query messages for every SL of the Candidate-Path 💅. The way you do that is by making a separate session for each SL 🦋. Every query message in a session carries the SR-MPLS label stack of the Candidate-Path, with the G-ACh Label (GAL) sitting at the bottom of the stack with S=1, like in Figure 2 ✨. And in each LSE in the MPLS label stack, the TTL value MUST be set to 255 [RFC5082] 👑.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Label(1)             | TC  |S|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                                                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Label(n)             | TC  |S|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  GAL (value 13)       | TC  |1|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version| Reserved      |       Channel Type            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 2: Example Query Message Header for an End-to-End SR-MPLS
                                   Policy

The fields 0001, Version, Reserved, and Channel Type shown in Figure 2 are specified in [RFC5586] 📚.

The SR-MPLS label stack can be empty in the case of a one-hop SR-MPLS Policy with an Implicit NULL label 🌸.

For an SR-MPLS Policy, to make sure the query message gets processed by the intended responder, the Destination Address TLV (Type 129) [RFC6374] containing an address of the responder can be sent in the query messages 🫶. The responder that supports this TLV MUST return Control Code 0x1 (Success) [RFC6374] if it is the intended destination for the query. Otherwise, it MUST return Error 0x15: Invalid Destination Node Identifier [RFC6374] 😭.

4.2.1. One-Way Measurement Mode

In one-way measurement mode, as defined in Section 2.4 of [RFC6374], the querier can set the UDP Return Object (URO) TLV in the query message 💖. That lets the querier receive the out-of-band response message, encapsulated in an IP/UDP header, sent to the IP address and UDP port specified in the URO TLV 🦋. The URO TLV (Type 131) is defined in [RFC7876] and includes the UDP-Destination-Port and IP address 🍓. When the querier sets an IP address and a UDP port in the URO TLV, the response message MUST be sent to that IP address, with that IP address as the destination address and the UDP port as the destination port 🔥. On top of that, the Control Code in the query message MUST be set to Out-of-band Response Requested [RFC6374] ✨.

4.2.2. Two-Way Measurement Mode

In the two-way measurement mode defined in Section 2.4 of [RFC6374], the response messages SHOULD be sent back one of two ways 💜: either they go back in-band on the same link, or they go back on the same end-to-end SR-MPLS path (so, the same set of links and nodes) in the reverse direction to the querier 🌸. The point of this is to get accurate two-way delay measurement 🧚.

For links, the response message as defined in [RFC6374] is sent back on the same incoming link where the query message was received 🎀. In this case, the Control Code in the query message MUST be set to In-band Response Requested [RFC6374] 💅.

For end-to-end SR-MPLS paths, the responder transmits the response message (see the example in Figure 2) on a specific return SR-MPLS path 🦋. In the query message, the querier can ask the responder to send the response message back on a given return path, using the MPLS Label Stack Sub-TLV in the Return Path TLV defined in this document 💖.

4.2.3. Loopback Measurement Mode

The loopback measurement mode defined in Section 2.8 of [RFC6374] is used to measure round-trip delay for a bidirectional circular path [RFC6374] in SR-MPLS networks 🌈. In this mode for SR-MPLS, the received query messages are not punted out of the fast path in forwarding (i.e., to the slow path or control plane) at the responder 🚀. In other words, the responder does not process the payload or generate response messages 🙈. The loopback function simply returns the received query message to the querier without responder modifications [RFC6374] 🔁.

The loopback mode is done by generating "queries" with the Response flag set to 1 and adding the Loopback Request object (Type 3) [RFC6374] 🧁. In query messages, the label stack, as shown in Figure 3, carries both the forward and reverse path labels in the MPLS header 🍭. The GAL is still carried at the bottom of the label stack (with S=1) 💫.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Label(1)             | TC  |S|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                                                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Label(n)             | TC  |S|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Reverse Path Label(1)| TC  |S|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                                                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Reverse Path Label(n)| TC  |S|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  GAL (value 13)       | TC  |1|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version| Reserved      |       Channel Type            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 3: Example Query Message Header for an End-to-End SR-MPLS
                  Policy in the Loopback Measurement Mode

5. Delay and Loss Measurement ⏱️

5.1. Delay Measurement Message

As defined in [RFC6374], MPLS Delay Measurement (DM) query and response messages use the Associated Channel Header (ACH) with value 0x000C for delay measurement 🌷. That value identifies the message type and the message payload that follow the ACH, as defined in Section 3.2 of [RFC6374] 🫧. For delay measurement, the same ACH value is used for both links and end-to-end SR-MPLS Policies 💖.

5.2. Loss Measurement Message

The Loss Measurement (LM) protocol can do two distinct kinds of loss measurement, as described in Section 2.9.8 of [RFC6374] 🕵️‍♀️.

  • In the inferred mode, LM measures the loss of specially generated test messages to infer the approximate data plane loss level. Inferred mode LM provides only approximate loss accounting 🤏.
  • In the direct mode, LM directly measures data plane packet loss. Direct mode LM provides perfect loss accounting but may require hardware support 🛠️.

As defined in [RFC6374], MPLS LM query and response messages use the ACH (with value 0x000A for direct loss measurement or value 0x000B for inferred loss measurement) 🎯. This value identifies the message type and message payload that follow the ACH, as defined in Section 3.1 of [RFC6374] 📝. For loss measurement, the same ACH value is used for both links and end-to-end SR-MPLS Policies 🦋.

5.3. Combined Loss/Delay Measurement Message

As defined in [RFC6374], combined LM/DM query and response messages use the ACH (with value 0x000D for direct loss and delay measurement or value 0x000E for inferred loss and delay measurement) 🌈. The value identifies the message type and the message payload that follows the ACH, as defined in Section 3.3 of [RFC6374] 💫. For combined loss and delay measurement, the same ACH value is used for both links and end-to-end SR-MPLS Policies 🧜‍♀️.

5.4. Counters

The Path Segment Identifier (PSID) [RFC9545] MUST be carried in the received data packet for the traffic flow under measurement, so that received traffic gets counted on the egress node of the SR-MPLS Policy 📊. In the direct mode, the PSID in the received query message (as shown in Figure 4) can be used to associate the received traffic counter on the responder, to detect the transmit packet loss for the end-to-end SR-MPLS Policy 🕵️‍♀️.

In the inferred mode, the PSID in the received query messages (as shown in Figure 4) can be used to count the received query messages on the responder, to detect the transmit packet loss for an end-to-end SR-MPLS Policy 🔍.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Label(1)             | TC  |S|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                                                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Label(n)             | TC  |S|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  PSID                 | TC  |S|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  GAL (value 13)       | TC  |1|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version| Reserved      |       Channel Type            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 4: Example with the PSID for SR-MPLS Policy

The fields 0001, Version, Reserved, and Channel Type shown in Figure 4 are specified in [RFC5586] 🧾.

Different values of the PSID can be used per Candidate-Path to account for received traffic and to measure packet loss at the Candidate-Path level 🛤️. Similarly, different values of the PSID can be used per Segment List (SL) of the Candidate-Path for accounting received traffic, to measure packet loss at the SL level 🎯. The same value of the PSID can be used for all SLs of the SR-MPLS Policy to measure packet loss at the SR-MPLS Policy level 👑.

5.5. Block Number for Counters

okay bestie, so the packet loss measurement using the Alternate-Marking Method in [RFC9341] 🦋 may use the block number for data correlation on the traffic flow under measurement. As defined in Section 3.1 of [RFC9341], the block number splits the traffic flow into consecutive blocks, and then you count the packets sent and received in each block for loss measurement. it's giving organization 📦✨

As described in Section 4.3 of [RFC9341], a protocol-based distributed solution can be used to swap counter values between the nodes for loss measurement. This document goes deeper into that solution using the LM messages defined in [RFC6374] 💜

The querier node gives a block number to each block of data packets in the traffic flow under measurement. The querier counts how many packets it transmitted in each block. How the block number gets assigned is a local decision on the querier, and it's outside the scope of this document 🙈

As an example, the querier can use the procedure defined in [RFC9714] to alternate-mark the data packets of the traffic flow under measurement. The responder counts how many packets it received in each block, based on the marking in the received data packets. The querier and responder keep separate sets of transmit and receive counters for each marking. The marking can serve as a block number, or a separate block number can get incremented whenever the marking changes. Other methods can be defined for alternate marking of the data packets of the traffic flow under measurement, to assign a block number for the counters 🌈

The LM query and response messages defined in [RFC6374] are used to measure packet loss for the block of data packets sent with the previous marking, while the data packets carry the alternate marking. To be specific, LM query and response messages carry the transmit and receive counters (which are not incrementing right now) along with their block number, so loss can be correlated 🎀

Section 4.3 of [RFC9341] specifies that: "The assumption of this BN mechanism is that the measurement nodes are time synchronized." However, this is not necessary, because the responder's block number can be synchronized based on the received LM query messages. no clocks needed, iykyk 🧚

6. TLV Extensions ✨

6.1. Return Path TLV Extension

In the two-way measurement mode, the responder may send the response message on a specific return path, for example in an ECMP environment 🛤️ The querier can ask, in the query message, for the responder to send the response message back on a given return path (e.g., a co-routed bidirectional path). This lets the responder avoid creating and maintaining extra state (containing return paths) for the sessions. so efficient, main character energy 👑

The querier may not be directly reachable from the responder in a network. In this case, the querier MUST send its reachability path information to the responder using the Return Path TLV. no skipping this step, bestie 🙅‍♀️

[RFC6374] defines query and response messages that can include one or more optional TLVs. This document defines the Return Path TLV (5) to carry return path information in query messages. The Return Path TLV is specific to a measurement session. The format of the Return Path TLV is shown in Figure 5 below:

    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 = 5     |    Length     |      Reserved                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Return Path Sub-TLV                        |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 5: Return Path TLV

The Length is a one-byte field and is equal to the length of the Return Path Sub-TLV and the Reserved field in bytes. The Length MUST NOT be 0 or 1. ⚠️

The Return Path TLV is defined in the "Mandatory TLV Type" registry space [RFC6374]. The querier MUST only insert one Return Path TLV in the query message. The responder that supports this TLV MUST only process the first Return Path TLV and ignore the other Return Path TLVs if present. The responder that supports this TLV also MUST send the response message back on the return path specified in the Return Path TLV. The responder also MUST NOT add a Return Path TLV in the response message. rules, rules, rules 📜

The Reserved field MUST be set to 0 and MUST be ignored on the receive side. 🫶

6.1.1. Return Path Sub-TLV Extension

The Return Path TLV holds a Sub-TLV to carry the return path. The format of the MPLS Label Stack Sub-TLV is shown in Figure 6. The label entries in the Sub-TLV MUST be in network order. The MPLS Label Stack Sub-TLV in the Return Path TLV is of the following type:

  • Type (value 1): MPLS Label Stack of the Return Path
    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=1     |    Length     |      Reserved                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Label(1)             | TC  |S|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                                                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Label(n)             | TC  |1|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 6: MPLS Label Stack Sub-TLV in the Return Path TLV

The MPLS label stack is a list of 32-bit LSEs that includes a 20-bit label value, an 8-bit TTL value, a 3-bit TC value, and a 1-bit End of Stack (S) field. An MPLS Label Stack Sub-TLV may carry a stack of labels or a Binding SID label [RFC8402] of the Return SR-MPLS Policy. 🧩

The Length is a one-byte field and is equal to the length of the label stack field and the Reserved field in bytes. The Length MUST NOT be 0 or 1.

The Return Path TLV MUST carry only one Return Path Sub-TLV. The MPLS Label Stack in the Return Path Sub-TLV MUST contain at least one MPLS Label. The responder that supports this Sub-TLV MUST only process the first Return Path Sub-TLV and ignore the other Return Path Sub-TLVs if present. The responder that supports this Sub-TLV MUST send the response message back on the return path specified in the Return Path Sub-TLV. 🔁

The Reserved field MUST be set to 0 and MUST be ignored on the receive side. 💖

6.2. Block Number TLV Extension

[RFC6374] defines query and response messages that can include one or more optional TLVs. This document defines the Block Number TLV (6) to carry the (8-bit) Block Number of the traffic counters in the LM query and response messages. The format of the Block Number TLV is shown in Figure 7:

    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=6     |    Length     | Reserved    |R| Block Number  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 7: Block Number TLV

The Length is a one-byte field and is equal to 2 bytes.

The Block Number TLV is defined in the "Mandatory TLV Type" registry space [RFC6374]. The querier MUST only insert one Block Number TLV in the query message to identify the Block Number for the traffic counters in the forward direction. The responder that supports this TLV MUST only insert one Block Number TLV in the response message to identify the Block Number for the traffic counters in the reverse direction. The responder also MUST return the first Block Number TLV from the query message and ignore the other Block Number TLVs if present. The Block Number TLV is specific to a measurement session. The R flag is used to indicate the query and response message direction associated with the Block Number. The R flag MUST be clear in the query message for the Block Number associated with Counter 1 and Counter 2, and set in the response message for the Block Number associated with Counter 3 and Counter 4. 🎯

The Reserved field MUST be set to 0 and MUST be ignored on the receive side. 🌸

7. ECMP for SR-MPLS Policies 🌈

The SLs of an SR-MPLS Policy can have ECMPs between the source and transit nodes, between transit nodes, and between transit and destination nodes. Using a node-SID [RFC8402] in the SLs of an SR-MPLS Policy can result in ECMP paths. On top of that, using an Anycast-SID [RFC8402] in the SLs of an SR-MPLS Policy can result in ECMP paths via transit nodes that are part of that anycast group. The query and response messages get sent so they traverse different ECMP paths, which lets you measure the delay of each ECMP path of an SL 🦋

The forwarding plane has various hashing functions available to forward packets on specific ECMP paths. For end-to-end SR-MPLS Policy delay measurement, different entropy label values [RFC6790] can be used in query and response messages, to take advantage of the hashing function in the forwarding plane and influence the ECMP path they take 🧚

The considerations for loss measurement for different ECMP paths of an SR-MPLS Policy are outside the scope of this document. 🙈

The extended TE metrics for link delay (namely, average delay, minimum delay, maximum delay, and delay-variance) and packet loss can be computed using the performance measurement procedures described in this document, and then advertised in the routing domain as follows:

  • For OSPF, IS-IS, and the Border Gateway Protocol - Link State (BGP-LS), the protocol extensions defined in [RFC7471], [RFC8570], and [RFC8571], respectively, are used for advertising the extended TE link delay and loss metrics in the network.
  • The extended TE link delay and loss metrics are advertised for Layer-2 LAG bundle member links in OSPF [RFC9356] and IS-IS [RFC8668] using the same protocol extensions defined in [RFC7471] and [RFC8570], respectively.
  • The advertised delay-variance metric is computed as Packet Delay Variation (PDV), as described in Section 4.2 of [RFC5481]. 📊

9. Backwards Compatibility 🔙

The procedures defined in this document are backwards compatible with the procedures defined in [RFC6374] at both the querier and the responder. If the responder does not support the new Mandatory TLV Types defined in this document, it will return Error 0x17: Unsupported Mandatory TLV Object as per [RFC6374]. so nobody gets left on read 💌

10. Manageability Considerations 🛠️

The manageability considerations described in Section 7 of [RFC6374] and Section 6 of [RFC7876] are applicable to this specification. 💅

11. Security Considerations ✨

Okay, security is serious business, but it's also lowkey my fave part 🔒💅 The security stuff in [RFC6374], [RFC7471], [RFC8570], [RFC8571], [RFC7876], and [RFC9341] still applies to everything in this doc, so go read those too 🫶

This procedure is meant to be deployed inside a single operator administrative domain 🏠 That means the operator is the one setting up the querier node, the responder node, the forward path, and the return paths for the probe session 🛠️ It's also assumed that the operator has already verified the integrity of the forward and return paths for the probe packets ✅

⚠️ Bestie, the Return Path TLV extensions defined here may be used for potential address spoofing 🙈 For example, a query message could carry a return path whose destination isn't local at the querier. To stop that kind of thing, the responder may drop the query messages when it can't figure out whether the return path's destination is local at the querier. The querier may send a proper source address in the Source Address TLV, and the responder can use that to make the call, for example by checking the access control list the operator provisioned 🧱

12. IANA Considerations 📋

IANA has allocated values for the following Mandatory TLV Types [RFC6374] from the "MPLS Loss/Delay Measurement TLV Object" registry, which lives inside the "Generic Associated Channel (G-ACh) Parameters" registry group 🗂️

                    +======+==============+===========+
                    | Code | Description  | Reference |
                    +======+==============+===========+
                    | 5    | Return Path  | RFC 9779  |
                    +------+--------------+-----------+
                    | 6    | Block Number | RFC 9779  |
                    +------+--------------+-----------+

                          Table 1: MPLS Loss/Delay
                           Measurement TLV Types

The Block Number TLV is carried in the query and response messages, and the Return Path TLV is carried in the query messages 📨

IANA also created a brand new "Return Path Sub-TLV Types" registry 🆕 All code points are allocated per the registration policies in Table 2 (see [RFC8126]) 💖

            +===========+=========================+===========+
            | Value     | Description             | Reference |
            +===========+=========================+===========+
            | 1 - 175   | IETF Review             | RFC 9779  |
            +-----------+-------------------------+-----------+
            | 176 - 239 | First Come First Served | RFC 9779  |
            +-----------+-------------------------+-----------+
            | 240 - 251 | Experimental Use        | RFC 9779  |
            +-----------+-------------------------+-----------+
            | 252 - 254 | Private Use             | RFC 9779  |
            +-----------+-------------------------+-----------+

                Table 2: Return Path Sub-TLV Types Registry

This document defines the following values in the "Return Path Sub-TLV Types" registry 🦋

        +=======+=====================================+===========+
        | Value | Description                         | Reference |
        +=======+=====================================+===========+
        | 0     | Reserved                            | RFC 9779  |
        +-------+-------------------------------------+-----------+
        | 1     | MPLS Label Stack of the Return Path | RFC 9779  |
        +-------+-------------------------------------+-----------+
        | 255   | Reserved                            | RFC 9779  |
        +-------+-------------------------------------+-----------+

                     Table 3: Return Path Sub-TLV Types

13. References 📚

13.1. Normative References

13.2. Informative References

Acknowledgments 🫶

The authors wanna thank Thierry Couture and Ianik Semco 💬 for the convos about use cases for performance measurement in segment routing networks. Big thanks to Patrick Khordoc, Ruby Lin, and Haowei Shi 👏 for implementing the mechanisms defined in this document. The authors also want to thank Greg Mirsky and Xiao Min 🌸 for loads of useful comments and suggestions. Stewart Bryant, Sam Aldrin, Tarek Saad, and Rajiv Asati also get a shoutout 💖 for their review comments.

Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for the MPLS expert review 🧠; Zhaohui Zhang for the RTGDIR early review 🔍; Tony Li for shepherd's review 🐑; Ned Smith for the SECDIR review 🛡️; Roni Even for the Gen-ART review 🎨; Marcus Ihlar for the TSV-ART review 🎶; Dhruv Dhody for the OPSDIR review 🛠️; and Gunter Van de Velde, Paul Wouters, Éric Vyncke, Murray Kucherawy, John Scudder, and Roman Danyliw for the IESG review 👑

Contributors 💜

Sagar Soni Cisco Systems, Inc. Email: sagsoni@cisco.com

Zafar Ali Cisco Systems, Inc. Email: zali@cisco.com

Pier Luigi Ventre CNIT Italy Email: pierluigi.ventre@cnit.it

Authors' Addresses 🦋

Rakesh Gandhi (editor) Cisco Systems, Inc. Canada Email: rgandhi@cisco.com

Clarence Filsfils Cisco Systems, Inc. Email: cfilsfil@cisco.com

Daniel Voyer Cisco Systems, Inc. Canada Email: davoyer@cisco.com

Stefano Salsano Universita di Roma "Tor Vergata" Italy Email: stefano.salsano@uniroma2.it

Mach(Guoyi) Chen Huawei Email: mach.chen@huawei.com

📦 where this page comes from