Cisco Systems, Inc.

Canada rgandhi@cisco.com

Cisco Systems, Inc.

cfilsfil@cisco.com

Cisco Systems, Inc.

Canada davoyer@cisco.com

Universita di Roma "Tor Vergata"

Italy stefano.salsano@uniroma2.it

Huawei

mach.chen@huawei.com

RTG mpls Delay Measurement Loss Measurement Link Measurement SR-MPLS Policy Measurement This document specifies the application of the MPLS loss and delay measurement techniques (originally defined in RFCs 6374, 7876, and 9341) within Segment Routing (SR) networks that utilize the MPLS data plane, also referred to as Segment Routing over MPLS (SR-MPLS). SR enables the forwarding of packets through an ordered list of instructions, known as segments, which are imposed at the ingress node. This document defines the procedures and extensions necessary to perform accurate measurement of packet loss and delay in SR-MPLS environments, ensuring that network operators can effectively measure and maintain the quality of service across their SR-based MPLS networks. This includes coverage of links and end-to-end SR-MPLS paths, as well as SR Policies.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice 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 () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
• .  Conventions Used in This Document
  • .  Requirements Language
  • .  Abbreviations
  • .  Reference Topology
• .  Overview
• .  Query and Response Messages
  • .  Query Message for Links and SR-MPLS Policies
    • .  Query Message for Links
    • .  Query Message for SR-MPLS Policies
  • .  Response Message for Links and SR-MPLS Policies
    • .  One-Way Measurement Mode
    • .  Two-Way Measurement Mode
    • .  Loopback Measurement Mode
• .  Delay and Loss Measurement
  • .  Delay Measurement Message
  • .  Loss Measurement Message
  • .  Combined Loss/Delay Measurement Message
  • .  Counters
  • .  Block Number for Counters
• .  TLV Extensions
  • .  Return Path TLV Extension
    • .  Return Path Sub-TLV Extension
  • .  Block Number TLV Extension
• .  ECMP for SR-MPLS Policies
• .  Extended TE Link Metrics Advertisement
• .  Backwards Compatibility
• . Manageability Considerations
• . Security Considerations
• . IANA Considerations
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Contributors
• Authors' Addresses

Introduction Segment Routing (SR), as specified in , leverages the source routing paradigm and applies to both the Multiprotocol Label Switching (MPLS) and Internet Protocol version 6 (IPv6) data planes. These are referred to as Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6), respectively. 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 , are used to steer traffic through specific, user-defined paths using a list of segments. A comprehensive SR Performance Measurement toolset is one of the essential requirements for measuring network performance to provide Service Level Agreements (SLAs). specifies protocol mechanisms to enable efficient and accurate measurement of packet loss, one-way and two-way delay, as well as related metrics such as delay-variation in MPLS networks. specifies mechanisms for sending and processing out-of-band responses over a UDP return path when receiving query messages defined in . These mechanisms can be applied to SR-MPLS networks. defines the Alternate-Marking Method using Block Numbers as a data correlation mechanism for packet loss measurement. This document utilizes the mechanisms from , , and for delay and loss measurements in SR-MPLS networks. This includes coverage of links and end-to-end SR-MPLS paths, as well as SR Policies. This document extends by defining Return Path and Block Number TLVs (see ) for delay and loss measurement in SR-MPLS networks. These TLVs can also be used in MPLS Label Switched Paths (LSPs) . However, the procedure for delay and loss measurement of MPLS LSPs is outside the scope of this document.

Conventions Used in This Document

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 when, and only when, they appear in all capitals, as shown here.

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

Reference Topology In the reference topology shown in , the querier node Q1 initiates a query message, and the responder node R1 transmits a response message for the query message received. The response message may be sent back to the querier node Q1 on the same path (the same set of links and nodes) or on a different path in the reverse direction from the path taken towards the responder R1. T1 is a transmit timestamp, and T4 is a receive timestamp; both are added by node Q1. T2 is a receive timestamp, and T3 is a transmit timestamp; both are added by node R1. SR is enabled with the MPLS data plane on nodes Q1 and R1. The nodes Q1 and R1 are connected via a channel (). The channel may be a directly connected link enabled with MPLS () or an SR-MPLS path . The link may be a physical interface, a virtual link, a Link Aggregation Group (LAG) , or a LAG member link. The SR-MPLS path may be an SR-MPLS Policy on node Q1 (called the "head-end") with the destination to node R1 (called the "tail-end").

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

