rfc9779.original.xml   rfc9779.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
<!ENTITY I-D.ietf-mpls-inband-pm-encapsulation SYSTEM
"https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-i
nband-pm-encapsulation.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.2119.xml">
<!ENTITY RFC3031 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.3031.xml">
<!ENTITY RFC3032 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.3032.xml">
<!ENTITY RFC6374 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.6374.xml">
<!ENTITY RFC7876 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.7876.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8174.xml">
<!ENTITY RFC9341 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.9341.xml">
<!ENTITY RFC5481 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.5481.xml">
<!ENTITY RFC5586 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.5586.xml">
<!ENTITY RFC6790 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.6790.xml">
<!ENTITY RFC7471 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.7471.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8126.xml">
<!ENTITY RFC8402 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8402.xml">
<!ENTITY RFC8570 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8570.xml">
<!ENTITY RFC8571 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8571.xml">
<!ENTITY RFC8668 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8668.xml">
<!ENTITY RFC9256 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.9256.xml">
<!ENTITY RFC9356 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.9356.xml">
<!ENTITY RFC9545 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.9545.xml">
<!ENTITY RFC5082 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.5082.xml">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d
raft-ietf-mpls-rfc6374-sr-17" category="std" ipr="trust200902" obsoletes="" upda <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d
tes="" xml:lang="en" sortRefs="false" consensus="yes" symRefs="true" tocInclude= raft-ietf-mpls-rfc6374-sr-17" number="9779" category="std" ipr="trust200902" obs
"true" version="3"> oletes="" updates="" xml:lang="en" sortRefs="false" consensus="yes" symRefs="tru
<!-- xml2rfc v2v3 conversion 3.12.3 --> e" tocInclude="true" version="3">
<!-- Generated by id2xml 1.5.0 on 2020-03-06T17:47:05Z -->
<front> <front>
<title abbrev="Performance Measurement for SR-MPLS">Performance Measurement <title abbrev="Performance Measurement for SR-MPLS">Performance Measurement
for Segment Routing Networks with MPLS Data Plane</title> for Segment Routing Networks with the MPLS Data Plane</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mpls-rfc6374-sr-17"/> <seriesInfo name="RFC" value="9779"/>
<author fullname="Rakesh Gandhi" initials="R." role="editor" surname="Gandhi "> <author fullname="Rakesh Gandhi" initials="R." role="editor" surname="Gandhi ">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Canada</street> <country>Canada</country>
</postal> </postal>
<email>rgandhi@cisco.com</email> <email>rgandhi@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils"> <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<email>cfilsfil@cisco.com</email> <email>cfilsfil@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Daniel Voyer" initials="D." surname="Voyer"> <author fullname="Daniel Voyer" initials="D." surname="Voyer">
<organization>Bell Canada</organization> <organization>Bell Canada</organization>
<address> <address>
<email>daniel.voyer@bell.ca</email> <email>daniel.voyer@bell.ca</email>
</address> </address>
</author> </author>
<author fullname="Stefano Salsano" initials="S." surname="Salsano"> <author fullname="Stefano Salsano" initials="S." surname="Salsano">
<organization>Universita di Roma "Tor Vergata"</organization> <organization>Universita di Roma "Tor Vergata"</organization>
<address> <address>
<postal> <postal>
<street>Italy</street> <country>Italy</country>
</postal> </postal>
<email>stefano.salsano@uniroma2.it</email> <email>stefano.salsano@uniroma2.it</email>
</address> </address>
</author> </author>
<author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen"> <author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<email>mach.chen@huawei.com</email> <email>mach.chen@huawei.com</email>
</address> </address>
</author> </author>
<date day="17" month="October" year="2024"/> <date month="April" year="2025"/>
<workgroup>MPLS Working Group</workgroup> <area>RTG</area>
<abstract> <workgroup>mpls</workgroup>
<keyword>Delay Measurement</keyword>
<keyword>Loss Measurement</keyword>
<keyword>Link Measurement</keyword>
<keyword>SR-MPLS Policy Measurement</keyword>
<abstract>
<t> <t>
This document specifies the application of the MPLS loss and delay measurement This document specifies the application of the MPLS loss and delay
techniques, originally defined in RFC 6374, RFC 7876, and RFC 9341 within measurement techniques (originally defined in RFCs 6374, 7876, and
Segment Routing (SR) networks that utilize the MPLS data plane (SR-MPLS). Segmen 9341) within Segment Routing (SR) networks that utilize the MPLS data
t Routing plane, also referred to as Segment Routing over MPLS (SR-MPLS). SR
enables the forwarding of packets through an ordered list of instructions, enables the forwarding of packets through an ordered list of
known as segments, which are imposed at the ingress node. instructions, known as segments, which are imposed at the ingress
This document defines the procedures and extensions necessary to perform node. This document defines the procedures and extensions necessary
accurate measurement of packet loss and delay in SR-MPLS environments, ensuring to perform accurate measurement of packet loss and delay in SR-MPLS
that 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 of links and maintain the quality of service across their SR-based MPLS
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.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sect-1" numbered="true" toc="default"> <section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t> <t>Segment Routing (SR), as specified in <xref target="RFC8402"/>,
Segment Routing (SR), as specified in <xref target="RFC8402" format="default"/>, leverages the source routing paradigm and applies to both the
leverages the source routing Multiprotocol Label Switching (MPLS) and Internet Protocol version 6
paradigm and applies to both the Multiprotocol Label Switching (SR-MPLS) and (IPv6) data planes. These are referred to as Segment Routing over MPLS
IPv6 (SRv6) data planes. SR takes advantage of Equal-Cost Multipaths (ECMPs) (SR-MPLS) and Segment Routing over IPv6 (SRv6), respectively. SR takes
between source and transit nodes, between transit nodes, and between transit advantage of Equal-Cost Multipaths (ECMPs) between source and transit
and destination nodes. SR Policies, defined in <xref target="RFC9256" format="de nodes, between transit nodes, and between transit and destination
fault"/>, are used to steer nodes. SR Policies, defined in <xref target="RFC9256"
traffic through specific, user-defined paths using a list of segments. format="default"/>, are used to steer traffic through specific,
</t> user-defined paths using a list of segments.</t>
<t> <t>A comprehensive SR Performance Measurement toolset is one of the
A comprehensive SR Performance Measurement toolset is one of the essential essential requirements for measuring network performance to provide
requirements for measuring network performance to provide Service Level Service Level Agreements (SLAs).</t>
Agreements (SLAs).
</t>
<t> <t><xref target="RFC6374" format="default"/> specifies protocol
<xref target="RFC6374" format="default"/> specifies protocol mechanisms to enabl mechanisms to enable efficient and accurate measurement of packet loss,
e efficient and accurate measurement of packet loss, one-way and two-way delay, one-way and two-way delay, as well as related metrics such as
as well as related metrics such as delay-variation in MPLS networks. delay-variation in MPLS networks.</t>
</t>
<t> <t><xref target="RFC7876" format="default"/> specifies mechanisms for
<xref target="RFC7876" format="default"/> specifies mechanisms for sending and p sending and processing out-of-band responses over a UDP return path when
rocessing out-of-band responses over a UDP return path when receiving query mess receiving query messages defined in <xref target="RFC6374"
ages defined in <xref target="RFC6374" format="default"/>. These mechanisms can format="default"/>. These mechanisms can be applied to SR-MPLS networks.</
be applied to SR-MPLS networks. t>
</t>
<t> <t><xref target="RFC9341" format="default"/> defines the
<xref target="RFC9341" format="default"/> defines the Alternate-Marking Method u Alternate-Marking Method using Block Numbers as a data correlation
sing block number as a data correlation mechanism for packet loss measurement. mechanism for packet loss measurement.</t>
</t>
<t> <t>This document utilizes the mechanisms from <xref target="RFC6374"
This document utilizes the mechanisms from <xref target="RFC6374" format="defaul format="default"/>, <xref target="RFC7876" format="default"/>, and <xref
t"/>, <xref target="RFC7876" format="default"/>, and <xref target="RFC9341" form target="RFC9341" format="default"/> for delay and loss measurements in
at="default"/> for delay and loss measurements in SR-MPLS networks. This include SR-MPLS networks. This includes coverage of links and end-to-end SR-MPLS
s coverage of links and end-to-end SR-MPLS paths, as well as SR Policies. paths, as well as SR Policies.</t>
</t>
<t> <t>This document extends <xref target="RFC6374"/> by defining
This document defines Return Path and Block Number TLV extensions for <xref targ Return Path and Block Number TLVs (see <xref target="sect-6"/>) for delay
et="RFC6374" format="default"/>, in Section 6, for delay and loss measurement in and loss measurement in SR-MPLS
SR-MPLS networks. These TLV extensions also apply to MPLS Label Switched Paths networks. These TLVs can also be used in MPLS Label Switched Paths
(LSPs) <xref target="RFC3031" format="default"/>. However, the procedure for del (LSPs) <xref target="RFC3031" format="default"/>. However, the procedure
ay and loss measurement of MPLS LSPs is outside the scope of this document. for delay and loss measurement of MPLS LSPs is outside the scope of this
</t> document.</t>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default"> <section anchor="sect-2" numbered="true" toc="default">
<name>Conventions Used in This Document</name> <name>Conventions Used in This Document</name>
<section anchor="sect-2.1" numbered="true" toc="default"> <section anchor="sect-2.1" numbered="true" toc="default">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>
<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", ",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
described in BCP 14 <xref target="RFC2119" format="default"/> <xref target=" "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
RFC8174" format="default"/> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
when, and only when, they appear in all capitals, as shown here. be
</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section anchor="sect-2.2" numbered="true" toc="default"> <section anchor="sect-2.2" numbered="true" toc="default">
<name>Abbreviations</name> <name>Abbreviations</name>
<t>
ACH: Associated Channel Header.</t> <dl spacing="normal" newline="false">
<t> <dt>ACH:</dt><dd>Associated Channel Header</dd>
DM: Delay Measurement.</t> <dt>DM:</dt><dd>Delay Measurement</dd>
<t> <dt>ECMP:</dt><dd>Equal-Cost Multipath</dd>
ECMP: Equal Cost Multi-Path.</t> <dt>G-ACh:</dt><dd>Generic Associated Channel</dd>
<t> <dt>GAL:</dt><dd>Generic Associated Channel Label</dd>
G-ACh: Generic Associated Channel (G-ACh).</t> <dt>LM:</dt><dd>Loss Measurement</dd>
<t> <dt>LSE:</dt><dd>Label Stack Entry</dd>
GAL: Generic Associated Channel (G-ACh) Label.</t> <dt>MPLS:</dt><dd>Multiprotocol Label Switching</dd>
<t> <dt>PSID:</dt><dd>Path Segment Identifier</dd>
LM: Loss Measurement.</t> <dt>SID:</dt><dd>Segment Identifier</dd>
<t> <dt>SL:</dt><dd>Segment List</dd>
LSE: Label Stack Entry.</t> <dt>SR:</dt><dd>Segment Routing</dd>
<t> <dt>SR-MPLS:</dt><dd>Segment Routing over MPLS</dd>
MPLS: Multiprotocol Label Switching.</t> <dt>TC:</dt><dd>Traffic Class</dd>
<t> <dt>TE:</dt><dd>Traffic Engineering</dd>
PSID: Path Segment Identifier.</t> <dt>TTL:</dt><dd>Time to Live</dd>
<t> <dt>URO:</dt><dd>UDP Return Object</dd>
SID: Segment Identifier.</t> </dl>
<t>
SL: Segment List.</t>
<t>
SR: Segment Routing.</t>
<t>
SR-MPLS: Segment Routing with MPLS data plane.</t>
<t>
TC: Traffic Class.</t>
<t>
TE: Traffic Engineering.</t>
<t>
TTL: Time-To-Live.</t>
<t>
URO: UDP Return Object.</t>
</section> </section>
<section anchor="sect-2.3" numbered="true" toc="default"> <section anchor="sect-2.3" numbered="true" toc="default">
<name>Reference Topology</name> <name>Reference Topology</name>
<t> <t>In the reference topology shown in <xref
In the Reference Topology shown in Figure 1, the querier node Q1 initiates a que target="ure-reference-topology"/>, the querier node Q1 initiates a
ry message, and the responder node R1 transmits a response message for the query query message, and the responder node R1 transmits a response message
message received. The response message may be sent back to the querier node Q1 for the query message received. The response message may be sent back
on the same path (same set of links and nodes) or a different path in the revers to the querier node Q1 on the same path (the same set of links and nodes)
e direction from the path taken towards the responder R1. or on a different path in the reverse direction from the path taken
</t> towards the responder R1.</t>
<t> <t>T1 is a transmit timestamp, and T4 is a receive timestamp; both are
T1 is a transmit timestamp, and T4 is a receive timestamp, both added by node Q1 added by node Q1. T2 is a receive timestamp, and T3 is a transmit
. T2 is a receive timestamp, and T3 is a transmit timestamp, both added by node timestamp; both are added by node R1.</t>
R1.
</t>
<t> <t>SR is enabled with the MPLS data plane on nodes Q1 and R1. The
SR is enabled with the MPLS data plane on nodes Q1 and R1. nodes Q1 and R1 are connected via a channel (<xref target="RFC6374"
The nodes Q1 and R1 are connected via a channel (Section 2.9.1 of <xref target=" sectionFormat="of" section="2.9.1"/>). The channel may be a directly
RFC6374" format="default"/>). connected link enabled with MPLS (<xref target="RFC6374"
The channel may be a directly connected link enabled with MPLS (Section 2.9.1 of sectionFormat="of" section="2.9.1"/>) or an SR-MPLS path <xref
<xref target="RFC6374" format="default"/>) target="RFC8402" format="default"/>. The link may be a physical
or an SR-MPLS path <xref target="RFC8402" format="default"/>. interface, a virtual link, a Link Aggregation Group (LAG) <xref
The link may be a physical interface, a virtual link, or a Link Aggregation Grou target="IEEE802.1AX" format="default"/>, or a LAG member link. The
p (LAG) <xref target="IEEE802.1AX" format="default"/>, SR-MPLS path may be an SR-MPLS Policy <xref target="RFC9256"
or a LAG member link. The SR-MPLS path may be an SR-MPLS Policy <xref target="RF format="default"/> on node Q1 (called the "head-end") with the destinatio
C9256" format="default"/> n
on node Q1 (called head-end) with the destination to node R1 (called tail-end). to node R1 (called the "tail-end").</t>
</t>
<figure anchor="ure-reference-topology"> <figure anchor="ure-reference-topology">
<name>Reference Topology</name> <name>Reference Topology</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
T1 T2
T1 T2 / \
/ \ +-------+ Query +-------+
+-------+ Query +-------+ | | - - - - - - - - - ->| |
| | - - - - - - - - - ->| | | Q1 |=====================| R1 |
| Q1 |=====================| R1 | | |<- - - - - - - - - - | |
| |<- - - - - - - - - - | | +-------+ Response +-------+
+-------+ Response +-------+ \ /
\ / T4 T3
T4 T3 Querier Responder
Querier Responder
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default"> <section anchor="sect-3" numbered="true" toc="default">
<name>Overview</name> <name>Overview</name>
<t> <t>
In this document, the procedures defined in In this document, the procedures defined in <xref target="RFC6374"
<xref target="RFC6374" format="default"/>, <xref target="RFC7876" format="defaul format="default"/>, <xref target="RFC7876" format="default"/>, and
t"/>, and <xref target="RFC9341" format="default"/> <xref target="RFC9341" format="default"/> are utilized for delay and
are utilized for delay and loss measurement in SR-MPLS networks. Specifically, loss measurement in SR-MPLS networks. Specifically, the one-way,
the one-way, two-way, and round-trip delay measurements described in Section two-way, and round-trip delay measurements described in <xref
2.4 of <xref target="RFC6374" format="default"/> are further elaborated for app target="RFC6374" sectionFormat="of" section="2.4"/> are further
lication within SR-MPLS elaborated for application within SR-MPLS networks. Similarly, the
networks. Similarly, the packet loss measurement procedures outlined in Section packet loss measurement procedures outlined in <xref
2.2 of <xref target="RFC6374" format="default"/> are extended for use in SR-MPLS target="RFC6374" sectionFormat="of" section="2.2"/> are extended for
networks. use in SR-MPLS networks.</t>
</t>
<t>
Packet loss measurement using the Alternate-Marking Method defined in <xref targ
et="RFC9341" format="default"/>
may employ the Block Number for data correlation. This is achieved by utilizing
the Block Number TLV extension defined in this document.
</t>
<t> <t>Packet loss measurement using the Alternate-Marking Method
In SR-MPLS networks, the query messages defined in <xref target="RFC6374" fo defined in <xref target="RFC9341" format="default"/> may employ the
rmat="default"/> Block Number for data correlation. This is achieved by utilizing the
MUST be transmitted along the same path as Block Number TLV extension defined in this document.</t>
the data traffic for links and end-to-end SR-MPLS paths,
to collect both transmit and receive timestamps for delay measurement and
to collect both transmit and receive traffic counters for loss measurement.
</t>
<t> <t>In SR-MPLS networks, the query messages defined in <xref
If it is desired in SR-MPLS networks that the same path (i.e., the same set of target="RFC6374" format="default"/> <bcp14>MUST</bcp14> be
links and nodes) between the querier and responder be used in both directions transmitted along the same path as the data traffic for links and
of the measurement, this can be achieved by using the Return Path TLV extension end-to-end SR-MPLS paths. This is to collect both transmit and receive
defined in this document. timestamps for delay measurement and to collect both transmit and
</t> receive traffic counters for loss measurement.</t>
<t> <t>If it is desired in SR-MPLS networks that the same path (i.e.,
The performance measurement procedures for links can be used to compute the same set of links and nodes) between the querier and responder
extended Traffic Engineering (TE) metrics for delay and loss, as described be used in both directions of the measurement, then this can be achieve
herein. These metrics are advertised in the network using the routing protocol d
extensions defined in <xref target="RFC7471" format="default"/>, <xref target="R by using the Return Path TLV extension defined in this document.</t>
FC8570" format="default"/>, and <xref target="RFC8571" format="default"/>.
</t> <t>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 <xref
target="RFC7471" format="default"/>, <xref target="RFC8570"
format="default"/>, and <xref target="RFC8571"
format="default"/>.</t>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default"> <section anchor="sect-4" numbered="true" toc="default">
<name>Query and Response Messages</name> <name>Query and Response Messages</name>
<section anchor="sect-4.1" numbered="true" toc="default"> <section anchor="sect-4.1" numbered="true" toc="default">
<name>Query Message for Links and SR-MPLS Policies</name> <name>Query Message for Links and SR-MPLS Policies</name>
<section anchor="sect-4.1.1" numbered="true" toc="default"> <section anchor="sect-4.1.1" numbered="true" toc="default">
<name>Query Message for Links</name> <name>Query Message for Links</name>
<t> <t>The query message, as defined in <xref target="RFC6374"
The query message, as defined in <xref target="RFC6374" format="default"/>, is s format="default"/>, is sent over the links for both delay and loss
ent over the links for both delay and loss measurement. In each Label Stack Entr measurement. In each Label Stack Entry (LSE) <xref target="RFC3032"
y (LSE) <xref target="RFC3032" format="default"/> in the MPLS label stack, the T format="default"/> in the MPLS label stack, the TTL value
TL value MUST be set to 255 <xref target="RFC5082" format="default"/>. <bcp14>MUST</bcp14> be set to 255 <xref target="RFC5082"
</t> format="default"/>.</t>
</section> </section>
<section anchor="sect-4.1.2" numbered="true" toc="default"> <section anchor="sect-4.1.2" numbered="true" toc="default">
<name>Query Message for SR-MPLS Policies</name> <name>Query Message for SR-MPLS Policies</name>
<t> <t>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 (SL Lists (SLs) (i.e., a stack of MPLS labels) <xref target="RFC9256"
s) format="default"/>. For delay and/or loss measurement for an
(i.e., a stack of MPLS labels) <xref target="RFC9256" format="default"/>. end-to-end SR-MPLS Policy, the query messages <bcp14>MUST</bcp14> be
For delay and/or loss measurement for an end-to-end SR-MPLS Policy, transmitted for every SL of the SR-MPLS Policy Candidate-Path. This
the query messages MUST be transmitted for every SL of the SR-MPLS Policy is done by creating a separate session for each SL. Each query
Candidate-Path, by creating a separate session for each SL. message of a session contains an SR-MPLS label stack of the
Each query message of a session contains an SR-MPLS label stack of the Can Candidate-Path, with the G-ACh Label (GAL) at the bottom of the
didate-Path, stack (with S=1) as shown in <xref
with the G-ACh Label (GAL) at the bottom of the stack (with S=1) as shown target="ure-header-for-an-end-to-end-sr-mpls-policy"/>. In each LSE
in Figure 2. in the MPLS label stack, the TTL value <bcp14>MUST</bcp14> be set to
In each LSE in the MPLS label stack, the TTL value MUST be set to 255 <xre 255 <xref target="RFC5082" format="default"/>.</t>
f target="RFC5082" format="default"/>.
</t>
<figure anchor="ure-header-for-an-end-to-end-sr-mpls-policy"> <figure anchor="ure-header-for-an-end-to-end-sr-mpls-policy">
<name>Example Query Message Header for an End-to-end SR-MPLS Policy< /name> <name>Example Query Message Header for an End-to-End SR-MPLS Policy< /name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t> <t>The fields 0001, Version, Reserved, and Channel Type shown in
The fields "0001", Version, Reserved, and Channel Type shown in Figure 2 are spe <xref target="ure-header-for-an-end-to-end-sr-mpls-policy"/> are
cified in <xref target="RFC5586" format="default"/>. specified in <xref target="RFC5586" format="default"/>.</t>
</t>
<t> <t>The SR-MPLS label stack can be empty in the case of a one-hop
The SR-MPLS label stack can be empty in the case of a one-hop SR-MPLS Policy wit SR-MPLS Policy with an Implicit NULL label.</t>
h an Implicit NULL label.
</t>
<t> <t>For an SR-MPLS Policy, to ensure that the query message is
For an SR-MPLS Policy, to ensure that the query message is processed by the inte processed by the intended responder, the Destination Address TLV
nded responder, the Destination Address TLV (Type 129) <xref target="RFC6374" fo (Type 129) <xref target="RFC6374" format="default"/> containing an
rmat="default"/> containing an address of the responder can be sent in the query address of the responder can be sent in the query messages. The
messages. The responder that supports this TLV MUST return Success in "Control responder that supports this TLV <bcp14>MUST</bcp14> return Control Cod
Code" <xref target="RFC6374" format="default"/> if it is the intended destinatio e 0x1 (Success) <xref target="RFC6374" format="default"/> if it is
n for the query. Otherwise, it MUST return 0x15: Error - Invalid Destination Nod the intended destination for the query. Otherwise, it
e Identifier <xref target="RFC6374" format="default"/>. <bcp14>MUST</bcp14> return Error 0x15: Invalid Destination Node
</t> Identifier <xref target="RFC6374" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="sect-4.2" numbered="true" toc="default"> <section anchor="sect-4.2" numbered="true" toc="default">
<name>Response Message for Links and SR-MPLS Policies</name> <name>Response Message for Links and SR-MPLS Policies</name>
<section anchor="sect-4.2.1" numbered="true" toc="default"> <section anchor="sect-4.2.1" numbered="true" toc="default">
<name>One-way Measurement Mode</name> <name>One-Way Measurement Mode</name>
<t> <!-- [rfced] May we update "out-of-band response messages" to "Out-of-Band Respo
In one-way measurement mode defined in Section 2.4 of <xref target="RFC6374" for nse Requested messages..."? It is unclear whether the text refers to the Respon
mat="default"/>, the querier can receive "out-of-band" response messages with an se Requested messages or res ponses to Out-of-Band Response Requested messages.
IP/UDP header by properly setting the UDP Return Object (URO) TLV in the query
message. The URO TLV (Type=131) is defined in <xref target="RFC7876" format="def Original:
ault"/> and includes the UDP-Destination-Port and IP Address. When the querier s In one-way measurement mode defined in Section 2.4 of [RFC6374], the
ets an IP address and a UDP port in the URO TLV, the response message MUST be se querier can receive "out-of-band" response messages with an IP/UDP
nt to that IP address as the destination address and UDP port as the destination header by properly setting the UDP Return Object (URO) TLV in the
port. In addition, the "Control Code" in the query message MUST be set to "out- query message.
of-band response requested" <xref target="RFC6374" format="default"/>. -->
</t>
<t>In the one-way measurement mode defined in <xref target="RFC6374"
sectionFormat="of" section="2.4"/>, the querier can receive response me
ssages with an IP/UDP header "out-of-band" by properly
setting the UDP Return Object (URO) TLV in the query message. The
URO TLV (Type 131) is defined in <xref target="RFC7876"
format="default"/> 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 <bcp14>MUST</bcp14> be sent to that IP address, with
that IP address as the destination address and the UDP port as the destination p
ort. In addition, the Control Code in the query message
<bcp14>MUST</bcp14> be set to Out-of-band Response Requested <xref
target="RFC6374" format="default"/>.</t>
</section> </section>
<section anchor="sect-4.2.2" numbered="true" toc="default"> <section anchor="sect-4.2.2" numbered="true" toc="default">
<name>Two-way Measurement Mode</name> <name>Two-Way Measurement Mode</name>
<t>
In two-way measurement mode defined in Section 2.4 of <xref target="RFC6374" for
mat="default"/>, the response messages SHOULD be sent back in-band on the same l
ink or the same end-to-end SR-MPLS path (same set of links and nodes) in the rev
erse direction to the querier, in order to perform accurate two-way delay measur
ement.
</t>
<t> <t>
For links, the response message as defined in <xref target="RFC6374" format="def In the two-way measurement mode defined in <xref target="RFC6374" sectionForm
ault"/> is sent back on the same incoming link where the query message is receiv at="of" section="2.4"/>, the
ed. In this case, the "Control Code" in the query message MUST be set to "in-ban response messages <bcp14>SHOULD</bcp14> be sent back one of two ways: either
d response requested" <xref target="RFC6374" format="default"/>. they are sent
</t> 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.</t>
<t> <t>For links, the response message as defined in <xref
For end-to-end SR-MPLS paths, the responder transmits the response message (exam target="RFC6374" format="default"/> is sent back on the same
ple as shown in Figure 2) on a specific return SR-MPLS path. The querier can req incoming link where the query message is received. In this case, the
uest in the query message for the responder to send the response message back on Control Code in the query message <bcp14>MUST</bcp14> be set to
a given return path using the MPLS Label Stack sub-TLV in the Return Path TLV d In-band Response Requested <xref target="RFC6374"
efined in this document. format="default"/>.</t>
<t>For end-to-end SR-MPLS paths, the responder transmits the response
message (see the example as shown in <xref
target="ure-header-for-an-end-to-end-sr-mpls-policy"/>) on a specific
return SR-MPLS path. In the query message, the querier can request t
hat the responder send the response message back on a given return path using t
he MPLS Label Stack Sub-TLV in the Return Path TLV defined in this document.
</t> </t>
</section>
</section>
<section anchor="sect-4.2.3" numbered="true" toc="default"> <section anchor="sect-4.2.3" numbered="true" toc="default">
<name>Loopback Measurement Mode</name> <name>Loopback Measurement Mode</name>
<t> <t>The loopback measurement mode defined in <xref target="RFC6374"
The loopback measurement mode defined in Section 2.8 of <xref target="RFC6374" f sectionFormat="of" section="2.8"/> is used to measure round-trip
ormat="default"/> is used to measure round-trip delay for a bidirectional circul delay for a bidirectional circular path <xref target="RFC6374"
ar path <xref target="RFC6374" format="default"/> in SR-MPLS networks. In this m format="default"/> in SR-MPLS networks. In this mode for SR-MPLS,
ode for SR-MPLS, the received query messages are not punted out of the fast path the received query messages are not punted out of the fast path in
in forwarding (i.e., to the slow path or control plane) at the responder. In ot forwarding (i.e., to the slow path or control plane) at the
her words, the responder does not process the payload or generate response messa responder. In other words, the responder does not process the
ges. The loopback function simply returns the received query message to the quer payload or generate response messages. The loopback function simply
ier without responder modifications <xref target="RFC6374" format="default"/>. returns the received query message to the querier without responder
</t> modifications <xref target="RFC6374" format="default"/>.</t>
<t> <t>The loopback mode is done by generating "queries" with the
The loopback mode is done by generating "queries" with the Response flag set to Response flag set to 1 and adding the Loopback Request object (Type
1 and adding the Loopback Request object (Type 3) <xref target="RFC6374" format= 3) <xref target="RFC6374" format="default"/>. In query messages, the
"default"/>. The label stack, as shown in Figure 3, in query messages, carries b label stack, as shown in <xref
oth the forward and reverse path labels in the MPLS header. The GAL is still car target="ure-header-for-an-end-to-end-sr-mpls-policy-in-loopback"/>,
ried at the bottom of the label stack (with S=1). carries both the forward and reverse path labels in the MPLS
</t> header. The GAL is still carried at the bottom of the label stack
(with S=1).</t>
<figure anchor="ure-header-for-an-end-to-end-sr-mpls-policy-in-loopbac k"> <figure anchor="ure-header-for-an-end-to-end-sr-mpls-policy-in-loopbac k">
<name>Example Query Message Header for an End-to-end SR-MPLS Policy in Loopback Measurement Mode</name> <name>Example Query Message Header for an End-to-End SR-MPLS Policy in the Loopback Measurement Mode</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default"> <section anchor="sect-5" numbered="true" toc="default">
<name>Delay and Loss Measurement</name> <name>Delay and Loss Measurement</name>
<section anchor="sect-5.1" numbered="true" toc="default"> <section anchor="sect-5.1" numbered="true" toc="default">
<name>Delay Measurement Message</name> <name>Delay Measurement Message</name>
<t> <!-- [rfced] Please review these similar sentences and let us know if we may
As defined in <xref target="RFC6374" format="default"/>, MPLS Delay Measurement update them for readability.
(DM) query and response messages use the Associated Channel Header (ACH) (value
0x000C for delay measurement) <xref target="RFC6374" format="default"/>, which i More specifically, what does "which" refer to in the examples below? Does it
dentifies the message type and the message payload as defined in Section 3.2 <xr refer to the ACH or the different values in parentheses?
ef target="RFC6374" format="default"/> following the ACH. For delay measurement,
the same ACH value is used for both links and end-to-end SR-MPLS Policies. In addition, we were unable to find "Combined DM+LM" in RFC 6374 as seen in
</t> the third example. Should this be updated to "combined LM/DM message" as used
in RFC 6374?
Original:
As defined in [RFC6374], MPLS Delay Measurement (DM) query and
response messages use the Associated Channel Header (ACH) (value
0x000C for delay measurement) [RFC6374], which identifies the message
type and the message payload as defined in Section 3.2 [RFC6374]
following the ACH.
As defined in [RFC6374], MPLS LM query and response messages use the
Associated Channel Header (ACH) (value 0x000A for direct loss
measurement or value 0x000B for inferred loss measurement), which
identifies the message type and the message payload defined in
Section 3.1 [RFC6374] following the ACH.
As defined in [RFC6374], Combined DM+LM query and response messages
use the Associated Channel Header (ACH) (value 0x000D for direct loss
and delay measurement or value 0x000E for inferred loss and delay
measurement), which identifies the message type and the message
payload defined in Section 3.3 [RFC6374] following the ACH.
Perhaps:
As defined in [RFC6374], MPLS Delay Measurement (DM) query and response
messages use the Associated Channel Header (ACH) (with the value 0x000C for
delay measurement). This value identifies the message type and the
message payload that follow the ACH, as defined in Section 3.2 of [RFC6374].
As defined in [RFC6374], MPLS LM query and response messages use the ACH
(with the value 0x000A for direct loss measurement or the value 0x000B for
inferred loss measurement). This value identifies the message type and the
message payload that follow the ACH, as defined in Section 3.1 of [RFC6374].
As defined in [RFC6374], combined DM+LM query and response messages use the
ACH (with the value 0x000D for direct loss and delay measurement or the
value 0x000E for inferred loss and delay measurement). This value
identifies the message type and the message payload that follows the ACH,
as defined in Section 3.3 of [RFC6374].
-->
<t>As defined in <xref target="RFC6374" format="default"/>, MPLS Delay
Measurement (DM) query and response messages use the Associated Channel
Header (ACH) (with the value 0x000C for delay measurement). This value ident
ifies the message type and message
payload that follow the ACH, as defined in <xref target="RFC6374" sectionFor
mat="of"
section="3.2"/>. For delay measurement, the same ACH
value is used for both links and end-to-end SR-MPLS Policies.</t>
</section> </section>
<section anchor="sect-5.2" numbered="true" toc="default"> <section anchor="sect-5.2" numbered="true" toc="default">
<name>Loss Measurement Message</name> <name>Loss Measurement Message</name>
<t> <t>The Loss Measurement (LM) protocol can perform two distinct kinds of
The Loss Measurement (LM) protocol can perform two distinct kinds of loss measur loss measurement as described in <xref target="RFC6374"
ement as described in Section 2.9.8 of <xref target="RFC6374" format="default"/> sectionFormat="of" section="2.9.8"/>.</t>
.
</t>
<ul spacing="normal"> <ul spacing="normal">
<li>In inferred mode, LM will measure the loss of specially generated test m <li>In the inferred mode, LM will measure the loss of specially generated
essages to infer the approximate data plane loss level. Inferred mode LM provide test messages to infer the approximate data plane loss level. Inferred
s only approximate loss accounting.</li> mode LM provides only approximate loss accounting.</li>
<li>In direct mode, LM will directly measure data plane packet loss. Direct <li>In the direct mode, LM will directly measure data plane packet
mode LM provides perfect loss accounting but may require hardware support.</li> loss. Direct mode LM provides perfect loss accounting but may require
</ul> hardware support.</li>
</ul>
<t> <t>As defined in <xref target="RFC6374" format="default"/>, MPLS LM
As defined in <xref target="RFC6374" format="default"/>, MPLS LM query and respo query and response messages use the ACH (with the value 0x000A for direct
nse messages use the Associated Channel Header (ACH) (value 0x000A for direct lo loss
ss measurement or value 0x000B for inferred loss measurement), which identifies measurement or value 0x000B for inferred loss measurement). This value ide
the message type and the message payload defined in Section 3.1 <xref target="RF ntifies the message type and message payload that follow the ACH, as defined in
C6374" format="default"/> following the ACH. For loss measurement, the same ACH <xref
value is used for both links and end-to-end SR-MPLS Policies. target="RFC6374" sectionFormat="of" section="3.1"/>. For loss measurement,
</t> the same ACH value is used for both links and
end-to-end SR-MPLS Policies.</t>
</section> </section>
<section anchor="sect-5.3" numbered="true" toc="default"> <section anchor="sect-5.3" numbered="true" toc="default">
<name>Combined Loss/Delay Measurement Message</name> <name>Combined Loss/Delay Measurement Message</name>
<t> <t>As defined in <xref target="RFC6374" format="default"/>, combined
As defined in <xref target="RFC6374" format="default"/>, Combined DM+LM query an LM/DM query and response messages use the ACH (with the value 0x000D for
d response messages use the Associated Channel Header (ACH) (value 0x000D for di direct loss and delay measurement or the value 0x000E for inferred loss
rect loss and delay measurement or value 0x000E for inferred loss and delay meas and delay measurement). The value identies the message type and the
urement), which identifies the message type and the message payload defined in S message payload that follows the ACH, as defined in <xref target="RFC6374
ection 3.3 <xref target="RFC6374" format="default"/> following the ACH. For comb " sectionFormat="of"
ined loss and delay measurement, the same ACH value is used for both links and e section="3.3"/>. For combined loss and delay
nd-to-end SR-MPLS Policies. measurement, the same ACH value is used for both links and end-to-end
</t> SR-MPLS Policies.</t>
</section> </section>
<section anchor="sect-5.4" numbered="true" toc="default"> <section anchor="sect-5.4" numbered="true" toc="default">
<name>Counters</name> <name>Counters</name>
<t> <t>The Path Segment Identifier (PSID) <xref target="RFC9545"
The Path Segment Identifier (PSID) <xref target="RFC9545" format="default"/> MUS format="default"/> <bcp14>MUST</bcp14> be carried in the received data
T be carried in the received data packet for the traffic flow under measurement packet for the traffic flow under measurement, in order to account for re
for accounting received traffic on the egress node of the SR-MPLS Policy. In dir ceived
ect mode, the PSID in the received query message, as shown in Figure 4, can be u traffic on the egress node of the SR-MPLS Policy. In the direct mode, the
sed to associate the received traffic counter on the responder to detect the tra PSID in the received query message (as shown in <xref
nsmit packet loss for the end-to-end SR-MPLS Policy. target="ure-with-path-segment-identifier-for-sr-mpls-policy"/>) can be
</t> used to associate the received traffic counter on the responder to
detect the transmit packet loss for the end-to-end SR-MPLS Policy.</t>
<t> <t>In the inferred mode, the PSID in the received query messages (as show
In inferred mode, the PSID in the received query messages, as shown in Figure 4, n
can be used to count the received query messages on the responder to detect the in <xref target="ure-with-path-segment-identifier-for-sr-mpls-policy"/>)
transmit packet loss for an end-to-end SR-MPLS Policy. can be
</t> used to count the received query messages on the responder to detect
the transmit packet loss for an end-to-end SR-MPLS Policy.</t>
<figure anchor="ure-with-path-segment-identifier-for-sr-mpls-policy"> <figure anchor="ure-with-path-segment-identifier-for-sr-mpls-policy">
<name>Example with Path Segment Identifier for SR-MPLS Policy</name> <name>Example with the PSID for SR-MPLS Policy</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<artwork name="" type="" align="left" alt=""><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t> <t>The fields 0001, Version, Reserved, and Channel Type shown in <xref
The fields "0001", Version, Reserved, and Channel Type shown in Figure 4 are spe target="ure-with-path-segment-identifier-for-sr-mpls-policy"/> are
cified in <xref target="RFC5586" format="default"/>. specified in <xref target="RFC5586" format="default"/>.</t>
</t>
<t> <t>Different values of the PSID can be used per Candidate-Path to account fo
Different values of PSID can be used per Candidate-Path for accounting received r
traffic to measure packet loss at the Candidate-Path level. Similarly, different received traffic and to measure packet loss at the Candidate-Path
values of PSID can be used per Segment List of the Candidate-Path for accountin level. Similarly, different values of the PSID can be used per Segment List
g received traffic to measure packet loss at the Segment List level. The same va (SL) of
lue of PSID can be used for all Segment Lists of the SR-MPLS Policy to measure p the Candidate-Path for accounting received traffic to measure packet loss
acket loss at the SR-MPLS Policy level. at the SL level. The same value of the PSID can be used for all
</t> SLs of the SR-MPLS Policy to measure packet loss at the SR-MPLS
Policy level.</t>
</section> </section>
<section anchor="sect-5.5" numbered="true" toc="default"> <section anchor="sect-5.5" numbered="true" toc="default">
<name>Block Number for Counters</name> <name>Block Number for Counters</name>
<t> <t>The packet loss measurement using the Alternate-Marking Method defined
The packet loss measurement using the Alternate-Marking Method defined in <xref in <xref target="RFC9341" format="default"/> may use the block number for
target="RFC9341" format="default"/> may use the block number for data correlatio data correlation for the traffic flow under measurement. As defined in
n for the traffic flow under measurement. As defined in Section 3.1 of <xref tar <xref target="RFC9341" sectionFormat="of" section="3.1"/>, the block
get="RFC9341" format="default"/>, the block number is used to divide the traffic number is used to divide the traffic flow into consecutive blocks and
flow into consecutive blocks and count the number of packets transmitted and re count the number of packets transmitted and received in each block for
ceived in each block for loss measurement. loss measurement.</t>
</t>
<t> <t>As described in <xref target="RFC9341" sectionFormat="of"
As described in Section 4.3 of <xref target="RFC9341" format="default"/>, a prot section="4.3"/>, a protocol-based distributed solution can be used to
ocol-based distributed solution can be used to exchange values of counters on th exchange values of counters on the nodes for loss measurement. That
e nodes for loss measurement. That solution is further described in this documen solution is further described in this document using the LM messages
t using the LM messages defined in <xref target="RFC6374" format="default"/>. defined in <xref target="RFC6374" format="default"/>.</t>
</t>
<t> <t>The querier node assigns a block number to the block of data packets of
The querier node assigns a block number to the block of data packets of the traf the traffic flow under measurement. The querier counts the number of
fic flow under measurement. The querier counts the number of packets transmitted packets transmitted in each block. The mechanism for the assignment of the
in each block. The mechanism for the assignment of the block number is a local block number is a local decision on the querier and is outside the scope
decision on the querier and is outside the scope of this document. of this document.</t>
</t>
<t> <t>As an example, the querier can use the procedure defined in <xref
As an example, the querier can use the procedure defined in <xref target="I-D.ie target="RFC9714" format="default"/> for
tf-mpls-inband-pm-encapsulation" format="default"/> for alternate marking of the alternate marking of the data packets of the traffic flow under
data packets of the traffic flow under measurement. The responder counts the nu measurement. The responder counts the number of received packets in each
mber of received packets in each block based on the marking in the received data block based on the marking in the received data packets. The querier and
packets. The querier and responder maintain separate sets of transmit and recei responder maintain separate sets of transmit and receive counters for each
ve counters for each marking. The marking can be used as a block number or a sep marking. The marking can be used as a block number, or a separate block
arate block number can be incremented when the marking changes. Other methods ca number can be incremented when the marking changes. Other methods can be
n be defined for alternate marking of the data packets of the traffic flow under defined for alternate marking of the data packets of the traffic flow
measurement to assign a block number for the counters. under measurement to assign a block number for the counters.</t>
</t>
<t> <t>The LM query and response messages defined in <xref target="RFC6374"
The LM query and response messages defined in <xref target="RFC6374" format="def format="default"/> are used to measure packet loss for the block of data
ault"/> are used to measure packet loss for the block of data packets transmitte packets transmitted with the previous marking, whereas data packets carry
d with the previous marking while data packets carry alternate marking. Specific alternate marking. Specifically, LM query and response messages carry the
ally, LM query and response messages carry the transmit and receive counters (wh transmit and receive counters (which are currently not incrementing) along
ich are currently not incrementing) along with their block number to correlate f with their block number to correlate for loss measurement.</t>
or loss measurement.
</t>
<t> <t><xref target="RFC9341" sectionFormat="of" section="4.3"/> specifies that:
"The assumption of the block number mechanism is that "The assumption of this BN mechanism is that the measurement nodes are time
the measurement nodes are time synchronized" as specified in Section 4.3 of <xre synchronized." However, this is not necessary, as the block number on the
f target="RFC9341" format="default"/> is not necessary, as the block number on t responder can be synchronized based on the received LM query messages.</t>
he responder can be synchronized based on the received LM query messages.
</t>
</section> </section>
</section> </section>
<section anchor="sect-6" numbered="true" toc="default"> <section anchor="sect-6" numbered="true" toc="default">
<name>TLV Extensions</name> <name>TLV Extensions</name>
<section anchor="sect-6.1" numbered="true" toc="default"> <section anchor="sect-6.1" numbered="true" toc="default">
<name>Return Path TLV Extension</name> <name>Return Path TLV Extension</name>
<t> <t>In the two-way measurement mode, the responder may transmit the
In two-way measurement mode, the responder may transmit the response message on response message on a specific return path, for example, in an ECMP
a specific return path, for example, in an ECMP environment. The querier can req environment. The querier can request in the query message for the
uest in the query message for the responder to send a response message back on a responder to send a response message back on a given return path
given return path (e.g., co-routed bidirectional path). This allows the respond (e.g., a co-routed bidirectional path). This allows the responder to
er to avoid creating and maintaining additional states (containing return paths) avoid creating and maintaining additional states (containing return
for the sessions. paths) for the sessions.</t>
</t>
<t> <t>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 q network. In this case, the querier <bcp14>MUST</bcp14> send its
uerier in this case MUST send its reachability path information to the responder reachability path information to the responder using the Return Path
using the Return Path TLV. TLV.</t>
</t>
<t> <t><xref target="RFC6374" format="default"/> defines query and
<xref target="RFC6374" format="default"/> defines query and response messages th response messages that can include one or more optional TLVs. This docume
at can include one or more optional TLVs. A new TLV Type (TBA1) is defined in th nt defines the the Return Path TLV (5) to
is document for the Return Path TLV to carry return path information in query me carry return path information in query messages. The Return Path TLV
ssages. The Return Path TLV is specific to a measurement session. The format of is specific to a measurement session. The format of the Return Path
the Return Path TLV is shown in Figure 5: TLV is shown in <xref target="ure-return-path-tlv"/> below:</t>
</t>
<figure anchor="ure-return-path-tlv"> <figure anchor="ure-return-path-tlv">
<name>Return Path TLV</name> <name>Return Path TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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 |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t> <t>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 Return Path Sub-TLV and the Reserved field in bytes. The Length
-TLV and the Reserved field in bytes. Length MUST NOT be 0 or 1. <bcp14>MUST NOT</bcp14> be 0 or 1.</t>
</t>
<t> <t>The Return Path TLV is defined in the "Mandatory TLV Type"
The Return Path TLV is defined in the Mandatory TLV Type registry space <xref ta registry space <xref target="RFC6374" format="default"/>. The
rget="RFC6374" format="default"/>. The querier MUST only insert one Return Path querier <bcp14>MUST</bcp14> only insert one Return Path TLV in the
TLV in the query message. The responder that supports this TLV MUST only process query message. The responder that supports this TLV
the first Return Path TLV and ignore the other Return Path TLVs if present. The <bcp14>MUST</bcp14> only process the first Return Path TLV and
responder that supports this TLV also MUST send the response message back on th ignore the other Return Path TLVs if present. The responder that
e return path specified in the Return Path TLV. The responder also MUST NOT add supports this TLV also <bcp14>MUST</bcp14> send the response message
a Return Path TLV in the response message. The Reserved field MUST be set to 0 a back on the return path specified in the Return Path TLV. The
nd MUST be ignored on the receive side. responder also <bcp14>MUST NOT</bcp14> add a Return Path TLV in the
</t> response message.</t>
<t>The Reserved field <bcp14>MUST</bcp14> be set to 0 and
<bcp14>MUST</bcp14> be ignored on the receive side.</t>
<section anchor="sect-6.1.1" numbered="true" toc="default"> <section anchor="sect-6.1.1" numbered="true" toc="default">
<name>Return Path Sub-TLV Extension</name> <name>Return Path Sub-TLV Extension</name>
<t> <t>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 t format of the MPLS Label Stack Sub-TLV is shown in <xref
he MPLS Label Stack Sub-TLV is shown in Figure 6. The label entries in the Sub-T target="ure-segment-list-sub-tlv-in-return-path-tlv"/>. The label
LV MUST be in network order. The MPLS Label Stack Sub-TLV in the Return Path TLV entries in the Sub-TLV <bcp14>MUST</bcp14> be in network order. The MPLS
is of the following type: Label Stack Sub-TLV in the Return Path TLV is of the following type:</t>
</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Type (value 1): MPLS Label Stack of the Return Path</li> <li>Type (value 1): MPLS Label Stack of the Return Path</li>
</ul> </ul>
<figure anchor="ure-segment-list-sub-tlv-in-return-path-tlv"> <figure anchor="ure-segment-list-sub-tlv-in-return-path-tlv">
<name>MPLS Label Stack Sub-TLV in Return Path TLV</name> <name>MPLS Label Stack Sub-TLV in the Return Path TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t> <t>The MPLS label stack contains a list of 32-bit LSEs that includes
The MPLS Label Stack contains a list of 32-bit LSE that includes a 20-bit label a 20-bit label value, an 8-bit TTL value, a 3-bit TC value, and a 1-bit
value, 8-bit TTL value, 3-bit TC value, and 1-bit EOS (S) field. An MPLS Label S End of Stack (S) field. An MPLS Label Stack Sub-TLV may carry a stack of labels
tack Sub-TLV may carry a stack of labels or a Binding SID label <xref target="RF or a Binding SID label <xref target="RFC8402" format="default"/> of
C8402" format="default"/> of the Return SR-MPLS Policy. the Return SR-MPLS Policy.</t>
</t>
<t> <t>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 fie label stack field and the Reserved field in bytes. The Length
ld and the Reserved field in bytes. Length MUST NOT be 0 or 1. <bcp14>MUST NOT</bcp14> be 0 or 1.</t>
</t>
<t> <t>The Return Path TLV <bcp14>MUST</bcp14> carry only one Return
The Return Path TLV MUST carry only one Return Path Sub-TLV. The MPLS Label Path Sub-TLV. The MPLS Label Stack in the Return Path Sub-TLV
Stack in the Return Path Sub-TLV MUST contain at least one MPLS Label. The respo <bcp14>MUST</bcp14> contain at least one MPLS Label. The responder
nder that supports this Sub-TLV MUST only process the first Return Path Sub-TLV that supports this Sub-TLV <bcp14>MUST</bcp14> only process the
and ignore the other Return Path Sub-TLVs if present. The responder that support first Return Path Sub-TLV and ignore the other Return Path Sub-TLVs
s this Sub-TLV MUST send the response message back on the return path specified if present. The responder that supports this Sub-TLV
in the Return Path Sub-TLV. <bcp14>MUST</bcp14> send the response message back on the return
</t> path specified in the Return Path Sub-TLV.</t>
<t> <t>The Reserved field <bcp14>MUST</bcp14> be set to 0 and
The Reserved field MUST be set to 0 and MUST be ignored on the receive side. <bcp14>MUST</bcp14> be ignored on the receive side.</t>
</t>
</section> </section>
</section> </section>
<section anchor="sect-6.2" numbered="true" toc="default"> <section anchor="sect-6.2" numbered="true" toc="default">
<name>Block Number TLV Extension</name> <name>Block Number TLV Extension</name>
<t> <t><xref target="RFC6374" format="default"/> defines query and
<xref target="RFC6374" format="default"/> defines query and response messages th response messages that can include one or more optional TLVs. This docume
at can include one or more optional TLVs. A new TLV Type (value TBA2) is defined nt defines the Block Number TLV (6) to carry (8-bit) Block Number of
in this document to carry the Block Number (8-bit) of the traffic counters in t the traffic counters in the LM query and response
he LM query and response messages. The format of the Block Number TLV is shown i messages. The format of the Block Number TLV is shown in <xref
n Figure 7: target="ure-block-number-tlv"/>:</t>
</t>
<figure anchor="ure-block-number-tlv"> <figure anchor="ure-block-number-tlv">
<name>Block Number TLV</name> <name>Block Number TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t> <t>The Length is a one-byte field and is equal to 2 bytes.</t>
The Length is a one-byte field and is equal to 2 bytes.
</t>
<t> <t>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 <xr space <xref target="RFC6374" format="default"/>. The querier
ef target="RFC6374" format="default"/>. <bcp14>MUST</bcp14> only insert one Block Number TLV in the query
The querier MUST only insert one Block Number TLV in the query message to id message to identify the Block Number for the traffic counters in the
entify the Block Number for forward direction. The responder that supports this TLV
the traffic counters in the forward direction. The responder that supports t <bcp14>MUST</bcp14> only insert one Block Number TLV in the response
his TLV MUST only insert one message to identify the Block Number for the traffic counters in the
Block Number TLV in the response message to identify the Block Number for th reverse direction. The responder also <bcp14>MUST</bcp14> return the
e traffic counters in the reverse direction. first Block Number TLV from the query message and ignore the other
The responder also MUST return the first Block Number TLV from the query mes Block Number TLVs if present. The Block Number TLV is specific to a
sage and ignore the other Block Number TLVs if present. measurement session. The R flag is used to indicate the query and
The Block Number TLV is specific to a measurement session. response message direction associated with the Block Number. The R
The R flag is used to indicate the query and response message direction asso flag <bcp14>MUST</bcp14> be clear in the query message for the Block
ciated with the Block Number. Number associated with Counter 1 and Counter 2, and set in the
The R flag MUST be clear in the query message for the Block Number associate response message for the Block Number associated with Counter 3 and
d with Counter 1 and Counter 2, Counter 4.</t>
and set in the response message for the Block Number associated with Counter
3 and Counter 4.
</t>
<t> <t>The Reserved field <bcp14>MUST</bcp14> be set to 0 and
The Reserved field MUST be set to 0 and MUST be ignored on the receive side. <bcp14>MUST</bcp14> be ignored on the receive side.</t>
</t>
</section> </section>
</section> </section>
<section anchor="sect-7" numbered="true" toc="default"> <section anchor="sect-7" numbered="true" toc="default">
<name>ECMP for SR-MPLS Policies</name> <name>ECMP for SR-MPLS Policies</name>
<t> <t>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 transit nodes, between transit nodes, and between transit and
, between transit nodes, and between transit and destination nodes. Usage of nod destination nodes. Usage of a node-SID <xref target="RFC8402"
e SID <xref target="RFC8402" format="default"/> by the SLs of an SR-MPLS Policy format="default"/> by the SLs of an SR-MPLS Policy can result in ECMP
can result in ECMP paths. In addition, usage of Anycast SID <xref target="RFC840 paths. In addition, usage of an Anycast-SID <xref target="RFC8402"
2" format="default"/> by the SLs of an SR-MPLS Policy can result in ECMP paths v format="default"/> by the SLs of an SR-MPLS Policy can result in ECMP
ia transit nodes that are part of that Anycast group. The query and response mes paths via transit nodes that are part of that anycast group. The query
sages are sent to traverse different ECMP paths to measure the delay of each ECM and response messages are sent to traverse different ECMP paths to
P path of an SL. measure the delay of each ECMP path of an SL.</t>
</t>
<t>
The forwarding plane has various hashing functions available to forward packets
on specific ECMP paths. For end-to-end SR-MPLS Policy delay measurement, differe
nt entropy label <xref target="RFC6790" format="default"/> values can be used in
query and response messages to take advantage of the hashing function in the fo
rwarding plane to influence the ECMP path taken by them.
</t>
<t> <t>The forwarding plane has various hashing functions available to
The considerations for loss measurement for different ECMP paths of an SR-MPLS P forward packets on specific ECMP paths. For end-to-end SR-MPLS Policy
olicy are outside the scope of this document. delay measurement, different entropy label values <xref target="RFC6790"
</t> format="default"/> 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.</t>
<t>The considerations for loss measurement for different ECMP paths of
an SR-MPLS Policy are outside the scope of this document.</t>
</section> </section>
<section anchor="sect-8" numbered="true" toc="default"> <section anchor="sect-8" numbered="true" toc="default">
<name>Extended TE Link Metrics Advertisements</name> <name>Extended TE Link Metrics Advertisement</name>
<t> <t>The extended TE metrics for link delay (namely, average delay,
The extended TE metrics for link delay (namely, average delay, minimum delay, ma minimum delay, maximum delay, and delay-variance) and packet loss can be
ximum delay and delay-variance) and packet loss can be computed using the perfor computed using the performance measurement procedures described in this
mance measurement procedures described in this document and advertised in the ro document and can be advertised in the routing domain as follows:</t>
uting domain as follows:
</t>
<ul spacing="normal"> <ul spacing="normal">
<li>For OSPF, IS-IS, and BGP-LS, protocol extensions defined in <xref target <li>For OSPF, IS-IS, and the Border Gateway Protocol - Link State
="RFC7471" format="default"/>, <xref target="RFC8570" format="default"/>, and <x (BGP-LS), the protocol extensions defined in <xref target="RFC7471"
ref target="RFC8571" format="default"/>, respectively, are used for advertising format="default"/>, <xref target="RFC8570" format="default"/>, and
the extended TE link delay and loss metrics in the network.</li> <xref target="RFC8571" format="default"/>, respectively, are used for
<li>The extended TE link delay and loss metrics are advertised for Layer-2 L advertising the extended TE link delay and loss metrics in the
AG bundle member links in OSPF <xref target="RFC9356" format="default"/> and IS- network.</li>
IS <xref target="RFC8668" format="default"/> using the same protocol extensions <li>The extended TE link delay and loss metrics are advertised for
defined in <xref target="RFC7471" format="default"/> and <xref target="RFC8570" Layer-2 LAG bundle member links in OSPF <xref target="RFC9356"
format="default"/>, respectively.</li> format="default"/> and IS-IS <xref target="RFC8668" format="default"/>
<li>The advertised delay-variance metric is computed as Packet Delay Variati using the same protocol extensions defined in <xref target="RFC7471"
on (PDV), as described in Section 4.2 of <xref target="RFC5481" format="default" format="default"/> and <xref target="RFC8570" format="default"/>,
/>.</li> respectively.</li>
</ul> <li>The advertised delay-variance metric is computed as Packet Delay
Variation (PDV), as described in <xref target="RFC5481"
sectionFormat="of" section="4.2"/>.</li>
</ul>
</section> </section>
<section anchor="sect-9" numbered="true" toc="default"> <section anchor="sect-9" numbered="true" toc="default">
<name>Backwards Compatibility</name> <name>Backwards Compatibility</name>
<t> <t>The procedures defined in this document are backwards compatible with
The procedures defined in this document are backwards compatible with the proced the procedures defined in <xref target="RFC6374" format="default"/> at
ures defined in <xref target="RFC6374" format="default"/> at both the querier an both the querier and the responder. If the responder does not support the
d responder. If the responder does not support the new Mandatory TLV Types defin new Mandatory TLV Types defined in this document, it will return Error
ed in this document it will return Error 0x17: Unsupported Mandatory TLV Object 0x17: Unsupported Mandatory TLV Object as per <xref target="RFC6374"
as per <xref target="RFC6374" format="default"/>. format="default"/>.</t>
</t>
</section> </section>
<section anchor="sect-10" numbered="true" toc="default"> <section anchor="sect-10" numbered="true" toc="default">
<name>Manageability Considerations</name> <name>Manageability Considerations</name>
<t> <t>The manageability considerations described in <xref target="RFC6374"
The manageability considerations described in Section 7 of <xref target="RFC6374 sectionFormat="of" section="7"/> and <xref target="RFC7876"
" format="default"/> and Section 6 of <xref target="RFC7876" format="default"/> sectionFormat="of" section="6"/> are applicable to this
are applicable to this specification. specification.</t>
</t>
</section> </section>
<section anchor="sect-11" numbered="true" toc="default"> <section anchor="sect-11" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>The security considerations specified in <xref target="RFC6374"
The security considerations specified in <xref target="RFC6374" format="default" format="default"/>, <xref target="RFC7471" format="default"/>, <xref
/>, <xref target="RFC7471" format="default"/>, <xref target="RFC8570" format="de target="RFC8570" format="default"/>, <xref target="RFC8571"
fault"/>, <xref target="RFC8571" format="default"/>, <xref target="RFC7876" form format="default"/>, <xref target="RFC7876" format="default"/>, and <xref
at="default"/>, and <xref target="RFC9341" format="default"/> also apply to the target="RFC9341" format="default"/> also apply to the procedures
procedures described in this document. described in this document.</t>
</t>
<t> <t>The procedure defined in this document is intended for deployment in
The procedure defined in this document is intended for deployment in a single op a single operator administrative domain. As such, the querier node, the
erator administrative domain. As such, the querier node, responder node, forward responder node, the forward path, and the return paths are provisioned
, and return paths are provisioned by the operator for the probe session. It is by the operator for the probe session. It is assumed that the operator
assumed that the operator has verified the integrity of the forward and return p has verified the integrity of the forward and return paths of the probe
aths of the probe packets. packets.</t>
</t>
<t> <t>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 potent for potential address spoofing. For example, a query message may carry a
ial address spoofing. For example, a query message may carry a return path that return path that has a destination that is not local at the querier. To
has a destination that is not local at the querier. To prevent such possible att prevent such possible attacks, the responder may drop the query messages
acks, the responder may drop the query messages when it cannot determine whether when it cannot determine whether the return path has the destination
the return path has the destination local at the querier. The querier may send local at the querier. The querier may send a proper source address in
a proper source address in the "Source Address" TLV that the responder can use t the Source Address TLV. The responder can use this to make that
o make that determination, for example, by checking the access control list prov determination, for example, by checking the access control list
isioned by the operator. provisioned by the operator.</t>
</t>
</section> </section>
<section anchor="sect-12" numbered="true" toc="default"> <section anchor="sect-12" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to allocate values for the following Mandatory
TLV Types for <xref target="RFC6374" format="default"/> from the "MPLS Loss/D <t>IANA has allocated values for the following Mandatory TLV
elay Measurement TLV Object" Types <xref target="RFC6374" format="default"/> from the "MPLS
registry contained within the "Generic Associated Channel (G-ACh) Parameters" Loss/Delay Measurement TLV Object" registry contained within the
registry set:</t> "Generic Associated Channel (G-ACh) Parameters" registry group:</t>
<table anchor="iana-tlv-type-tbl" align="center"> <table anchor="iana-tlv-type-tbl" align="center">
<name>MPLS Loss/Delay Measurement TLV Types</name> <name>MPLS Loss/Delay Measurement TLV Types</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left">Code</th>
<th align="center">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">TBA1</td> <td align="left">5</td>
<td align="center">Return Path TLV</td> <td align="left">Return Path</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
<tr> <tr>
<td align="left">TBA2</td> <td align="left">6</td>
<td align="center">Block Number TLV</td> <td align="left">Block Number</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>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 Retu and the Return Path TLV is carried in the query messages.</t>
rn Path TLV is carried in the query messages.
</t>
<t> <t>IANA has created the "Return Path Sub-TLV Types" registry.
IANA is requested to create a registry for "Return Path Sub-TLV Type." All code All code points are allocated per the registration policies shown in <xref targe
points in the range 0 through 175 in this registry shall be allocated according t="iana-return-path-tbl"/> (see <xref target="RFC8126"/>).
to the "IETF Review" procedure as specified in <xref target="RFC8126" format="de
fault"/>. Code points in the range 176 through 239 in this registry shall be all
ocated according to the "First Come, First Served" procedure as specified in <xr
ef target="RFC8126" format="default"/>. Remaining code points are allocated acco
rding to <xref target="iana-return-path-tbl" format="default"/>:
</t> </t>
<table anchor="iana-return-path-tbl" align="center"> <table anchor="iana-return-path-tbl" align="center">
<name>Return Path Sub-TLV Type Registry</name> <name>Return Path Sub-TLV Type Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left">Value</th>
<th align="center">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">1 - 175</td> <td align="left">1 - 175</td>
<td align="center">IETF Review</td> <td align="left">IETF Review</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
<tr> <tr>
<td align="left">176 - 239</td> <td align="left">176 - 239</td>
<td align="center">First Come First Served</td> <td align="left">First Come First Served</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
<tr> <tr>
<td align="left">240 - 251</td> <td align="left">240 - 251</td>
<td align="center">Experimental Use</td> <td align="left">Experimental Use</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
<tr> <tr>
<td align="left">252 - 254</td> <td align="left">252 - 254</td>
<td align="center">Private Use</td> <td align="left">Private Use</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>This document defines the following values in the Return Path Sub-TLV T
ype registry:</t> <t>This document defines the following values in the "Return Path Sub-TLV
Type" registry:</t>
<table anchor="iana-return-path-type-tbl" align="center"> <table anchor="iana-return-path-type-tbl" align="center">
<name>Return Path Sub-TLV Types</name> <name>Return Path Sub-TLV Types</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left">Value</th>
<th align="center">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0</td> <td align="left">0</td>
<td align="center">Reserved</td> <td align="left">Reserved</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="center">MPLS Label Stack of the Return Path</td> <td align="left">MPLS Label Stack of the Return Path</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
<tr> <tr>
<td align="left">255</td> <td align="left">255</td>
<td align="center">Reserved</td> <td align="left">Reserved</td>
<td align="left">This document</td> <td align="left">RFC 9779</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
&RFC2119; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.
&RFC6374; xml"/>
&RFC7876; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6374.
&RFC8174; xml"/>
&RFC9341; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7876.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9341.
xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
&RFC3031; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.
&RFC3032; xml"/>
&RFC5082; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3032.
&RFC5481; xml"/>
&RFC5586; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5082.
&RFC6790; xml"/>
&RFC7471; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5481.
&RFC8126; xml"/>
&RFC8402; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5586.
&RFC8570; xml"/>
&RFC8571; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6790.
&RFC8668; xml"/>
&RFC9256; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7471.
&RFC9356; xml"/>
&RFC9545; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8570.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8571.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8668.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9356.
xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9545.
xml"/>
&I-D.ietf-mpls-inband-pm-encapsulation; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9714.xml" />;
<reference anchor="IEEE802.1AX"> <reference anchor="IEEE802.1AX">
<front> <front>
<title>IEEE Standard for Local and metropolitan area networks - Link Aggregation</title> <title>IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation</title>
<author> <author>
<organization> <organization>IEEE</organization>
IEEE Std. 802.1AX
</organization>
</author> </author>
<date month="November" year="2008"/> <date month="May" year="2020"/>
</front> </front>
<seriesInfo name="IEEE" value="Std 802.1AX-2020"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9105034"/>
</reference> </reference>
</references> </references>
</references> </references>
<section numbered="false" anchor="acknowledgments" toc="default"> <section numbered="false" anchor="acknowledgments" toc="default">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t> <t>The authors would like to thank <contact fullname="Thierry Couture"/>
The authors would like to thank Thierry Couture and Ianik Semco for the discussi and <contact fullname="Ianik Semco"/> for the discussions on the use
ons on the use cases for performance measurement in segment routing networks. Th cases for performance measurement in segment routing networks. The
e authors would like to thank Patrick Khordoc, Ruby Lin, and Haowei Shi for impl authors would like to thank <contact fullname="Patrick Khordoc"/>,
ementing the mechanisms defined in this document. The authors would like to than <contact fullname="Ruby Lin"/>, and <contact fullname="Haowei Shi"/> for
k Greg Mirsky and Xiao Min for providing many useful comments and suggestions. T implementing the mechanisms defined in this document. The authors would
he authors would also like to thank Stewart Bryant, Sam Aldrin, Tarek Saad, and like to thank <contact fullname="Greg Mirsky"/> and <contact
Rajiv Asati for their review comments. Thanks to Huaimo Chen, Yimin Shen, and Xu fullname="Xiao Min"/> for providing many useful comments and
feng Liu for MPLS-RT expert review, Zhaohui Zhang for RTGDIR early review, Tony suggestions. The authors would also like to thank <contact
Li for shepherd's review, Ned Smith for SECDIR review, Roni Even for Gen-ART rev fullname="Stewart Bryant"/>, <contact fullname="Sam Aldrin"/>, <contact
iew, Marcus Ihlar for TSV-ART review, Dhruv Dhody for OPSDIR review, Gunter Van fullname="Tarek Saad"/>, and <contact fullname="Rajiv Asati"/> for their
de Velde, Paul Wouters, Eric Vyncke, Murray Kucherawy, John Scudder, and Roman D review comments. Thanks to <contact fullname="Huaimo Chen"/>,
anyliw for IESG review. <contact fullname="Yimin Shen"/>, and <contact fullname="Xufeng Liu"/>
</t> for the MPLS expert review; <contact fullname="Zhaohui Zhang"/> for
the RTGDIR early review; <contact fullname="Tony Li"/> for shepherd's
review; <contact fullname="Ned Smith"/> for the SECDIR review; <contact
fullname="Roni Even"/> for the Gen-ART review; <contact fullname="Marcus
Ihlar"/> for the TSV-ART review; <contact fullname="Dhruv Dhody"/> for
the OPSDIR review; and <contact fullname="Gunter Van de Velde"/>,
<contact fullname="Paul Wouters"/>, <contact fullname="Éric Vyncke"/>,
<contact fullname="Murray Kucherawy"/>, <contact fullname="John
Scudder"/>, and <contact fullname="Roman Danyliw"/> for the IESG
review.</t>
</section> </section>
<section numbered="false" anchor="contributors" toc="default"> <section numbered="false" anchor="contributors" toc="default">
<name>Contributors</name> <name>Contributors</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Sagar Soni
Cisco Systems, Inc.
Email: sagsoni@cisco.com
Zafar Ali <contact fullname="Sagar Soni">
Cisco Systems, Inc. <organization>Cisco Systems, Inc.</organization>
Email: zali@cisco.com <address>
<email>sagsoni@cisco.com</email>
</address>
</contact>
<contact fullname="Zafar Ali">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>zali@cisco.com</email>
</address>
</contact>
<contact fullname="Pier Luigi Ventre">
<organization>CNIT</organization>
<address>
<postal>
<country>Italy</country>
</postal>
<email>pierluigi.ventre@cnit.it</email>
</address>
</contact>
Pier Luigi Ventre
CNIT
Italy
Email: pierluigi.ventre@cnit.it
]]></artwork>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 136 change blocks. 
779 lines changed or deleted 789 lines changed or added

This html diff was produced by rfcdiff 1.48.