rfc9779.original   rfc9779.txt 
MPLS Working Group R. Gandhi, Ed. Internet Engineering Task Force (IETF) R. Gandhi, Ed.
Internet-Draft C. Filsfils Request for Comments: 9779 C. Filsfils
Intended status: Standards Track Cisco Systems, Inc. Category: Standards Track Cisco Systems, Inc.
Expires: 20 April 2025 D. Voyer ISSN: 2070-1721 D. Voyer
Bell Canada Bell Canada
S. Salsano S. Salsano
Universita di Roma "Tor Vergata" Universita di Roma "Tor Vergata"
M. Chen M. Chen
Huawei Huawei
17 October 2024 April 2025
Performance Measurement for Segment Routing Networks with MPLS Data Performance Measurement for Segment Routing Networks with the MPLS Data
Plane Plane
draft-ietf-mpls-rfc6374-sr-17
Abstract Abstract
This document specifies the application of the MPLS loss and delay This document specifies the application of the MPLS loss and delay
measurement techniques, originally defined in RFC 6374, RFC 7876, and measurement techniques (originally defined in RFCs 6374, 7876, and
RFC 9341 within Segment Routing (SR) networks that utilize the MPLS 9341) within Segment Routing (SR) networks that utilize the MPLS data
data plane (SR-MPLS). Segment Routing enables the forwarding of plane, also referred to as Segment Routing over MPLS (SR-MPLS). SR
packets through an ordered list of instructions, known as segments, enables the forwarding of packets through an ordered list of
which are imposed at the ingress node. This document defines the instructions, known as segments, which are imposed at the ingress
procedures and extensions necessary to perform accurate measurement node. This document defines the procedures and extensions necessary
of packet loss and delay in SR-MPLS environments, ensuring that to perform accurate measurement of packet loss and delay in SR-MPLS
network operators can effectively measure and maintain the quality of environments, ensuring that network operators can effectively measure
service across their SR-based MPLS networks. This includes coverage and maintain the quality of service across their SR-based MPLS
of links and end-to-end SR-MPLS paths, as well as SR Policies. networks. This includes coverage of links and end-to-end SR-MPLS
paths, as well as SR Policies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 20 April 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9779.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Abbreviations
2.3. Reference Topology . . . . . . . . . . . . . . . . . . . 5 2.3. Reference Topology
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview
4. Query and Response Messages . . . . . . . . . . . . . . . . . 6 4. Query and Response Messages
4.1. Query Message for Links and SR-MPLS Policies . . . . . . 6 4.1. Query Message for Links and SR-MPLS Policies
4.1.1. Query Message for Links . . . . . . . . . . . . . . . 6 4.1.1. Query Message for Links
4.1.2. Query Message for SR-MPLS Policies . . . . . . . . . 6 4.1.2. Query Message for SR-MPLS Policies
4.2. Response Message for Links and SR-MPLS Policies . . . . . 7 4.2. Response Message for Links and SR-MPLS Policies
4.2.1. One-way Measurement Mode . . . . . . . . . . . . . . 7 4.2.1. One-Way Measurement Mode
4.2.2. Two-way Measurement Mode . . . . . . . . . . . . . . 8 4.2.2. Two-Way Measurement Mode
4.2.3. Loopback Measurement Mode . . . . . . . . . . . . . . 8 4.2.3. Loopback Measurement Mode
5. Delay and Loss Measurement . . . . . . . . . . . . . . . . . 9 5. Delay and Loss Measurement
5.1. Delay Measurement Message . . . . . . . . . . . . . . . . 9 5.1. Delay Measurement Message
5.2. Loss Measurement Message . . . . . . . . . . . . . . . . 9 5.2. Loss Measurement Message
5.3. Combined Loss/Delay Measurement Message . . . . . . . . . 10 5.3. Combined Loss/Delay Measurement Message
5.4. Counters . . . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Counters
5.5. Block Number for Counters . . . . . . . . . . . . . . . . 11 5.5. Block Number for Counters
6. TLV Extensions . . . . . . . . . . . . . . . . . . . . . . . 12 6. TLV Extensions
6.1. Return Path TLV Extension . . . . . . . . . . . . . . . . 12 6.1. Return Path TLV Extension
6.1.1. Return Path Sub-TLV Extension . . . . . . . . . . . . 13 6.1.1. Return Path Sub-TLV Extension
6.2. Block Number TLV Extension . . . . . . . . . . . . . . . 14 6.2. Block Number TLV Extension
7. ECMP for SR-MPLS Policies . . . . . . . . . . . . . . . . . . 15 7. ECMP for SR-MPLS Policies
8. Extended TE Link Metrics Advertisements . . . . . . . . . . . 16 8. Extended TE Link Metrics Advertisement
9. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 16 9. Backwards Compatibility
10. Manageability Considerations . . . . . . . . . . . . . . . . 16 10. Manageability Considerations
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. Security Considerations
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 12. IANA Considerations
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 13. References
13.1. Normative References . . . . . . . . . . . . . . . . . . 18 13.1. Normative References
13.2. Informative References . . . . . . . . . . . . . . . . . 19 13.2. Informative References
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 Acknowledgments
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses
1. Introduction 1. Introduction
Segment Routing (SR), as specified in [RFC8402], leverages the source Segment Routing (SR), as specified in [RFC8402], leverages the source
routing paradigm and applies to both the Multiprotocol Label routing paradigm and applies to both the Multiprotocol Label
Switching (SR-MPLS) and IPv6 (SRv6) data planes. SR takes advantage 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, of Equal-Cost Multipaths (ECMPs) between source and transit nodes,
between transit nodes, and between transit and destination nodes. SR between transit nodes, and between transit and destination nodes. SR
Policies, defined in [RFC9256], are used to steer traffic through Policies, defined in [RFC9256], are used to steer traffic through
specific, user-defined paths using a list of segments. specific, user-defined paths using a list of segments.
A comprehensive SR Performance Measurement toolset is one of the A comprehensive SR Performance Measurement toolset is one of the
essential requirements for measuring network performance to provide essential requirements for measuring network performance to provide
Service Level Agreements (SLAs). Service Level Agreements (SLAs).
[RFC6374] specifies protocol mechanisms to enable efficient and [RFC6374] specifies protocol mechanisms to enable efficient and
accurate measurement of packet loss, one-way and two-way delay, as accurate measurement of packet loss, one-way and two-way delay, as
well as related metrics such as delay-variation in MPLS networks. well as related metrics such as delay-variation in MPLS networks.
[RFC7876] specifies mechanisms for sending and processing out-of-band [RFC7876] specifies mechanisms for sending and processing out-of-band
responses over a UDP return path when receiving query messages responses over a UDP return path when receiving query messages
defined in [RFC6374]. These mechanisms can be applied to SR-MPLS defined in [RFC6374]. These mechanisms can be applied to SR-MPLS
networks. networks.
[RFC9341] defines the Alternate-Marking Method using block number as [RFC9341] defines the Alternate-Marking Method using Block Numbers as
a data correlation mechanism for packet loss measurement. a data correlation mechanism for packet loss measurement.
This document utilizes the mechanisms from [RFC6374], [RFC7876], and This document utilizes the mechanisms from [RFC6374], [RFC7876], and
[RFC9341] for delay and loss measurements in SR-MPLS networks. This [RFC9341] for delay and loss measurements in SR-MPLS networks. This
includes coverage of links and end-to-end SR-MPLS paths, as well as includes coverage of links and end-to-end SR-MPLS paths, as well as
SR Policies. SR Policies.
This document defines Return Path and Block Number TLV extensions for This document extends [RFC6374] by defining Return Path and Block
[RFC6374], in Section 6, for delay and loss measurement in SR-MPLS Number TLVs (see Section 6) for delay and loss measurement in SR-MPLS
networks. These TLV extensions also apply to MPLS Label Switched networks. These TLVs can also be used in MPLS Label Switched Paths
Paths (LSPs) [RFC3031]. However, the procedure for delay and loss (LSPs) [RFC3031]. However, the procedure for delay and loss
measurement of MPLS LSPs is outside the scope of this document. measurement of MPLS LSPs is outside the scope of this document.
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Abbreviations 2.2. Abbreviations
ACH: Associated Channel Header. ACH: Associated Channel Header
DM: Delay Measurement. DM: Delay Measurement
ECMP: Equal Cost Multi-Path. ECMP: Equal-Cost Multipath
G-ACh: Generic Associated Channel (G-ACh). G-ACh: Generic Associated Channel
GAL: Generic Associated Channel (G-ACh) Label. GAL: Generic Associated Channel Label
LM: Loss Measurement. LM: Loss Measurement
LSE: Label Stack Entry. LSE: Label Stack Entry
MPLS: Multiprotocol Label Switching. MPLS: Multiprotocol Label Switching
PSID: Path Segment Identifier. PSID: Path Segment Identifier
SID: Segment Identifier. SID: Segment Identifier
SL: Segment List. SL: Segment List
SR: Segment Routing. SR: Segment Routing
SR-MPLS: Segment Routing with MPLS data plane. SR-MPLS: Segment Routing over MPLS
TC: Traffic Class. TC: Traffic Class
TE: Traffic Engineering. TE: Traffic Engineering
TTL: Time-To-Live. TTL: Time to Live
URO: UDP Return Object. URO: UDP Return Object
2.3. Reference Topology 2.3. Reference Topology
In the Reference Topology shown in Figure 1, the querier node Q1 In the reference topology shown in Figure 1, the querier node Q1
initiates a query message, and the responder node R1 transmits a initiates a query message, and the responder node R1 transmits a
response message for the query message received. The response response message for the query message received. The response
message may be sent back to the querier node Q1 on the same path message may be sent back to the querier node Q1 on the same path (the
(same set of links and nodes) or a different path in the reverse same set of links and nodes) or on a different path in the reverse
direction from the path taken towards the responder R1. direction from the path taken towards the responder R1.
T1 is a transmit timestamp, and T4 is a receive timestamp, both added T1 is a transmit timestamp, and T4 is a receive timestamp; both are
by node Q1. T2 is a receive timestamp, and T3 is a transmit added by node Q1. T2 is a receive timestamp, and T3 is a transmit
timestamp, both added by node R1. timestamp; both are added by node R1.
SR is enabled with the MPLS data plane on nodes Q1 and R1. The nodes SR is enabled with the MPLS data plane on nodes Q1 and R1. The nodes
Q1 and R1 are connected via a channel (Section 2.9.1 of [RFC6374]). Q1 and R1 are connected via a channel (Section 2.9.1 of [RFC6374]).
The channel may be a directly connected link enabled with MPLS The channel may be a directly connected link enabled with MPLS
(Section 2.9.1 of [RFC6374]) or an SR-MPLS path [RFC8402]. The link (Section 2.9.1 of [RFC6374]) or an SR-MPLS path [RFC8402]. The link
may be a physical interface, a virtual link, or a Link Aggregation may be a physical interface, a virtual link, a Link Aggregation Group
Group (LAG) [IEEE802.1AX], or a LAG member link. The SR-MPLS path (LAG) [IEEE802.1AX], or a LAG member link. The SR-MPLS path may be
may be an SR-MPLS Policy [RFC9256] on node Q1 (called head-end) with an SR-MPLS Policy [RFC9256] on node Q1 (called the "head-end") with
the destination to node R1 (called tail-end). the destination to node R1 (called the "tail-end").
T1 T2 T1 T2
/ \ / \
+-------+ Query +-------+ +-------+ Query +-------+
| | - - - - - - - - - ->| | | | - - - - - - - - - ->| |
| Q1 |=====================| R1 | | Q1 |=====================| R1 |
| |<- - - - - - - - - - | | | |<- - - - - - - - - - | |
+-------+ Response +-------+ +-------+ Response +-------+
\ / \ /
T4 T3 T4 T3
Querier Responder Querier Responder
Figure 1: Reference Topology Figure 1: Reference Topology
3. Overview 3. Overview
In this document, the procedures defined in [RFC6374], [RFC7876], and In this document, the procedures defined in [RFC6374], [RFC7876], and
[RFC9341] are utilized for delay and loss measurement in SR-MPLS [RFC9341] are utilized for delay and loss measurement in SR-MPLS
networks. Specifically, the one-way, two-way, and round-trip delay networks. Specifically, the one-way, two-way, and round-trip delay
measurements described in Section 2.4 of [RFC6374] are further measurements described in Section 2.4 of [RFC6374] are further
elaborated for application within SR-MPLS networks. Similarly, the elaborated for application within SR-MPLS networks. Similarly, the
packet loss measurement procedures outlined in Section 2.2 of packet loss measurement procedures outlined in Section 2.2 of
[RFC6374] are extended for use in SR-MPLS networks. [RFC6374] are extended for use in SR-MPLS networks.
Packet loss measurement using the Alternate-Marking Method defined in Packet loss measurement using the Alternate-Marking Method defined in
[RFC9341] may employ the Block Number for data correlation. This is [RFC9341] may employ the Block Number for data correlation. This is
achieved by utilizing the Block Number TLV extension defined in this achieved by utilizing the Block Number TLV extension defined in this
document. document.
In SR-MPLS networks, the query messages defined in [RFC6374] MUST be In SR-MPLS networks, the query messages defined in [RFC6374] MUST be
transmitted along the same path as the data traffic for links and transmitted along the same path as the data traffic for links and
end-to-end SR-MPLS paths, to collect both transmit and receive end-to-end SR-MPLS paths. This is to collect both transmit and
timestamps for delay measurement and to collect both transmit and receive timestamps for delay measurement and to collect both transmit
receive traffic counters for loss measurement. and receive traffic counters for loss measurement.
If it is desired in SR-MPLS networks that the same path (i.e., the 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 same set of links and nodes) between the querier and responder be
used in both directions of the measurement, this can be achieved by used in both directions of the measurement, then this can be achieved
using the Return Path TLV extension defined in this document. by using the Return Path TLV extension defined in this document.
The performance measurement procedures for links can be used to The performance measurement procedures for links can be used to
compute extended Traffic Engineering (TE) metrics for delay and loss, compute extended Traffic Engineering (TE) metrics for delay and loss,
as described herein. These metrics are advertised in the network as described herein. These metrics are advertised in the network
using the routing protocol extensions defined in [RFC7471], using the routing protocol extensions defined in [RFC7471],
[RFC8570], and [RFC8571]. [RFC8570], and [RFC8571].
4. Query and Response Messages 4. Query and Response Messages
4.1. Query Message for Links and SR-MPLS Policies 4.1. Query Message for Links and SR-MPLS Policies
skipping to change at page 6, line 44 skipping to change at line 268
for both delay and loss measurement. In each Label Stack Entry (LSE) 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 [RFC3032] in the MPLS label stack, the TTL value MUST be set to 255
[RFC5082]. [RFC5082].
4.1.2. Query Message for SR-MPLS Policies 4.1.2. Query Message for SR-MPLS Policies
An SR-MPLS Policy Candidate-Path may contain a number of Segment An SR-MPLS Policy Candidate-Path may contain a number of Segment
Lists (SLs) (i.e., a stack of MPLS labels) [RFC9256]. For delay and/ Lists (SLs) (i.e., a stack of MPLS labels) [RFC9256]. For delay and/
or loss measurement for an end-to-end SR-MPLS Policy, the query 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 messages MUST be transmitted for every SL of the SR-MPLS Policy
Candidate-Path, by creating a separate session for each SL. Each Candidate-Path. This is done by creating a separate session for each
query message of a session contains an SR-MPLS label stack of the SL. Each query message of a session contains an SR-MPLS label stack
Candidate-Path, with the G-ACh Label (GAL) at the bottom of the stack of the Candidate-Path, with the G-ACh Label (GAL) at the bottom of
(with S=1) as shown in Figure 2. In each LSE in the MPLS label the stack (with S=1) as shown in Figure 2. In each LSE in the MPLS
stack, the TTL value MUST be set to 255 [RFC5082]. label stack, the TTL value MUST be set to 255 [RFC5082].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) | TC |S| TTL | | Label(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(n) | TC |S| TTL | | Label(n) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL (value 13) | TC |1| TTL | | GAL (value 13) | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type | |0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example Query Message Header for an End-to-end SR-MPLS Figure 2: Example Query Message Header for an End-to-End SR-MPLS
Policy Policy
The fields "0001", Version, Reserved, and Channel Type shown in The fields 0001, Version, Reserved, and Channel Type shown in
Figure 2 are specified in [RFC5586]. Figure 2 are specified in [RFC5586].
The SR-MPLS label stack can be empty in the case of a one-hop SR-MPLS The SR-MPLS label stack can be empty in the case of a one-hop SR-MPLS
Policy with an Implicit NULL label. Policy with an Implicit NULL label.
For an SR-MPLS Policy, to ensure that the query message is processed For an SR-MPLS Policy, to ensure that the query message is processed
by the intended responder, the Destination Address TLV (Type 129) by the intended responder, the Destination Address TLV (Type 129)
[RFC6374] containing an address of the responder can be sent in the [RFC6374] containing an address of the responder can be sent in the
query messages. The responder that supports this TLV MUST return query messages. The responder that supports this TLV MUST return
Success in "Control Code" [RFC6374] if it is the intended destination Control Code 0x1 (Success) [RFC6374] if it is the intended
for the query. Otherwise, it MUST return 0x15: Error - Invalid destination for the query. Otherwise, it MUST return Error 0x15:
Destination Node Identifier [RFC6374]. Invalid Destination Node Identifier [RFC6374].
4.2. Response Message for Links and SR-MPLS Policies 4.2. Response Message for Links and SR-MPLS Policies
4.2.1. One-way Measurement Mode 4.2.1. One-Way Measurement Mode
In one-way measurement mode defined in Section 2.4 of [RFC6374], the In the one-way measurement mode defined in Section 2.4 of [RFC6374],
querier can receive "out-of-band" response messages with an IP/UDP the querier can receive response messages with an IP/UDP header "out-
header by properly setting the UDP Return Object (URO) TLV in the of-band" by properly setting the UDP Return Object (URO) TLV in the
query message. The URO TLV (Type=131) is defined in [RFC7876] and query message. The URO TLV (Type 131) is defined in [RFC7876] and
includes the UDP-Destination-Port and IP Address. When the querier 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 sets an IP address and a UDP port in the URO TLV, the response
message MUST be sent to that IP address as the destination address message MUST be sent to that IP address, with that IP address as the
and UDP port as the destination port. In addition, the "Control destination address and the UDP port as the destination port. In
Code" in the query message MUST be set to "out-of-band response addition, the Control Code in the query message MUST be set to Out-
requested" [RFC6374]. of-band Response Requested [RFC6374].
4.2.2. Two-way Measurement Mode 4.2.2. Two-Way Measurement Mode
In two-way measurement mode defined in Section 2.4 of [RFC6374], the In the two-way measurement mode defined in Section 2.4 of [RFC6374],
response messages SHOULD be sent back in-band on the same link or the the response messages SHOULD be sent back one of two ways: either
same end-to-end SR-MPLS path (same set of links and nodes) in the they are sent back in-band on the same link, or they are sent back on
reverse direction to the querier, in order to perform accurate two- the same end-to-end SR-MPLS path (i.e., the same set of links and
way delay measurement. 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 [RFC6374] is sent back For links, the response message as defined in [RFC6374] is sent back
on the same incoming link where the query message is received. In 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 this case, the Control Code in the query message MUST be set to In-
"in-band response requested" [RFC6374]. band Response Requested [RFC6374].
For end-to-end SR-MPLS paths, the responder transmits the response For end-to-end SR-MPLS paths, the responder transmits the response
message (example as shown in Figure 2) on a specific return SR-MPLS message (see the example as shown in Figure 2) on a specific return
path. The querier can request in the query message for the responder SR-MPLS path. In the query message, the querier can request that the
to send the response message back on a given return path using the responder send the response message back on a given return path using
MPLS Label Stack sub-TLV in the Return Path TLV defined in this the MPLS Label Stack Sub-TLV in the Return Path TLV defined in this
document. document.
4.2.3. Loopback Measurement Mode 4.2.3. Loopback Measurement Mode
The loopback measurement mode defined in Section 2.8 of [RFC6374] is The loopback measurement mode defined in Section 2.8 of [RFC6374] is
used to measure round-trip delay for a bidirectional circular path used to measure round-trip delay for a bidirectional circular path
[RFC6374] in SR-MPLS networks. In this mode for SR-MPLS, the [RFC6374] in SR-MPLS networks. In this mode for SR-MPLS, the
received query messages are not punted out of the fast path in received query messages are not punted out of the fast path in
forwarding (i.e., to the slow path or control plane) at the forwarding (i.e., to the slow path or control plane) at the
responder. In other words, the responder does not process the responder. In other words, the responder does not process the
payload or generate response messages. The loopback function simply payload or generate response messages. The loopback function simply
returns the received query message to the querier without responder returns the received query message to the querier without responder
modifications [RFC6374]. modifications [RFC6374].
The loopback mode is done by generating "queries" with the Response The loopback mode is done by generating "queries" with the Response
flag set to 1 and adding the Loopback Request object (Type 3) flag set to 1 and adding the Loopback Request object (Type 3)
[RFC6374]. The label stack, as shown in Figure 3, in query messages, [RFC6374]. In query messages, the label stack, as shown in Figure 3,
carries both the forward and reverse path labels in the MPLS header. 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). The GAL is still carried at the bottom of the label stack (with S=1).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) | TC |S| TTL | | Label(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(n) | TC |S| TTL | | Label(n) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse Path Label(1)| TC |S| TTL | | Reverse Path Label(1)| TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse Path Label(n)| TC |S| TTL | | Reverse Path Label(n)| TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL (value 13) | TC |1| TTL | | GAL (value 13) | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type | |0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Example Query Message Header for an End-to-end SR-MPLS Figure 3: Example Query Message Header for an End-to-End SR-MPLS
Policy in Loopback Measurement Mode Policy in the Loopback Measurement Mode
5. Delay and Loss Measurement 5. Delay and Loss Measurement
5.1. Delay Measurement Message 5.1. Delay Measurement Message
As defined in [RFC6374], MPLS Delay Measurement (DM) query and As defined in [RFC6374], MPLS Delay Measurement (DM) query and
response messages use the Associated Channel Header (ACH) (value response messages use the Associated Channel Header (ACH) (with the
0x000C for delay measurement) [RFC6374], which identifies the message value 0x000C for delay measurement). This value identifies the
type and the message payload as defined in Section 3.2 [RFC6374] message type and message payload that follow the ACH, as defined in
following the ACH. For delay measurement, the same ACH value is used Section 3.2 of [RFC6374]. For delay measurement, the same ACH value
for both links and end-to-end SR-MPLS Policies. is used for both links and end-to-end SR-MPLS Policies.
5.2. Loss Measurement Message 5.2. Loss Measurement Message
The Loss Measurement (LM) protocol can perform two distinct kinds of The Loss Measurement (LM) protocol can perform two distinct kinds of
loss measurement as described in Section 2.9.8 of [RFC6374]. loss measurement as described in Section 2.9.8 of [RFC6374].
* In inferred mode, LM will measure the loss of specially generated * In the inferred mode, LM will measure the loss of specially
test messages to infer the approximate data plane loss level. generated test messages to infer the approximate data plane loss
Inferred mode LM provides only approximate loss accounting. level. Inferred mode LM provides only approximate loss
accounting.
* In direct mode, LM will directly measure data plane packet loss. * In the direct mode, LM will directly measure data plane packet
Direct mode LM provides perfect loss accounting but may require loss. Direct mode LM provides perfect loss accounting but may
hardware support. require hardware support.
As defined in [RFC6374], MPLS LM query and response messages use the As defined in [RFC6374], MPLS LM query and response messages use the
Associated Channel Header (ACH) (value 0x000A for direct loss ACH (with the value 0x000A for direct loss measurement or value
measurement or value 0x000B for inferred loss measurement), which 0x000B for inferred loss measurement). This value identifies the
identifies the message type and the message payload defined in message type and message payload that follow the ACH, as defined in
Section 3.1 [RFC6374] following the ACH. For loss measurement, the Section 3.1 of [RFC6374]. For loss measurement, the same ACH value
same ACH value is used for both links and end-to-end SR-MPLS is used for both links and end-to-end SR-MPLS Policies.
Policies.
5.3. Combined Loss/Delay Measurement Message 5.3. Combined Loss/Delay Measurement Message
As defined in [RFC6374], Combined DM+LM query and response messages As defined in [RFC6374], combined LM/DM query and response messages
use the Associated Channel Header (ACH) (value 0x000D for direct loss use the ACH (with the value 0x000D for direct loss and delay
and delay measurement or value 0x000E for inferred loss and delay measurement or the value 0x000E for inferred loss and delay
measurement), which identifies the message type and the message measurement). The value identies the message type and the message
payload defined in Section 3.3 [RFC6374] following the ACH. For payload that follows the ACH, as defined in Section 3.3 of [RFC6374].
combined loss and delay measurement, the same ACH value is used for For combined loss and delay measurement, the same ACH value is used
both links and end-to-end SR-MPLS Policies. for both links and end-to-end SR-MPLS Policies.
5.4. Counters 5.4. Counters
The Path Segment Identifier (PSID) [RFC9545] MUST be carried in the The Path Segment Identifier (PSID) [RFC9545] MUST be carried in the
received data packet for the traffic flow under measurement for received data packet for the traffic flow under measurement, in order
accounting received traffic on the egress node of the SR-MPLS Policy. to account for received traffic on the egress node of the SR-MPLS
In direct mode, the PSID in the received query message, as shown in Policy. In the direct mode, the PSID in the received query message
Figure 4, can be used to associate the received traffic counter on (as shown in Figure 4) can be used to associate the received traffic
the responder to detect the transmit packet loss for the end-to-end counter on the responder to detect the transmit packet loss for the
SR-MPLS Policy. end-to-end SR-MPLS Policy.
In inferred mode, the PSID in the received query messages, as shown In the inferred mode, the PSID in the received query messages (as
in Figure 4, can be used to count the received query messages on the shown in Figure 4) can be used to count the received query messages
responder to detect the transmit packet loss for an end-to-end SR- on the responder to detect the transmit packet loss for an end-to-end
MPLS Policy. SR-MPLS Policy.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) | TC |S| TTL | | Label(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(n) | TC |S| TTL | | Label(n) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSID | TC |S| TTL | | PSID | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL (value 13) | TC |1| TTL | | GAL (value 13) | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type | |0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Example with Path Segment Identifier for SR-MPLS Policy Figure 4: Example with the PSID for SR-MPLS Policy
The fields "0001", Version, Reserved, and Channel Type shown in The fields 0001, Version, Reserved, and Channel Type shown in
Figure 4 are specified in [RFC5586]. Figure 4 are specified in [RFC5586].
Different values of PSID can be used per Candidate-Path for Different values of the PSID can be used per Candidate-Path to
accounting received traffic to measure packet loss at the Candidate- account for received traffic and to measure packet loss at the
Path level. Similarly, different values of PSID can be used per Candidate-Path level. Similarly, different values of the PSID can be
Segment List of the Candidate-Path for accounting received traffic to used per Segment List (SL) of the Candidate-Path for accounting
measure packet loss at the Segment List level. The same value of received traffic to measure packet loss at the SL level. The same
PSID can be used for all Segment Lists of the SR-MPLS Policy to 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. measure packet loss at the SR-MPLS Policy level.
5.5. Block Number for Counters 5.5. Block Number for Counters
The packet loss measurement using the Alternate-Marking Method The packet loss measurement using the Alternate-Marking Method
defined in [RFC9341] may use the block number for data correlation defined in [RFC9341] may use the block number for data correlation
for the traffic flow under measurement. As defined in Section 3.1 of for the traffic flow under measurement. As defined in Section 3.1 of
[RFC9341], the block number is used to divide the traffic flow into [RFC9341], the block number is used to divide the traffic flow into
consecutive blocks and count the number of packets transmitted and consecutive blocks and count the number of packets transmitted and
received in each block for loss measurement. received in each block for loss measurement.
skipping to change at page 12, line 11 skipping to change at line 496
distributed solution can be used to exchange values of counters on distributed solution can be used to exchange values of counters on
the nodes for loss measurement. That solution is further described the nodes for loss measurement. That solution is further described
in this document using the LM messages defined in [RFC6374]. in this document using the LM messages defined in [RFC6374].
The querier node assigns a block number to the block of data packets 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 the traffic flow under measurement. The querier counts the number
of packets transmitted in each block. The mechanism for the of packets transmitted in each block. The mechanism for the
assignment of the block number is a local decision on the querier and assignment of the block number is a local decision on the querier and
is outside the scope of this document. is outside the scope of this document.
As an example, the querier can use the procedure defined in As an example, the querier can use the procedure defined in [RFC9714]
[I-D.ietf-mpls-inband-pm-encapsulation] for alternate marking of the for alternate marking of the data packets of the traffic flow under
data packets of the traffic flow under measurement. The responder measurement. The responder counts the number of received packets in
counts the number of received packets in each block based on the each block based on the marking in the received data packets. The
marking in the received data packets. The querier and responder querier and responder maintain separate sets of transmit and receive
maintain separate sets of transmit and receive counters for each counters for each marking. The marking can be used as a block
marking. The marking can be used as a block number or a separate number, or a separate block number can be incremented when the
block number can be incremented when the marking changes. Other marking changes. Other methods can be defined for alternate marking
methods can be defined for alternate marking of the data packets of of the data packets of the traffic flow under measurement to assign a
the traffic flow under measurement to assign a block number for the block number for the counters.
counters.
The LM query and response messages defined in [RFC6374] are used to The LM query and response messages defined in [RFC6374] are used to
measure packet loss for the block of data packets transmitted with measure packet loss for the block of data packets transmitted with
the previous marking while data packets carry alternate marking. the previous marking, whereas data packets carry alternate marking.
Specifically, LM query and response messages carry the transmit and Specifically, LM query and response messages carry the transmit and
receive counters (which are currently not incrementing) along with receive counters (which are currently not incrementing) along with
their block number to correlate for loss measurement. their block number to correlate for loss measurement.
"The assumption of the block number mechanism is that the measurement Section 4.3 of [RFC9341] specifies that: "The assumption of this BN
nodes are time synchronized" as specified in Section 4.3 of [RFC9341] mechanism is that the measurement nodes are time synchronized."
is not necessary, as the block number on the responder can be However, this is not necessary, as the block number on the responder
synchronized based on the received LM query messages. can be synchronized based on the received LM query messages.
6. TLV Extensions 6. TLV Extensions
6.1. Return Path TLV Extension 6.1. Return Path TLV Extension
In two-way measurement mode, the responder may transmit the response In the two-way measurement mode, the responder may transmit the
message on a specific return path, for example, in an ECMP response message on a specific return path, for example, in an ECMP
environment. The querier can request in the query message for the environment. The querier can request in the query message for the
responder to send a response message back on a given return path responder to send a response message back on a given return path
(e.g., co-routed bidirectional path). This allows the responder to (e.g., a co-routed bidirectional path). This allows the responder to
avoid creating and maintaining additional states (containing return avoid creating and maintaining additional states (containing return
paths) for the sessions. paths) for the sessions.
The querier may not be directly reachable from the responder in a The querier may not be directly reachable from the responder in a
network. The querier in this case MUST send its reachability path network. In this case, the querier MUST send its reachability path
information to the responder using the Return Path TLV. information to the responder using the Return Path TLV.
[RFC6374] defines query and response messages that can include one or [RFC6374] defines query and response messages that can include one or
more optional TLVs. A new TLV Type (TBA1) is defined in this more optional TLVs. This document defines the the Return Path TLV
document for the Return Path TLV to carry return path information in (5) to carry return path information in query messages. The Return
query messages. The Return Path TLV is specific to a measurement Path TLV is specific to a measurement session. The format of the
session. The format of the Return Path TLV is shown in Figure 5: Return Path TLV is shown in Figure 5 below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBA1 | Length | Reserved | | Type = 5 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Path Sub-TLV | | Return Path Sub-TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Return Path TLV Figure 5: Return Path TLV
The Length is a one-byte field and is equal to the length of the 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. Length MUST NOT Return Path Sub-TLV and the Reserved field in bytes. The Length MUST
be 0 or 1. NOT be 0 or 1.
The Return Path TLV is defined in the Mandatory TLV Type registry The Return Path TLV is defined in the "Mandatory TLV Type" registry
space [RFC6374]. The querier MUST only insert one Return Path TLV in space [RFC6374]. The querier MUST only insert one Return Path TLV in
the query message. The responder that supports this TLV MUST only the query message. The responder that supports this TLV MUST only
process the first Return Path TLV and ignore the other Return Path process the first Return Path TLV and ignore the other Return Path
TLVs if present. The responder that supports this TLV also MUST send TLVs if present. The responder that supports this TLV also MUST send
the response message back on the return path specified in the Return 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 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 response message.
ignored on the receive side.
The Reserved field MUST be set to 0 and MUST be ignored on the
receive side.
6.1.1. Return Path Sub-TLV Extension 6.1.1. Return Path Sub-TLV Extension
The Return Path TLV contains a Sub-TLV to carry the return path. The 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 Figure 6. 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 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: Label Stack Sub-TLV in the Return Path TLV is of the following type:
* Type (value 1): MPLS Label Stack of the Return Path * Type (value 1): MPLS Label Stack of the Return Path
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=1 | Length | Reserved | | Type=1 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) | TC |S| TTL | | Label(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(n) | TC |1| TTL | | Label(n) | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: MPLS Label Stack Sub-TLV in Return Path TLV Figure 6: MPLS Label Stack Sub-TLV in the Return Path TLV
The MPLS Label Stack contains a list of 32-bit LSE that includes a The MPLS label stack contains a list of 32-bit LSEs that includes a
20-bit label value, 8-bit TTL value, 3-bit TC value, and 1-bit EOS 20-bit label value, an 8-bit TTL value, a 3-bit TC value, and a 1-bit
(S) field. An MPLS Label Stack Sub-TLV may carry a stack of labels End of Stack (S) field. An MPLS Label Stack Sub-TLV may carry a
or a Binding SID label [RFC8402] of the Return SR-MPLS Policy. 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 The Length is a one-byte field and is equal to the length of the
label stack field and the Reserved field in bytes. Length MUST NOT label stack field and the Reserved field in bytes. The Length MUST
be 0 or 1. NOT be 0 or 1.
The Return Path TLV MUST carry only one Return Path Sub-TLV. The 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 Stack in the Return Path Sub-TLV MUST contain at least one
MPLS Label. The responder that supports this Sub-TLV MUST only MPLS Label. The responder that supports this Sub-TLV MUST only
process the first Return Path Sub-TLV and ignore the other Return process the first Return Path Sub-TLV and ignore the other Return
Path Sub-TLVs if present. The responder that supports this Sub-TLV Path Sub-TLVs if present. The responder that supports this Sub-TLV
MUST send the response message back on the return path specified in MUST send the response message back on the return path specified in
the Return Path Sub-TLV. the Return Path Sub-TLV.
The Reserved field MUST be set to 0 and MUST be ignored on the The Reserved field MUST be set to 0 and MUST be ignored on the
receive side. receive side.
6.2. Block Number TLV Extension 6.2. Block Number TLV Extension
[RFC6374] defines query and response messages that can include one or [RFC6374] defines query and response messages that can include one or
more optional TLVs. A new TLV Type (value TBA2) is defined in this more optional TLVs. This document defines the Block Number TLV (6)
document to carry the Block Number (8-bit) of the traffic counters in to carry (8-bit) Block Number of the traffic counters in the LM query
the LM query and response messages. The format of the Block Number and response messages. The format of the Block Number TLV is shown
TLV is shown in Figure 7: in Figure 7:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBA2 | Length | Reserved |R| Block Number | | Type=6 | Length | Reserved |R| Block Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Block Number TLV Figure 7: Block Number TLV
The Length is a one-byte field and is equal to 2 bytes. 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 The Block Number TLV is defined in the "Mandatory TLV Type" registry
space [RFC6374]. The querier MUST only insert one Block Number TLV space [RFC6374]. The querier MUST only insert one Block Number TLV
in the query message to identify the Block Number for the traffic in the query message to identify the Block Number for the traffic
counters in the forward direction. The responder that supports this counters in the forward direction. The responder that supports this
TLV MUST only insert one Block Number TLV in the response message to TLV MUST only insert one Block Number TLV in the response message to
identify the Block Number for the traffic counters in the reverse identify the Block Number for the traffic counters in the reverse
direction. The responder also MUST return the first Block Number TLV direction. The responder also MUST return the first Block Number TLV
from the query message and ignore the other Block Number TLVs if from the query message and ignore the other Block Number TLVs if
present. The Block Number TLV is specific to a measurement session. present. The Block Number TLV is specific to a measurement session.
The R flag is used to indicate the query and response message The R flag is used to indicate the query and response message
direction associated with the Block Number. The R flag MUST be clear direction associated with the Block Number. The R flag MUST be clear
skipping to change at page 15, line 37 skipping to change at line 654
and Counter 2, and set in the response message for the Block Number and Counter 2, and set in the response message for the Block Number
associated with Counter 3 and Counter 4. associated with Counter 3 and Counter 4.
The Reserved field MUST be set to 0 and MUST be ignored on the The Reserved field MUST be set to 0 and MUST be ignored on the
receive side. receive side.
7. ECMP for SR-MPLS Policies 7. ECMP for SR-MPLS Policies
The SLs of an SR-MPLS Policy can have ECMPs between the source and The SLs of an SR-MPLS Policy can have ECMPs between the source and
transit nodes, between transit nodes, and between transit and transit nodes, between transit nodes, and between transit and
destination nodes. Usage of node SID [RFC8402] by the SLs of an SR- destination nodes. Usage of a node-SID [RFC8402] by the SLs of an
MPLS Policy can result in ECMP paths. In addition, usage of Anycast SR-MPLS Policy can result in ECMP paths. In addition, usage of an
SID [RFC8402] by the SLs of an SR-MPLS Policy can result in ECMP Anycast-SID [RFC8402] by the SLs of an SR-MPLS Policy can result in
paths via transit nodes that are part of that Anycast group. The ECMP paths via transit nodes that are part of that anycast group.
query and response messages are sent to traverse different ECMP paths The query and response messages are sent to traverse different ECMP
to measure the delay of each ECMP path of an SL. paths to measure the delay of each ECMP path of an SL.
The forwarding plane has various hashing functions available to The forwarding plane has various hashing functions available to
forward packets on specific ECMP paths. For end-to-end SR-MPLS forward packets on specific ECMP paths. For end-to-end SR-MPLS
Policy delay measurement, different entropy label [RFC6790] values Policy delay measurement, different entropy label values [RFC6790]
can be used in query and response messages to take advantage of the can be used in query and response messages to take advantage of the
hashing function in the forwarding plane to influence the ECMP path hashing function in the forwarding plane to influence the ECMP path
taken by them. taken by them.
The considerations for loss measurement for different ECMP paths of The considerations for loss measurement for different ECMP paths of
an SR-MPLS Policy are outside the scope of this document. an SR-MPLS Policy are outside the scope of this document.
8. Extended TE Link Metrics Advertisements 8. Extended TE Link Metrics Advertisement
The extended TE metrics for link delay (namely, average delay, The extended TE metrics for link delay (namely, average delay,
minimum delay, maximum delay and delay-variance) and packet loss can minimum delay, maximum delay, and delay-variance) and packet loss can
be computed using the performance measurement procedures described in be computed using the performance measurement procedures described in
this document and advertised in the routing domain as follows: this document and can be advertised in the routing domain as follows:
* For OSPF, IS-IS, and BGP-LS, protocol extensions defined in * For OSPF, IS-IS, and the Border Gateway Protocol - Link State
[RFC7471], [RFC8570], and [RFC8571], respectively, are used for (BGP-LS), the protocol extensions defined in [RFC7471], [RFC8570],
advertising the extended TE link delay and loss metrics in the and [RFC8571], respectively, are used for advertising the extended
network. TE link delay and loss metrics in the network.
* The extended TE link delay and loss metrics are advertised for * The extended TE link delay and loss metrics are advertised for
Layer-2 LAG bundle member links in OSPF [RFC9356] and IS-IS Layer-2 LAG bundle member links in OSPF [RFC9356] and IS-IS
[RFC8668] using the same protocol extensions defined in [RFC7471] [RFC8668] using the same protocol extensions defined in [RFC7471]
and [RFC8570], respectively. and [RFC8570], respectively.
* The advertised delay-variance metric is computed as Packet Delay * The advertised delay-variance metric is computed as Packet Delay
Variation (PDV), as described in Section 4.2 of [RFC5481]. Variation (PDV), as described in Section 4.2 of [RFC5481].
9. Backwards Compatibility 9. Backwards Compatibility
The procedures defined in this document are backwards compatible with The procedures defined in this document are backwards compatible with
the procedures defined in [RFC6374] at both the querier and the procedures defined in [RFC6374] at both the querier and the
responder. If the responder does not support the new Mandatory TLV responder. If the responder does not support the new Mandatory TLV
Types defined in this document it will return Error 0x17: Unsupported Types defined in this document, it will return Error 0x17:
Mandatory TLV Object as per [RFC6374]. Unsupported Mandatory TLV Object as per [RFC6374].
10. Manageability Considerations 10. Manageability Considerations
The manageability considerations described in Section 7 of [RFC6374] The manageability considerations described in Section 7 of [RFC6374]
and Section 6 of [RFC7876] are applicable to this specification. and Section 6 of [RFC7876] are applicable to this specification.
11. Security Considerations 11. Security Considerations
The security considerations specified in [RFC6374], [RFC7471], The security considerations specified in [RFC6374], [RFC7471],
[RFC8570], [RFC8571], [RFC7876], and [RFC9341] also apply to the [RFC8570], [RFC8571], [RFC7876], and [RFC9341] also apply to the
procedures described in this document. procedures described in this document.
The procedure defined in this document is intended for deployment in The procedure defined in this document is intended for deployment in
a single operator administrative domain. As such, the querier node, a single operator administrative domain. As such, the querier node,
responder node, forward, and return paths are provisioned by the the responder node, the forward path, and the return paths are
operator for the probe session. It is assumed that the operator has provisioned by the operator for the probe session. It is assumed
verified the integrity of the forward and return paths of the probe that the operator has verified the integrity of the forward and
packets. return paths of the probe packets.
The "Return Path" TLV extensions defined in this document may be used The Return Path TLV extensions defined in this document may be used
for potential address spoofing. For example, a query message may for potential address spoofing. For example, a query message may
carry a return path that has a destination that is not local at the carry a return path that has a destination that is not local at the
querier. To prevent such possible attacks, the responder may drop querier. To prevent such possible attacks, the responder may drop
the query messages when it cannot determine whether the return path the query messages when it cannot determine whether the return path
has the destination local at the querier. The querier may send a has the destination local at the querier. The querier may send a
proper source address in the "Source Address" TLV that the responder proper source address in the Source Address TLV. The responder can
can use to make that determination, for example, by checking the use this to make that determination, for example, by checking the
access control list provisioned by the operator. access control list provisioned by the operator.
12. IANA Considerations 12. IANA Considerations
IANA is requested to allocate values for the following Mandatory TLV IANA has allocated values for the following Mandatory TLV Types
Types for [RFC6374] from the "MPLS Loss/Delay Measurement TLV Object" [RFC6374] from the "MPLS Loss/Delay Measurement TLV Object" registry
registry contained within the "Generic Associated Channel (G-ACh) contained within the "Generic Associated Channel (G-ACh) Parameters"
Parameters" registry set: registry group:
+=======+==================+===============+ +======+==============+===========+
| Value | Description | Reference | | Code | Description | Reference |
+=======+==================+===============+ +======+==============+===========+
| TBA1 | Return Path TLV | This document | | 5 | Return Path | RFC 9779 |
+-------+------------------+---------------+ +------+--------------+-----------+
| TBA2 | Block Number TLV | This document | | 6 | Block Number | RFC 9779 |
+-------+------------------+---------------+ +------+--------------+-----------+
Table 1: MPLS Loss/Delay Measurement TLV Table 1: MPLS Loss/Delay
Types Measurement TLV Types
The Block Number TLV is carried in the query and response messages, The Block Number TLV is carried in the query and response messages,
and the Return Path TLV is carried in the query messages. and the Return Path TLV is carried in the query messages.
IANA is requested to create a registry for "Return Path Sub-TLV IANA has created the "Return Path Sub-TLV Types" registry. All code
Type." All code points in the range 0 through 175 in this registry points are allocated per the registration policies shown in Table 2
shall be allocated according to the "IETF Review" procedure as (see [RFC8126]).
specified in [RFC8126]. Code points in the range 176 through 239 in
this registry shall be allocated according to the "First Come, First
Served" procedure as specified in [RFC8126]. Remaining code points
are allocated according to Table 2:
+===========+=========================+===============+ +===========+=========================+===========+
| Value | Description | Reference | | Value | Description | Reference |
+===========+=========================+===============+ +===========+=========================+===========+
| 1 - 175 | IETF Review | This document | | 1 - 175 | IETF Review | RFC 9779 |
+-----------+-------------------------+---------------+ +-----------+-------------------------+-----------+
| 176 - 239 | First Come First Served | This document | | 176 - 239 | First Come First Served | RFC 9779 |
+-----------+-------------------------+---------------+ +-----------+-------------------------+-----------+
| 240 - 251 | Experimental Use | This document | | 240 - 251 | Experimental Use | RFC 9779 |
+-----------+-------------------------+---------------+ +-----------+-------------------------+-----------+
| 252 - 254 | Private Use | This document | | 252 - 254 | Private Use | RFC 9779 |
+-----------+-------------------------+---------------+ +-----------+-------------------------+-----------+
Table 2: Return Path Sub-TLV Type Registry Table 2: Return Path Sub-TLV Type Registry
This document defines the following values in the Return Path Sub-TLV This document defines the following values in the "Return Path Sub-
Type registry: TLV Type" registry:
+=======+=====================================+===============+ +=======+=====================================+===========+
| Value | Description | Reference | | Value | Description | Reference |
+=======+=====================================+===============+ +=======+=====================================+===========+
| 0 | Reserved | This document | | 0 | Reserved | RFC 9779 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+-----------+
| 1 | MPLS Label Stack of the Return Path | This document | | 1 | MPLS Label Stack of the Return Path | RFC 9779 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+-----------+
| 255 | Reserved | This document | | 255 | Reserved | RFC 9779 |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+-----------+
Table 3: Return Path Sub-TLV Types Table 3: Return Path Sub-TLV Types
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 20, line 46 skipping to change at line 886
[RFC9356] Talaulikar, K., Ed. and P. Psenak, "Advertising Layer 2 [RFC9356] Talaulikar, K., Ed. and P. Psenak, "Advertising Layer 2
Bundle Member Link Attributes in OSPF", RFC 9356, Bundle Member Link Attributes in OSPF", RFC 9356,
DOI 10.17487/RFC9356, January 2023, DOI 10.17487/RFC9356, January 2023,
<https://www.rfc-editor.org/info/rfc9356>. <https://www.rfc-editor.org/info/rfc9356>.
[RFC9545] Cheng, W., Ed., Li, H., Li, C., Ed., Gandhi, R., and R. [RFC9545] Cheng, W., Ed., Li, H., Li, C., Ed., Gandhi, R., and R.
Zigler, "Path Segment Identifier in MPLS-Based Segment Zigler, "Path Segment Identifier in MPLS-Based Segment
Routing Networks", RFC 9545, DOI 10.17487/RFC9545, Routing Networks", RFC 9545, DOI 10.17487/RFC9545,
February 2024, <https://www.rfc-editor.org/info/rfc9545>. February 2024, <https://www.rfc-editor.org/info/rfc9545>.
[I-D.ietf-mpls-inband-pm-encapsulation] [RFC9714] Cheng, W., Ed., Min, X., Ed., Zhou, T., Dai, J., and Y.
Cheng, W., Min, X., Zhou, T., Dai, J., and Y. Peleg, Peleg, "Encapsulation for MPLS Performance Measurement
"Encapsulation For MPLS Performance Measurement with with the Alternate-Marking Method", RFC 9714,
Alternate-Marking Method", Work in Progress, Internet- DOI 10.17487/RFC9714, February 2025,
Draft, draft-ietf-mpls-inband-pm-encapsulation-18, 12 <https://www.rfc-editor.org/info/rfc9714>.
September 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-mpls-inband-pm-encapsulation-18>.
[IEEE802.1AX] [IEEE802.1AX]
IEEE Std. 802.1AX, "IEEE Standard for Local and IEEE, "IEEE Standard for Local and Metropolitan Area
metropolitan area networks - Link Aggregation", November Networks - Link Aggregation", IEEE Std 802.1AX-2020,
2008. DOI 10.1109/IEEESTD.2020.9105034, May 2020,
<https://doi.org/10.1109/IEEESTD.2020.9105034>.
Acknowledgments Acknowledgments
The authors would like to thank Thierry Couture and Ianik Semco for The authors would like to thank Thierry Couture and Ianik Semco for
the discussions on the use cases for performance measurement in the discussions on the use cases for performance measurement in
segment routing networks. The authors would like to thank Patrick segment routing networks. The authors would like to thank Patrick
Khordoc, Ruby Lin, and Haowei Shi for implementing the mechanisms Khordoc, Ruby Lin, and Haowei Shi for implementing the mechanisms
defined in this document. The authors would like to thank Greg defined in this document. The authors would like to thank Greg
Mirsky and Xiao Min for providing many useful comments and Mirsky and Xiao Min for providing many useful comments and
suggestions. The authors would also like to thank Stewart Bryant, suggestions. The authors would also like to thank Stewart Bryant,
Sam Aldrin, Tarek Saad, and Rajiv Asati for their review comments. Sam Aldrin, Tarek Saad, and Rajiv Asati for their review comments.
Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for MPLS-RT expert Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for the MPLS expert
review, Zhaohui Zhang for RTGDIR early review, Tony Li for shepherd's review; Zhaohui Zhang for the RTGDIR early review; Tony Li for
review, Ned Smith for SECDIR review, Roni Even for Gen-ART review, shepherd's review; Ned Smith for the SECDIR review; Roni Even for the
Marcus Ihlar for TSV-ART review, Dhruv Dhody for OPSDIR review, Gen-ART review; Marcus Ihlar for the TSV-ART review; Dhruv Dhody for
Gunter Van de Velde, Paul Wouters, Eric Vyncke, Murray Kucherawy, the OPSDIR review; and Gunter Van de Velde, Paul Wouters, Éric
John Scudder, and Roman Danyliw for IESG review. Vyncke, Murray Kucherawy, John Scudder, and Roman Danyliw for the
IESG review.
Contributors Contributors
Sagar Soni Sagar Soni
Cisco Systems, Inc. Cisco Systems, Inc.
Email: sagsoni@cisco.com Email: sagsoni@cisco.com
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
Email: zali@cisco.com Email: zali@cisco.com
 End of changes. 106 change blocks. 
392 lines changed or deleted 393 lines changed or added

This html diff was produced by rfcdiff 1.48.