Overview In this document, the procedures defined in , , and are utilized for delay and loss measurement in SR-MPLS networks. Specifically, the one-way, two-way, and round-trip delay measurements described in are further elaborated for application within SR-MPLS networks. Similarly, the packet loss measurement procedures outlined in are extended for use in SR-MPLS networks. Packet loss measurement using the Alternate-Marking Method defined in may employ the Block Number for data correlation. This is achieved by utilizing the Block Number TLV extension defined in this document. In SR-MPLS networks, the query messages defined in MUST be transmitted along the same path as the data traffic for links and end-to-end SR-MPLS paths. This is to collect both transmit and receive timestamps for delay measurement and to collect both transmit and receive traffic counters for loss measurement. If it is desired in SR-MPLS networks that the same path (i.e., the same set of links and nodes) between the querier and responder be used in both directions of the measurement, then this can be achieved by using the Return Path TLV extension defined in this document. The performance measurement procedures for links can be used to compute extended Traffic Engineering (TE) metrics for delay and loss, as described herein. These metrics are advertised in the network using the routing protocol extensions defined in , , and .

Query and Response Messages

Query Message for Links and SR-MPLS Policies

Query Message for Links The query message, as defined in , is sent over the links for both delay and loss measurement. In each Label Stack Entry (LSE) in the MPLS label stack, the TTL value MUST be set to 255 .

Query Message for SR-MPLS Policies An SR-MPLS Policy Candidate-Path may contain a number of Segment Lists (SLs) (i.e., a stack of MPLS labels) . For delay and/or loss measurement for an end-to-end SR-MPLS Policy, the query messages MUST be transmitted for every SL of the SR-MPLS Policy Candidate-Path. This is done by creating a separate session for each SL. Each query message of a session contains an SR-MPLS label stack of the Candidate-Path, with the G-ACh Label (GAL) at the bottom of the stack (with S=1) as shown in . In each LSE in the MPLS label stack, the TTL value MUST be set to 255 .

Example Query Message Header 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL (value 13) | TC |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields 0001, Version, Reserved, and Channel Type shown in are specified in . 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 ensure that the query message is processed by the intended responder, the Destination Address TLV (Type 129) 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) if it is the intended destination for the query. Otherwise, it MUST return Error 0x15: Invalid Destination Node Identifier .

Response Message for Links and SR-MPLS Policies

One-Way Measurement Mode In one-way measurement mode, as defined in , the querier can set the UDP Return Object (URO) TLV in the query message. This enables the querier to 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 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. In addition, the Control Code in the query message MUST be set to Out-of-band Response Requested .

Two-Way Measurement Mode In the two-way measurement mode defined in , the response messages SHOULD be sent back one of two ways: either they are sent back in-band on the same link, or they are sent back on the same end-to-end SR-MPLS path (i.e., the same set of links and nodes) in the reverse direction to the querier. This is done in order to perform accurate two-way delay measurement. For links, the response message as defined in is sent back on the same incoming link where the query message is received. In this case, the Control Code in the query message MUST be set to In-band Response Requested . For end-to-end SR-MPLS paths, the responder transmits the response message (see the example as shown in ) on a specific return SR-MPLS path. In the query message, the querier can request that the responder 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.

Loopback Measurement Mode The loopback measurement mode defined in is used to measure round-trip delay for a bidirectional circular path 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 . The loopback mode is done by generating "queries" with the Response flag set to 1 and adding the Loopback Request object (Type 3) . In query messages, the label stack, as shown in , 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).

Example Query Message Header for an End-to-End SR-MPLS Policy in the Loopback Measurement Mode 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Delay and Loss Measurement

Delay Measurement Message As defined in , MPLS Delay Measurement (DM) query and response messages use the Associated Channel Header (ACH) (with value 0x000C for delay measurement). The value identifies the message type and message payload that follow the ACH, as defined in . For delay measurement, the same ACH value is used for both links and end-to-end SR-MPLS Policies.

Loss Measurement Message The Loss Measurement (LM) protocol can perform two distinct kinds of loss measurement as described in .

