Diff: rfc9779.original.xml

	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 " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	<!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>Cisco Systems, Inc.</organization>
	<address>	<address>

	<email>daniel.voyer@bell.ca</email>	<postal><country>Canada</country></postal>
		<email>davoyer@cisco.com</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="May" 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 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>	<t>In one-way measurement mode, as defined in <xref target="RFC6374" se
	In one-way measurement mode defined in Section 2.4 of <xref target="RFC6374" for	ctionFormat="of" section="2.4"/>, the querier can set the UDP Return Object (URO
	mat="default"/>, the querier can receive "out-of-band" response messages with an	) TLV in the query
	IP/UDP header by properly setting the UDP Return Object (URO) TLV in the query	message. This enables the querier to receive the out-of-band response
	message. The URO TLV (Type=131) is defined in <xref target="RFC7876" format="def	message encapsulated in an IP/UDP header sent to the IP address and
	ault"/> and includes the UDP-Destination-Port and IP Address. When the querier s	UDP port specified in the URO TLV. The
	ets an IP address and a UDP port in the URO TLV, the response message MUST be se	URO TLV (Type 131) is defined in <xref target="RFC7876"
	nt to that IP address as the destination address and UDP port as the destination	format="default"/> and includes the UDP-Destination-Port and IP
	port. In addition, the "Control Code" in the query message MUST be set to "out-	address. When the querier sets an IP address and a UDP port in the URO
	of-band response requested" <xref target="RFC6374" format="default"/>.	TLV, the response message <bcp14>MUST</bcp14> be sent to that IP address, with
	</t>	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 d
		elay 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>	<t>As defined in <xref target="RFC6374" format="default"/>, MPLS Delay
	As defined in <xref target="RFC6374" format="default"/>, MPLS Delay Measurement	Measurement (DM) query and response messages use the Associated Channel
	(DM) query and response messages use the Associated Channel Header (ACH) (value	Header (ACH) (with value 0x000C for delay measurement). The value identifies
	0x000C for delay measurement) <xref target="RFC6374" format="default"/>, which i	the message type and message
	dentifies the message type and the message payload as defined in Section 3.2 <xr	payload that follow the ACH, as defined in <xref target="RFC6374" sectionFor
	ef target="RFC6374" format="default"/> following the ACH. For delay measurement,	mat="of"
	the same ACH value is used for both links and end-to-end SR-MPLS Policies.	section="3.2"/>. For delay measurement, the same ACH
	</t>	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 value 0x000A for direct loss
	nse messages use the Associated Channel Header (ACH) (value 0x000A for direct lo	measurement or value 0x000B for inferred loss measurement). This value ide
	ss measurement or value 0x000B for inferred loss measurement), which identifies	ntifies the message type and message payload that follow the ACH, as defined in
	the message type and the message payload defined in Section 3.1 <xref target="RF	<xref
	C6374" format="default"/> following the ACH. For loss measurement, the same ACH	target="RFC6374" sectionFormat="of" section="3.1"/>. For loss measurement,
	value is used for both links and end-to-end SR-MPLS Policies.	the same ACH value is used for both links and
	</t>	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 value 0x000D for
	d response messages use the Associated Channel Header (ACH) (value 0x000D for di	direct loss and delay measurement or value 0x000E for inferred loss
	rect loss and delay measurement or value 0x000E for inferred loss and delay meas	and delay measurement). The value identifies 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. 138 change blocks.
	781 lines changed or deleted	734 lines changed or added
This html diff was produced by rfcdiff 1.48.