• In the inferred mode, LM will measure 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 will directly measure data plane packet loss. Direct mode LM provides perfect loss accounting but may require hardware support.

As defined in , 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 . For loss measurement, the same ACH value is used for both links and end-to-end SR-MPLS Policies.

Combined Loss/Delay Measurement Message As defined in , 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 . For combined loss and delay measurement, the same ACH value is used for both links and end-to-end SR-MPLS Policies.

Counters The Path Segment Identifier (PSID) MUST be carried in the received data packet for the traffic flow under measurement, in order to account for received traffic on the egress node of the SR-MPLS Policy. In the direct mode, the PSID in the received query message (as shown in ) 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 ) 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.

Example with the PSID for 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields 0001, Version, Reserved, and Channel Type shown in are specified in . 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.

Block Number for Counters The packet loss measurement using the Alternate-Marking Method defined in may use the block number for data correlation for the traffic flow under measurement. As defined in , the block number is used to divide the traffic flow into consecutive blocks and count the number of packets transmitted and received in each block for loss measurement. As described in , a protocol-based distributed solution can be used to exchange values of counters on the nodes for loss measurement. That solution is further described in this document using the LM messages defined in . The querier node assigns a block number to the block of data packets of the traffic flow under measurement. The querier counts the number of packets transmitted in each block. The mechanism for the assignment of the block number is a local decision on the querier and is outside the scope of this document. As an example, the querier can use the procedure defined in for alternate marking of the data packets of the traffic flow under measurement. The responder counts the number of received packets in each block based on the marking in the received data packets. The querier and responder maintain separate sets of transmit and receive counters for each marking. The marking can be used as a block number, or a separate block number can be incremented when 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 are used to measure packet loss for the block of data packets transmitted with the previous marking, whereas data packets carry alternate marking. Specifically, LM query and response messages carry the transmit and receive counters (which are currently not incrementing) along with their block number to correlate for loss measurement. specifies that: "The assumption of this BN mechanism is that the measurement nodes are time synchronized." However, this is not necessary, as the block number on the responder can be synchronized based on the received LM query messages.

TLV Extensions

Return Path TLV Extension In the two-way measurement mode, the responder may transmit the response message on a specific return path, for example, in an ECMP environment. The querier can request in the query message for the responder to send a response message back on a given return path (e.g., a co-routed bidirectional path). This allows the responder to avoid creating and maintaining additional states (containing return paths) for the sessions. 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. 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 below:

Return Path TLV 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 | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 . 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. The Reserved field MUST be set to 0 and MUST be ignored on the receive side.

Return Path Sub-TLV Extension The Return Path TLV contains a Sub-TLV to carry the return path. The format of the MPLS Label Stack Sub-TLV is shown in . 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

MPLS Label Stack Sub-TLV in the Return Path TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The MPLS label stack contains 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 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.

Block Number TLV Extension defines query and response messages that can include one or more optional TLVs. This document defines the Block Number TLV (6) to carry (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 :

Block Number TLV 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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. Usage of a node-SID by the SLs of an SR-MPLS Policy can result in ECMP paths. In addition, usage of an Anycast-SID by 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 are sent to traverse different ECMP paths to 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 can be used in query and response messages to take advantage of the hashing function in the forwarding plane to influence the ECMP path taken by them. The considerations for loss measurement for different ECMP paths of an SR-MPLS Policy are outside the scope of this document.

Extended TE Link Metrics Advertisement 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 can be 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 , , and , 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 and IS-IS using the same protocol extensions defined in and , respectively.
• The advertised delay-variance metric is computed as Packet Delay Variation (PDV), as described in .

Backwards Compatibility The procedures defined in this document are backwards compatible with the procedures defined in 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 .

Manageability Considerations The manageability considerations described in and are applicable to this specification.

Security Considerations The security considerations specified in , , , , , and also apply to the procedures described in this document. The procedure defined in this document is intended for deployment in a single operator administrative domain. As such, the querier node, the responder node, the forward path, and the return paths are provisioned by the operator for the probe session. It is assumed that the operator has verified the integrity of the forward and return paths of the probe packets. The Return Path TLV extensions defined in this document may be used for potential address spoofing. For example, a query message may carry a return path that has a destination that is not local at the querier. To prevent such possible attacks, the responder may drop the query messages when it cannot determine whether the return path has the destination local at the querier. The querier may send a proper source address in the Source Address TLV. The responder can use this to make that determination, for example, by checking the access control list provisioned by the operator.

IANA Considerations IANA has allocated values for the following Mandatory TLV Types from the "MPLS Loss/Delay Measurement TLV Object" registry contained within the "Generic Associated Channel (G-ACh) Parameters" registry group: MPLS Loss/Delay Measurement TLV Types

Code	Description	Reference
5	Return Path	RFC 9779
6	Block Number	RFC 9779

The Block Number TLV is carried in the query and response messages, and the Return Path TLV is carried in the query messages. IANA has created the "Return Path Sub-TLV Types" registry. All code points are allocated per the registration policies shown in (see ). Return Path Sub-TLV Types Registry

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

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

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

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. [STANDARDS-TRACK] RFC 6374 defines a protocol for Packet Loss and Delay Measurement for MPLS networks (MPLS-PLDM). This document specifies the procedures to be used when sending and processing out-of-band MPLS performance management Responses over an UDP/IP return path. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application. This document obsoletes RFC 8321. Informative References This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK] This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK] The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK] Packet delay variation metrics appear in many different standards documents. The metric definition in RFC 3393 has considerable flexibility, and it allows multiple formulations of delay variation through the specification of different packet selection functions. Although flexibility provides wide coverage and room for new ideas, it can make comparisons of independent implementations more difficult. Two different formulations of delay variation have come into wide use in the context of active measurements. This memo examines a range of circumstances for active measurements of delay variation and their uses, and recommends which of the two forms is best matched to particular conditions and tasks. This memo provides information for the Internet community. This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism. Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK] In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection. This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. This document obsoletes RFC 7810. This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in the IS-IS and OSPF protocols. There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer 3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links that comprise the Layer 2 interface bundle, link attribute information about the bundle members is required. This document introduces the ability for IS-IS to advertise the link attributes of Layer 2 (L2) Bundle Members. Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. There are deployments where the Layer 3 (L3) interface on which OSPF operates is a Layer 2 (L2) interface bundle. Existing OSPF advertisements only support advertising link attributes of the L3 interface. If entities external to OSPF wish to control traffic flows on the individual physical links that comprise the L2 interface bundle, link attribute information for the bundle members is required. This document defines the protocol extensions for OSPF to advertise the link attributes of L2 bundle members. The document also specifies the advertisement of these OSPF extensions via the Border Gateway Protocol - Link State (BGP-LS) and thereby updates RFC 9085. A Segment Routing (SR) path is identified by an SR segment list. A subset of segments from the segment list cannot be leveraged to distinguish one SR path from another as they may be partially congruent. SR path identification is a prerequisite for various use cases such as performance measurement and end-to-end 1+1 path protection. In an SR over MPLS (SR-MPLS) data plane, an egress node cannot determine on which SR path a packet traversed the network from the label stack because the segment identifiers are removed from the label stack as the packet transits the network. This document defines a Path Segment Identifier (PSID) to identify an SR path on the egress node of the path. This document defines the encapsulation for MPLS performance measurement with the Alternate-Marking Method, which performs flow-based packet loss, delay, and jitter measurements on MPLS traffic. IEEE

Acknowledgments The authors would like to thank and for the discussions on the use cases for performance measurement in segment routing networks. The authors would like to thank , , and for implementing the mechanisms defined in this document. The authors would like to thank and for providing many useful comments and suggestions. The authors would also like to thank , , , and for their review comments. Thanks to , , and for the MPLS expert review; for the RTGDIR early review; for shepherd's review; for the SECDIR review; for the Gen-ART review; for the TSV-ART review; for the OPSDIR review; and , , , , , and for the IESG review.

Contributors Cisco Systems, Inc.

sagsoni@cisco.com

Cisco Systems, Inc.

zali@cisco.com

CNIT

Italy pierluigi.ventre@cnit.it

Authors' Addresses Cisco Systems, Inc.

Canada rgandhi@cisco.com

Cisco Systems, Inc.

cfilsfil@cisco.com

Cisco Systems, Inc.

Canada davoyer@cisco.com

Universita di Roma "Tor Vergata"

Italy stefano.salsano@uniroma2.it

Huawei

mach.chen@huawei.com