rfc9503.original.xml   rfc9503.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;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="d
raft-ietf-ippm-stamp-srpm-18" category="std" ipr="trust200902" consensus="yes" o <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
bsoletes="" updates="" xml:lang="en" sortRefs="false" symRefs="true" tocInclude= std" consensus="yes" docName="draft-ietf-ippm-stamp-srpm-18" number="9503" ipr="
"true" version="3"> trust200902" obsoletes="" updates="" xml:lang="en" sortRefs="true" symRefs="true
" tocInclude="true" version="3">
<!-- xml2rfc v2v3 conversion 3.12.0 --> <!-- xml2rfc v2v3 conversion 3.12.0 -->
<!-- Generated by id2xml 1.5.0 on 2020-02-06T01:41:26Z --> <!-- Generated by id2xml 1.5.0 on 2020-02-06T01:41:26Z -->
<front> <front>
<title abbrev="Simple TWAMP Extensions for SR Networks">Simple TWAMP (STAMP) <title abbrev="STAMP Extensions for SR Networks">Simple Two-Way Active Measu
Extensions for Segment Routing Networks</title> rement Protocol (STAMP) Extensions for Segment Routing Networks</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-ippm-stamp-srpm-18"/> <seriesInfo name="RFC" value="9503"/>
<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>
skipping to change at line 47 skipping to change at line 49
<address> <address>
<email>Bart.Janssens@colt.net</email> <email>Bart.Janssens@colt.net</email>
</address> </address>
</author> </author>
<author fullname="Richard Foote" initials="R." surname="Foote"> <author fullname="Richard Foote" initials="R." surname="Foote">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<email>footer.foote@nokia.com</email> <email>footer.foote@nokia.com</email>
</address> </address>
</author> </author>
<date day="04" month="August" year="2023"/> <date month="October" year="2023"/>
<workgroup>IPPM Working Group</workgroup> <area>tsv</area>
<workgroup>ippm</workgroup>
<abstract> <abstract>
<t> <t>
Segment Routing (SR) leverages the source routing paradigm. SR is Segment Routing (SR) leverages the source routing paradigm. SR is
applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6
(SRv6) forwarding planes. This document specifies RFC 8762 (SRv6) forwarding planes. This document specifies Simple Two-Way Active Measu
(Simple Two-Way Active Measurement Protocol (STAMP)) rement Protocol (STAMP)
extensions for SR networks, for both SR-MPLS and SRv6 forwarding extensions (as described in RFC 8762) for SR networks, for both the SR-MPLS a
planes by augmenting the optional extensions defined in RFC 8972.</t> nd SRv6 forwarding
planes, by augmenting the optional extensions defined in RFC 8972.</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) leverages the source routing paradigm Segment Routing (SR) leverages the source routing paradigm
for Software Defined Networks for Software-Defined Networks
(SDNs). SR is applicable to both Multiprotocol Label Switching (SDNs). SR is applicable to both Multiprotocol Label Switching
(SR-MPLS) and IPv6 (SRv6) forwarding planes <xref target="RFC8402" format="de fault"/>. (SR-MPLS) and IPv6 (SRv6) forwarding planes <xref target="RFC8402" format="de fault"/>.
SR Policies as defined in <xref target="RFC9256" format="default"/> are used SR Policies as defined in <xref target="RFC9256" format="default"/> are used
to steer traffic through a specific, user-defined paths using a stack of Segm ents. to steer traffic through specific, user-defined paths using a stack of Segmen ts.
A comprehensive SR Performance Measurement (PM) toolset is one of the A comprehensive SR Performance Measurement (PM) toolset is one of the
essential requirements to measure network performance to provide Service Leve l Agreements (SLAs).</t> essential requirements to measure network performance to provide Service Leve l Agreements (SLAs).</t>
<t>The Simple Two-Way Active Measurement Protocol (STAMP) provides <t>The Simple Two-Way Active Measurement Protocol (STAMP) provides
capabilities for the measurement of various performance capabilities for the measurement of various performance
metrics in IP networks <xref target="RFC8762" format="default"/> metrics in IP networks <xref target="RFC8762" format="default"/>
without the use of a control channel to pre-signal session parameters. without the use of a control channel to pre-signal session parameters.
<xref target="RFC8972" format="default"/> defines optional extensions, in the form of TLVs, for STAMP. <xref target="RFC8972" format="default"/> defines optional extensions, in the form of TLVs, for STAMP.
Note that the YANG data model defined in <xref target="I-D.ietf-ippm-stamp-ya ng" format="default"/> Note that the YANG data model defined in <xref target="I-D.ietf-ippm-stamp-ya ng" format="default"/>
can be used to provision the STAMP Session-Sender and STAMP Session-Reflector .</t> can be used to provision the STAMP Session-Sender and STAMP Session-Reflector .</t>
<t>The STAMP test packets are transmitted along an IP path between a Sessi on-Sender <t>STAMP test packets are transmitted along an IP path between a Session-S ender
and a Session-Reflector to measure performance delay and packet loss along th at IP path. and a Session-Reflector to measure performance delay and packet loss along th at IP path.
It may be desired in SR networks that the same path (same set of links and no In SR networks, it may be desired that the same path (same set of links and n
des) between the odes) between the
Session-Sender and Session-Reflector is used for the STAMP test packets in bo Session-Sender and Session-Reflector be used for the STAMP test packets in bo
th directions. th directions.
This is achieved by using the STAMP <xref target="RFC8762" format="default"/> extensions for This is achieved by using the STAMP <xref target="RFC8762" format="default"/> extensions for
SR-MPLS and SRv6 networks specified in this document by augmenting SR-MPLS and SRv6 networks as specified in this document by augmenting
the optional extensions defined in <xref target="RFC8972" format="default"/>. </t> the optional extensions defined in <xref target="RFC8972" format="default"/>. </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>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="
RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be 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> <dl spacing="normal">
MPLS: Multiprotocol Label Switching.</t> <dt>MPLS:</dt><dd> Multiprotocol Label Switching</dd>
<t> <dt>SID:</dt><dd> Segment Identifier</dd>
SID: Segment Identifier.</t> <dt>SR:</dt><dd> Segment Routing</dd>
<t> <dt>SR-MPLS:</dt><dd> Segment Routing over MPLS</dd>
SR: Segment Routing.</t> <dt>SRv6:</dt><dd> Segment Routing over IPv6</dd>
<t> <dt>SSID:</dt><dd> STAMP Session Identifier</dd>
SR-MPLS: Segment Routing with MPLS forwarding plane.</t> <dt>STAMP:</dt><dd> Simple Two-Way Active Measurement Protocol</dd>
<t> </dl>
SRv6: Segment Routing with IPv6 forwarding plane.</t>
<t>
SSID: STAMP Session Identifier.</t>
<t>
STAMP: Simple Two-Way Active Measurement Protocol.</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 below, the STAMP Session-Sender S1 initiates a In the reference topology shown below, the STAMP Session-Sender S1 initiates a
STAMP test packet and the STAMP Session-Reflector R1 STAMP test packet and the STAMP Session-Reflector R1
transmits a reply STAMP test packet. The reply test packet may be transmitte transmits a reply STAMP test packet.
d The reply test packet may be transmitted
to the Session-Sender S1 on the same path (same set of links and nodes) or a different path to the Session-Sender S1 on the same path (same set of links and nodes) or a different path
in the reverse direction from the path taken towards the Session-Reflector R1 . in the reverse direction from the path taken towards the Session-Reflector R1 .
The T1 is a transmit timestamp and T4 is a receive timestamp added by node S1 </t><t>
in the STAMP test packet.
The T2 is a receive timestamp and T3 is a transmit timestamp added by node R1 T1 is a transmit timestamp, and T4 is a receive timestamp added by node S1.
in the STAMP test packet. T2 is a receive timestamp, and T3 is a transmit timestamp added by node R1.
</t> </t>
<t>The nodes S1 and R1 may be <t>The nodes S1 and R1 may be
connected via a link or an SR path <xref target="RFC8402" format="default"/>. connected via a link or an SR path <xref target="RFC8402" format="default"/>.
The link may be a physical interface, virtual link, The link may be a physical interface, virtual link,
or Link Aggregation Group (LAG) <xref target="IEEE802.1AX" format="default"/> , or LAG member. Link Aggregation Group (LAG) <xref target="IEEE802.1AX" format="default"/>, o r LAG member.
The SR path may be an SR Policy <xref target="RFC9256" format="default"/> The SR path may be an SR Policy <xref target="RFC9256" format="default"/>
on node S1 (called head-end) with destination to node R1 (called tail-end).</ t> on node S1 (called "head-end") with a destination to node R1 (called "tai l-end").</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <figure anchor="Figure_Reference_Topology">
<name>Reference Topology</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
T1 T2 T1 T2
/ \ / \
+-------+ Test Packet +-------+ +-------+ Test Packet +-------+
| | - - - - - - - - - ->| | | | - - - - - - - - - ->| |
| S1 |=====================| R1 | | S1 |=====================| R1 |
| |<- - - - - - - - - - | | | |<- - - - - - - - - - | |
+-------+ Reply Test Packet +-------+ +-------+ Reply Test Packet +-------+
\ / \ /
T4 T3 T4 T3
STAMP Session-Sender STAMP Session-Reflector STAMP Session-Sender STAMP Session-Reflector
]]></artwork>
Reference Topology </figure>
]]></artwork>
</section> </section>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default"> <section anchor="sect-4" numbered="true" toc="default">
<name>Destination Node Address TLV</name> <name>Destination Node Address TLV</name>
<t> <t>
The Session-Sender may need to transmit test packets to the Session-Reflector with a destination address that is not a routable (i.e., The Session-Sender may need to transmit test packets to the Session-Reflector with a Destination Address that is not a routable address (i.e., not
suitable for use as the Source Address of the reply test packet) suitable for use as the Source Address of the reply test packet)
address of the Session-Reflector. This can be facilitated, for example, of the Session-Reflector. This can be facilitated, for example,
by encapsulating the STAMP packet by a tunneling protocol, see Appendix A, by encapsulating the STAMP packet by a tunneling protocol; see <xref target="
for a worked example. </t> app-A"/>
for an example. </t>
<t><xref target="RFC8972" format="default"/> defines STAMP Session-Sender <t><xref target="RFC8972" format="default"/> defines STAMP Session-Sender
and Session-Reflector test packets that and Session-Reflector test packets that can include one or more optional TLVs. I
can include one or more optional TLVs. n this document, the TLV Type (value 9 for IPv4 and IPv6) is defined for the Des
In this document, the TLV type (value 9 for IPv4 and IPv6) is defined for th tination Node Address TLV
e Destination Node Address TLV
for the STAMP test packet <xref target="RFC8972" format="default"/>. The for mats of for the STAMP test packet <xref target="RFC8972" format="default"/>. The for mats of
the Destination Node Address TLVs are shown in Figure 1:</t> the Destination Node Address TLVs are shown in <xref target="ure-node-addr
ess-tlv-format"/>:</t>
<figure anchor="ure-node-address-tlv-format"> <figure anchor="ure-node-address-tlv-format">
<name>Destination Node Address TLV Format</name> <name>Destination Node Address TLV Formats</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=9 | Length=4 | |STAMP TLV Flags| Type=9 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address | | IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=9 | Length=16 | |STAMP TLV Flags| Type=9 | Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Address | | IPv6 Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> TLV fields are defined as follows:</t> <t> The TLV fields are defined as follows:</t>
<t> STAMP TLV Flags : The STAMP TLV Flags follow the procedures described <dl spacing="normal">
in <xref target="RFC8972" format="default"/> and this document.</t> <dt> STAMP TLV Flags:</dt><dd> The STAMP TLV Flags follow the procedures d
<t> Type : Type (value 9) for IPv4 Destination Node Address TLV or IPv6 De escribed in <xref target="RFC8972" format="default"/> and this document.</dd>
stination Node Address TLV.</t> <dt> Type:</dt><dd> Type (value 9) for the IPv4 Destination Node Address T
<t> Length : A two-octet field equal to the length of the Address field in LV or IPv6 Destination Node Address TLV.</dd>
octets. The length is 4 octets for IPv4 address and 16 octets for IPv6 address. <dt> Length:</dt><dd> A 2-octet field equal to the length of the Address f
</t> ield in octets. The length is 4 octets for an IPv4 address and 16 octets for an
<t></t> IPv6 address.</dd>
</dl>
<t> <t>
The Destination Node Address TLV indicates an address of the intended The Destination Node Address TLV indicates an address of the intended
Session-Reflector node of the test packet. If the received Session-Reflector node of the test packet. If the received
Destination Node Address is one of the addresses of the Destination Node Address is one of the addresses of the
Session-Reflector, it SHOULD be used as the Source Address in the IP Session-Reflector, it <bcp14>SHOULD</bcp14> be used as the Source Address in the IP
header of the reply test packet. header of the reply test packet.
If the Destination Node Address TLV is sent, the SSID MUST also be sent. </t> If the Destination Node Address TLV is sent, the SSID <bcp14>MUST</bcp14> als o be sent. </t>
<t>A Session-Reflector that recognizes this TLV, MUST set the U flag <xref <t>A Session-Reflector that recognizes this TLV <bcp14>MUST</bcp14> set th
target="RFC8972" format="default"/> in the reply test packet to 1 if the Sessio e U flag <xref target="RFC8972" format="default"/> in the reply test packet to 1
n-Reflector if the Session-Reflector
determined that it is not the intended Destination as identified in the De determined that it is not the intended destination as identified in the De
stination stination
Node Address TLV. In this case, the Session-Reflector does not use the rec eived Destination Node Address Node Address TLV. In this case, the Session-Reflector does not use the rec eived Destination Node Address
as the Source Address in the IP header of the reply test packet. as the Source Address in the IP header of the reply test packet.
Otherwise, the Session-Reflector MUST set the U flag in the Destination No de Address TLV in the Otherwise, the Session-Reflector <bcp14>MUST</bcp14> set the U flag in the Destination Node Address TLV in the
reply test packet to 0.</t> reply test packet to 0.</t>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default"> <section anchor="sect-5" numbered="true" toc="default">
<name>Return Path TLV</name> <name>Return Path TLV</name>
<t> <t>
For end-to-end SR paths, the Session-Reflector may need to transmit the reply test For end-to-end SR paths, the Session-Reflector may need to transmit the reply test
packet on a specific return path. The Session-Sender packet on a specific Return Path. The Session-Sender
can request this in the test packet to the Session-Reflector using a Return P ath TLV. can request this in the test packet to the Session-Reflector using a Return P ath TLV.
With this TLV carried in the Session-Sender test packet, With this TLV carried in the Session-Sender test packet,
signaling and maintaining dynamic SR network state for the signaling and maintaining dynamic SR network state for the
STAMP sessions on the Session-Reflector are avoided.</t> STAMP sessions on the Session-Reflector are avoided.</t>
<t>There are two modes defined for the behaviors on the Session-Reflector in
<t>There are two modes defined for the behaviors on the Session-Reflector in <xref target="RFC8762" sectionFormat="of" section="4"/>: Stateless and Stateful.
Section 4 of <xref target="RFC8762" format="default"/>. A Stateful Session-Reflector requires configuration that must match all Sessi
A Stateful Session-Reflector that requires configuration that must match all on-Sender parameters, including the Source Address, Destination Address, Source
Session-Sender parameters, including Source Address, Destination Address, Source UDP Port, Destination UDP Port, and possibly SSID (assuming the SSID is configur
UDP Port, Destination UDP Port, and possibly SSID (assuming the SSID is configu able and not auto-generated). In this case, a local policy can be used to direct
rable and not auto-generated). In this case, a local policy can be used to direc the test packet by creating additional states for the STAMP sessions on the Ses
t the test packet by creating additional states for the STAMP sessions on the Se sion-Reflector. In the case of promiscuous operation, the Stateless Session-Refl
ssion-Reflector. In the case of promiscuous operation, the Stateless Session-Ref ector will require an indication of how to return the test packet on a specific
lector will require an indication of how to return the test packet on a specific path, for example, for measurement in an ECMP environment. </t>
path, for example, for measurement in an ECMP environment. </t>
<t>For links, the Session-Reflector may need to transmit the reply test <t>For links, the Session-Reflector may need to transmit the reply test
packet on the same incoming link in the reverse direction. packet on the same incoming link in the reverse direction.
The Session-Sender can request this in the test packet The Session-Sender can request this in the test packet
to the Session-Reflector using a Return Path TLV.</t> to the Session-Reflector using a Return Path TLV.</t>
<t><xref target="RFC8972" format="default"/> defines STAMP test packets th at <t><xref target="RFC8972" format="default"/> defines STAMP test packets th at
can include one or more optional TLVs. In this document, the TLV Type (value 10) is can include one or more optional TLVs. In this document, the TLV Type (value 10) is
defined for the Return Path TLV that carries the return path for the Session- defined for the Return Path TLV that carries the Return Path for the Session-
Sender Sender
test packet. The format of the Return Path TLV is shown in Figure 2:</t> test packet. The format of the Return Path TLV is shown in <xref target="ure-
<figure anchor="ure-return-path-tlv"> return-path-tlv"/>:</t>
<name>Return Path TLV</name> <figure anchor="ure-return-path-tlv">
<artwork name="" type="" align="left" alt=""><![CDATA[ <name>Return Path TLV Format</name>
0 1 2 3 <artwork name="" type="" align="left" alt=""><![CDATA[
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=10 | Length | |STAMP TLV Flags| Type=10 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Path Sub-TLVs | | Return Path Sub-TLVs |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> TLV fields are defined as follows:</t> <t> The TLV fields are defined as follows:</t>
<t> STAMP TLV Flags : The STAMP TLV Flags follow the procedures described <dl spacing="normal">
in <xref target="RFC8972" format="default"/> and this document.</t> <dt> STAMP TLV Flags:</dt><dd> The STAMP TLV Flags follow the procedures d
<t> Type : Type (value 10) for Return Path TLV.</t> escribed in <xref target="RFC8972" format="default"/> and this document.</dd>
<t> Length : A two-octet field equal to the length of the Return Path Sub <dt> Type:</dt><dd> Type (value 10) for the Return Path TLV.</dd>
-TLVs field in octets.</t> <dt> Length:</dt><dd> A 2-octet field equal to the length of the Return Pa
<t> Return Path Sub-TLVs : As defined in Section 4.1.</t> th Sub-TLVs field in octets.</dd>
<t></t> <dt> Return Path Sub-TLVs:</dt><dd>As defined in <xref target="sect-5.1"/>
.</dd>
</dl>
<t> <t>
A Session-Sender MUST NOT insert more than one Return Path TLV in the A Session-Sender <bcp14>MUST NOT</bcp14> insert more than one Return Path TLV
STAMP test packet. A Session-Reflector that supports this TLV MUST in the
STAMP test packet. A Session-Reflector that supports this TLV <bcp14>MUST</b
cp14>
only process the first Return Path TLV in the test packet and ignore only process the first Return Path TLV in the test packet and ignore
other Return Path TLVs if present. A Session-Reflector that supports other Return Path TLVs if present. A Session-Reflector that supports
this TLV MUST reply using the Return Path received in the this TLV <bcp14>MUST</bcp14> reply using the Return Path received in the
Session-Sender test packet, if no error was encountered while processing the TLV. Session-Sender test packet, if no error was encountered while processing the TLV.
</t> </t>
<t>A Session-Reflector that recognizes this TLV, MUST set the U flag <xref ta <t>A Session-Reflector that recognizes this TLV <bcp14>MUST</bcp14> set the U
rget="RFC8972" format="default"/> in the reply test packet to 1 if the Session-R flag <xref target="RFC8972" format="default"/> in the reply test packet to 1 if
eflector the Session-Reflector
determined that it cannot use the return path in the test packet to transmit determined that it cannot use the Return Path in the test packet to transmit
the reply test packet. the reply test packet.
Otherwise, the Session-Reflector MUST set the U flag in the Otherwise, the Session-Reflector <bcp14>MUST</bcp14> set the U flag in the
reply test packet to 0.</t> reply test packet to 0.</t>
<section anchor="sect-5.1" numbered="true" toc="default"> <section anchor="sect-5.1" numbered="true" toc="default">
<name>Return Path Sub-TLVs</name> <name>Return Path Sub-TLVs</name>
<t>The Return Path TLV contains one or more Sub-TLVs to carry <t>The Return Path TLV contains one or more Sub-TLVs to carry
the information for the requested return path. the information for the requested Return Path.
A Return Path Sub-TLV can carry Return Path Control Code, A Return Path Sub-TLV can carry a Return Path Control Code,
Return Path IP Address or Return Path Segment List.</t> Return Path IP Address, or Return Path Segment List.</t>
<t>The STAMP Sub-TLV Flags are set using the procedures described in <xr ef target="RFC8972" format="default"/>.</t> <t>The STAMP Sub-TLV Flags are set using the procedures described in <xr ef target="RFC8972" format="default"/>.</t>
<t>A Return Path TLV MUST NOT contain more than one Control Code Sub-TLV <t>A Return Path TLV <bcp14>MUST NOT</bcp14> contain more than one Contr
or more than one Return Address Sub-TLV or more than one Segment List Sub-TLV i ol Code Sub-TLV, Return Address Sub-TLV, or Return Path Segment List Sub-TLV in
n Session-Sender test packet.</t> a Session-Sender test packet.</t>
<t>A Return Path TLV MUST NOT contain both Control Code Sub-TLV as well <t>A Return Path TLV <bcp14>MUST NOT</bcp14> contain both a Control Code
as Return Address or Return Segment List Sub-TLV in Session-Sender test packet.< Sub-TLV and a Return Address or Return Path Segment List Sub-TLV in a Session-S
/t> ender test packet.</t>
<t>A Return Path TLV MAY contain both Return Address as well as Return S <t>A Return Path TLV <bcp14>MAY</bcp14> contain both a Return Address an
egment List Sub-TLV in Session-Sender test packet.</t> d a Return Path Segment List Sub-TLV in a Session-Sender test packet.</t>
<section anchor="sect-4.1.1" numbered="true" toc="default"> <section anchor="sect-4.1.1" numbered="true" toc="default">
<name>Return Path Control Code Sub-TLV</name> <name>Return Path Control Code Sub-TLV</name>
<t>The format of the Control Code Sub-TLV in the Return Path TLV is sh
<t>The format of the Return Path Control Code Sub-TLV is shown in Figu own in <xref target="ure-control-code-return-path-tlv"/>.</t>
re 3.</t>
<figure anchor="ure-control-code-return-path-tlv"> <figure anchor="ure-control-code-return-path-tlv">
<name>Control Code Sub-TLV in Return Path TLV</name> <name>Format of the Control Code Sub-TLV in the Return Path TLV</nam
<artwork name="" type="" align="left" alt=""><![CDATA[ e>
0 1 2 3 <artwork name="" type="" align="left" alt=""><![CDATA[
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=1 | Length=4 | |STAMP TLV Flags| Type=1 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control Code Flags | | Control Code Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>TLV fields are defined as follows:</t> <t>The TLV fields are defined as follows:</t>
<ul spacing="normal"> <dl newline="false" spacing="normal">
<li>Type (value 1): Return Path Control Code. <dt>Type:</dt><dd>Type (value 1) for the Return Path Control Code.
The Session-Sender can request the Session-Reflector The Session-Sender can request the Session-Reflector
to transmit the reply test packet based on the flags defined in the Control to transmit the reply test packet based on the flags defined in the Control
Code Flags field.</li> Code Flags field.</dd>
</ul> <dt>STAMP TLV Flags:</dt><dd> The STAMP TLV Flags follow the procedures de
scribed in <xref target="RFC8972" format="default"/> and this document.</dd>
<t>STAMP TLV Flags : The STAMP TLV Flags follow the procedures described i <dt>Length:</dt><dd> A 2-octet field equal to the length of the Control Co
n <xref target="RFC8972" format="default"/> and this document.</t> de flags, which is 4 octets.</dd>
<t>Length : A two-octet field equal to the length of the Control Code flag <dt>Control Code Flags (32 bits):</dt><dd><t>Reply Request Flag at bit 31
s which is 4 octets.</t> (least significant bit) is defined as follows.</t>
<t>Control Code Flags (32-bit): Reply Request Flag at bit 31 (least signif <dl newline="false" spacing="normal" indent="3">
icant bit) is defined as follows.</t> <dt> 0x0:</dt><dd> No Reply Requested</dd>
<dl newline="false" spacing="normal" indent="4"> <dt> 0x1:</dt><dd> Reply Requested on the Same Link</dd>
<dt/> </dl>
<dd> </dd>
0x0 : No Reply Requested.</dd> </dl>
</dl>
<dl newline="false" spacing="normal" indent="4">
<dt/>
<dd>
0x1 : Reply Requested on the Same Link.</dd>
</dl>
<t> All other bits are reserved and must be transmitted as 0 and ignored b y the receiver.</t> <t> All other bits are reserved and must be transmitted as 0 and ignored b y the receiver.</t>
<t>When Control Code flag for Reply Request is set to 0x0 in the Sessi on-Sender test packet, <t>When Control Code flag for Reply Request is set to 0x0 in the Sessi on-Sender test packet,
the Session-Reflector does not the Session-Reflector does not
transmit reply test packet to the Session-Sender and terminates the transmit a reply test packet to the Session-Sender and terminates the
STAMP test packet. Only the one-way measurement is applicable in this case. STAMP test packet. Only the one-way measurement is applicable in this case.
Optionally, the Session-Reflector may locally stream performance metrics Optionally, the Session-Reflector may locally stream performance metrics
via telemetry using the information from the received test packet. via telemetry using the information from the received test packet.
All other Return Path Sub-TLVs MUST be ignored in this case.</t> All other Return Path Sub-TLVs <bcp14>MUST</bcp14> be ignored in this case.< /t>
<t>When Control Code flag for Reply Request is set to 0x1 in the Sessi on-Sender test packet, <t>When Control Code flag for Reply Request is set to 0x1 in the Sessi on-Sender test packet,
the Session-Reflector transmits the reply test packet over the same incoming link the Session-Reflector transmits the reply test packet over the same incoming link
where the test packet is received in the reverse direction towards the Sessi on-Sender. where the test packet is received in the reverse direction towards the Sessi on-Sender.
The link may be a physical interface, virtual link, The link may be a physical interface, virtual link, LAG <xref target="IEEE80
or Link Aggregation Group (LAG) <xref target="IEEE802.1AX" format="default"/ 2.1AX" format="default"/>, or LAG member.
>, or LAG member. All other Return Path Sub-TLVs <bcp14>MUST</bcp14> be ignored in this case.
All other Return Path Sub-TLVs MUST be ignored in this case. When using LAG member links, the STAMP extension for the Micro-Session ID TL
When using LAG member links, STAMP extension for Micro-Session ID TLV define V defined
d
in <xref target=" I-D.ietf-ippm-stamp-on-lag" format="default"/> can be used to identify the link. in <xref target=" I-D.ietf-ippm-stamp-on-lag" format="default"/> can be used to identify the link.
</t> </t>
</section> </section>
<section anchor="sect-5.1.2" numbered="true" toc="default"> <section anchor="sect-5.1.2" numbered="true" toc="default">
<name>Return Address Sub-TLV</name> <name>Return Address Sub-TLVs</name>
<t>The STAMP reply test packet may be transmitted to the Session-Sende r <t>The STAMP reply test packet may be transmitted to the Session-Sende r
to the specified Return Address in the Return Address Sub-TLV instead of tran smitting to the Source Address in the Session-Sender test packet.</t> to the specified Return Address in the Return Address Sub-TLV instead of tran smitting to the Source Address in the Session-Sender test packet.</t>
<t>The formats of the IPv4 and IPv6 Return Address Sub-TLVs are shown i n Figure 4.</t> <t>The formats of the IPv4 and IPv6 Return Address Sub-TLVs in the Return Pat h TLV are shown in <xref target="ure-return-node-address-tlv-format"/>.</t>
<figure anchor="ure-return-node-address-tlv-format"> <figure anchor="ure-return-node-address-tlv-format">
<name>Return Address Sub-TLV in Return Path TLV</name> <name>Formats of the Return Address Sub-TLVs in the Return Path TLV<
<artwork name="" type="" align="left" alt=""><![CDATA[ /name>
0 1 2 3 <artwork name="" type="" align="left" alt=""><![CDATA[
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=2 | Length=4 | |STAMP TLV Flags| Type=2 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return IPv4 Address | | Return IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=2 | Length=16 | |STAMP TLV Flags| Type=2 | Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Return IPv6 Address | | Return IPv6 Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> The TLV fields are defined as follows:</t>
<ul spacing="normal"> <t> The TLV fields are defined as follows:</t>
<li>Type : Type (value 2) for IPv4 Return Address or IPv6 Return Add <dl newline="false" spacing="normal">
ress.</li> <dt>Type:</dt><dd>Type (value 2) for the Return IPv4 Address or Return
</ul> IPv6 Address.</dd>
</dl>
<t> The Return Address requests that the Session-Reflector reply test pack et <t> The Return Address requests that the Session-Reflector reply test pack et
be sent to the specified address, rather than to the Source Address in be sent to the specified address rather than to the Source Address in
the Session-Sender test packet.</t> the Session-Sender test packet.</t>
<t> STAMP TLV Flags : The STAMP TLV Flags follow the procedures described <dl spacing="normal">
in <xref target="RFC8972" format="default"/> and this document.</t> <dt> STAMP TLV Flags:</dt><dd> The STAMP TLV Flags follow the procedures d
<t> Length : A two-octet field equal to the length of the Return Address f escribed in <xref target="RFC8972" format="default"/> and this document.</dd>
ield in octets. <dt> Length:</dt><dd> A 2-octet field equal to the length of the Return Ad
The length is 4 octets for IPv4 address and 16 octets for IPv6 address.</t dress field in octets.
> The length is 4 octets for an IPv4 address and 16 octets for an IPv6 addre
ss.</dd>
</dl>
</section> </section>
<section anchor="sect-5.1.3" numbered="true" toc="default"> <section anchor="sect-5.1.3" numbered="true" toc="default">
<name>Return Segment List Sub-TLVs</name> <name>Return Path Segment List Sub-TLVs</name>
<t>The format of the Segment List Sub-TLVs in the Return Path TLV is s <t>The format of the Segment List Sub-TLVs in the Return Path TLV is s
hown in Figures 5 and 6. hown in Figures <xref target="ure-sr-mpl-segment-list-sub-tlv-in-return-path-tlv
" format="counter"/> and <xref target="ure-srv6segment-list-sub-tlv-in-return-pa
th-tlv" format="counter"/>.
The Segments carried in Segment List Sub-TLVs are described in <xref targe t="RFC8402" format="default"/>. The Segments carried in Segment List Sub-TLVs are described in <xref targe t="RFC8402" format="default"/>.
The segment entries MUST be in network order.</t> The segment entries <bcp14>MUST</bcp14> be in network order.</t>
<t>The Session-Sender MUST only insert one Segment List Return Path Su <t>The Session-Sender <bcp14>MUST</bcp14> only insert one Return Path
b-TLV Segment List Sub-TLV
in the test packet and Segment List MUST contain at least one Segment. Th in the test packet, and the Segment List <bcp14>MUST</bcp14> contain at le
e Session-Reflector MUST only process ast one Segment. The Session-Reflector <bcp14>MUST</bcp14> only process
the first Segment List Return Path Sub-TLV in the test packet and ignore o the first Return Path Segment List Sub-TLV in the test packet and ignore o
ther ther
Segment List Return Path Sub-TLVs if present.</t> Return Path Segment List Sub-TLVs if present.</t>
<t> TLV fields are defined as follows:</t> <t> The TLV fields are defined as follows:</t>
<t> The Segment List Sub-TLV can be one of the following Types:</t> <dl newline="false" spacing="normal">
<ul spacing="normal"> <dt> The Return Path Segment List Sub-TLV can be one of the following Ty
<li>Type (value 3): SR-MPLS Label Stack of the Return Path</li> pes:</dt>
<li>Type (value 4): SRv6 Segment List of the Return Path</li> <dd><t><br/></t>
</ul> <dl indent="3" newline="false" spacing="normal">
<t> STAMP TLV Flags : The STAMP TLV Flags follow the procedures described <dt>Type (value 3):</dt><dd> SR-MPLS Label Stack of the Return Path<
in <xref target="RFC8972" format="default"/> and this document.</t> /dd>
<t> Length : A two-octet field equal to the length of the Segment List fie <dt>Type (value 4):</dt><dd> SRv6 Segment List of the Return Path</d
ld in octets. Length MUST NOT be 0.</t> d>
</dl>
</dd>
<dt> STAMP TLV Flags:</dt><dd> The STAMP TLV Flags follow the procedures d
escribed in <xref target="RFC8972" format="default"/> and this document.</dd>
<dt> Length:</dt><dd> A 2-octet field equal to the length of the Segment L
ist field in octets. The length <bcp14>MUST NOT</bcp14> be 0.</dd>
</dl>
<section anchor="sect-5.1.3.1" numbered="true" toc="default"> <section anchor="sect-5.1.3.1" numbered="true" toc="default">
<name>Return Path SR-MPLS Segment-List Sub-TLV</name> <name>Return Path SR-MPLS Label Stack Sub-TLV</name>
<figure anchor="ure-sr-mpl-segment-list-sub-tlv-in-return-path-tlv"> <figure anchor="ure-sr-mpl-segment-list-sub-tlv-in-return-path-tlv">
<name>SR-MPLS Segment List Sub-TLV in Return Path TLV</name> <name>Format of the SR-MPLS Label Stack Sub-TLV in the Return Path T
<artwork name="" type="" align="left" alt=""><![CDATA[ LV</name>
0 1 2 3 <artwork name="" type="" align="left" alt=""><![CDATA[
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=3 | Length | |STAMP TLV Flags| Type=3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment(1) | TC |S| TTL | | Segment(1) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment(n) (bottom of stack) | TC |S| TTL | | Segment(n) (bottom of stack) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The SR-MPLS Label Stack contains a list of 32-bit Label Stack Entry (LSE <t>The SR-MPLS Label Stack contains a list of 32-bit Label Stack Entries (L
) that includes a 20-bit label value, SEs) that includes a 20-bit label value,
8-bit Time-To-Live (TTL) value, 3-bit Traffic Class (TC) value and 1-bit E an 8-bit Time-To-Live (TTL) value, a 3-bit Traffic Class (TC) value, and a
nd-Of-Stack (S) field. Length of the Sub-TLV modulo 4 MUST be 0.</t> 1-bit End-of-Stack (S) field. The length of the Sub-TLV modulo 4 <bcp14>MUST</b
cp14> be 0.</t>
<t>As an example, an SR-MPLS Label Stack Sub-TLV could carry only the Bind ing SID Label <t>As an example, an SR-MPLS Label Stack Sub-TLV could carry only the Bind ing SID Label
<xref target="I-D.ietf-pce-binding-label-sid" format="default"/> of the Re turn SR-MPLS Policy. <xref target="I-D.ietf-pce-binding-label-sid" format="default"/> of the Re turn SR-MPLS Policy.
The Binding SID Label of the Return SR-MPLS Policy is local to the Session -Reflector. The Binding SID Label of the Return SR-MPLS Policy is local to the Session -Reflector.
The mechanism to signal the Binding SID Label to the Session-Sender is out side the scope of this document.</t> The mechanism to signal the Binding SID Label to the Session-Sender is out side the scope of this document.</t>
<t>As another example, an SR-MPLS Label Stack Sub-TLV could include the Pa th Segment Identifier Label of the Return SR-MPLS Policy in the Segment List of the SR-MPLS Policy.</t> <t>As another example, an SR-MPLS Label Stack Sub-TLV could include the Pa th Segment Identifier Label of the Return SR-MPLS Policy in the Segment List of the SR-MPLS Policy.</t>
</section> </section>
<section anchor="sect-5.1.3.2" numbered="true" toc="default"> <section anchor="sect-5.1.3.2" numbered="true" toc="default">
<name>Return Path SRv6 Segment-List Sub-TLV</name> <name>Return Path SRv6 Segment List Sub-TLV</name>
<figure anchor="ure-srv6segment-list-sub-tlv-in-return-path-tlv"> <figure anchor="ure-srv6segment-list-sub-tlv-in-return-path-tlv">
<name>SRv6 Segment List Sub-TLV in Return Path TLV</name> <name>Format of the SRv6 Segment List Sub-TLV in the Return Path TLV
<artwork name="" type="" align="left" alt=""><![CDATA[ </name>
0 1 2 3 <artwork name="" type="" align="left" alt=""><![CDATA[
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=4 | Length | |STAMP TLV Flags| Type=4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Segment(1) (128-bit IPv6 address) | | Segment(1) (128-bit IPv6 Address) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Segment(n) (128-bit IPv6 address) (bottom of stack) | | Segment(n) (128-bit IPv6 Address) (bottom of stack) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The SRv6 Segment List contains a list of 128-bit IPv6 addresses represe nting the SRv6 SIDs. Length of the Sub-TLV modulo 16 MUST be 0.</t> <t>The SRv6 Segment List contains a list of 128-bit IPv6 addresses represe nting the SRv6 SIDs. The length of the Sub-TLV modulo 16 <bcp14>MUST</bcp14> be 0.</t>
<t>As an example, an SRv6 Segment List Sub-TLV could carry only the SRv6 B inding SID <t>As an example, a Return Path SRv6 Segment List Sub-TLV could carry only the SRv6 Binding SID
<xref target="I-D.ietf-pce-binding-label-sid" format="default"/> of the Re turn SRv6 Policy. <xref target="I-D.ietf-pce-binding-label-sid" format="default"/> of the Re turn SRv6 Policy.
The SRv6 Binding SID of the Return SRv6 Policy is local to the Session-Ref lector. The SRv6 Binding SID of the Return SRv6 Policy is local to the Session-Ref lector.
The mechanism to signal the SRv6 Binding SID to the Session-Sender is outs ide the scope of this document.</t> The mechanism to signal the SRv6 Binding SID to the Session-Sender is outs ide the scope of this document.</t>
<t>As another example, an SRv6 Segment List Sub-TLV could include the SRv6 Path Segment Identifier of the Return SRv6 Policy in the Segment List of the SR v6 Policy.</t> <t>As another example, a Return Path SRv6 Segment List Sub-TLV could inclu de the SRv6 Path Segment Identifier of the Return SRv6 Policy in the Segment Lis t of the SRv6 Policy.</t>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sect-6" numbered="true" toc="default"> <section anchor="sect-6" numbered="true" toc="default">
<name>Interoperability with TWAMP Light</name> <name>Interoperability with TWAMP Light</name>
<t>This document does not introduce any additional considerations for inte roperability <t>This document does not introduce any additional considerations for inte roperability
with TWAMP Light than those described in Section 4.6 of <xref target="R FC8762" format="default"/>. </t> with the Two-Way Active Measurement Protocol (TWAMP) Light than those d escribed in <xref target="RFC8762" sectionFormat="of" section="4.6"/>. </t>
<t>As described in <xref target="RFC8762" format="default"/>, there are tw o possible <t>As described in <xref target="RFC8762" format="default"/>, there are tw o possible
combinations for such an interoperability use case:</t> combinations for such an interoperability use case:</t>
<ul spacing="normal">
<li> STAMP Session-Sender with TWAMP Light Session-Reflector </li>
<li> TWAMP Light Session-Sender with STAMP Session-Reflector </li>
</ul>
<t> - STAMP Session-Sender with TWAMP Light Session-Reflector </t> <t>If any of the STAMP extensions defined in this document are used by STA
MP Session-Sender,
<t> - TWAMP Light Session-Sender with STAMP Session-Reflector </t>
<t>If any of STAMP extensions defined in this document are used by STAMP S
ession-Sender,
the TWAMP Light Session-Reflector will view them as the Packet Padding field.</t> the TWAMP Light Session-Reflector will view them as the Packet Padding field.</t>
</section> </section>
<section anchor="sect-7" numbered="true" toc="default"> <section anchor="sect-7" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The security considerations specified in <xref target="RFC8762" format ="default"/> <t>The security considerations specified in <xref target="RFC8762" format ="default"/>
and <xref target="RFC8972" format="default"/> also apply to the extensions and <xref target="RFC8972" format="default"/> also apply to the extensions
defined in this document. Specifically, the authenticated mode and the defined in this document. Specifically, the authenticated mode and the
message integrity protection using HMAC, as defined in <xref target="RFC8762" message integrity protection using Hashed Message Authentication Code (HMAC),
format="default"/> as defined in <xref target="RFC8762" sectionFormat="of" section="4.4"/>, also a
Section 4.4, also apply to the procedure described in this document.</t> pply to the procedures described in this document.</t>
<t>STAMP uses the well-known UDP port number that could become <t>STAMP uses the well-known UDP port number that could become
a target of denial of service (DoS) or could a target of denial of service (DoS) or could
be used to aid on-path attacks. be used to aid on-path attacks.
Thus, the security considerations and measures to mitigate the Thus, the security considerations and measures to mitigate the
risk of the attack documented in Section 6 of <xref target="RFC8545" format=" default"/> risk of the attack documented in <xref target="RFC8545" sectionFormat="of" se ction="6"/>
equally apply to the STAMP extensions in this document.</t> equally apply to the STAMP extensions in this document.</t>
<t>If desired, attacks can be mitigated by performing basic validation <t>If desired, attacks can be mitigated by performing basic validation
checks of the timestamp fields (such as T2 is later than T1 in the Reference Topology in Section 2.3) checks of the timestamp fields (such as T2 is later than T1 in the reference topology in <xref target="sect-2.3"/>)
in received reply test packets at the Session-Sender. The minimal state in received reply test packets at the Session-Sender. The minimal state
associated with these protocols also limit the extent of measurement associated with these protocols also limit the extent of measurement
disruption that can be caused by a corrupt or invalid test packet to a disruption that can be caused by a corrupt or invalid test packet to a
single test cycle.</t> single test cycle.</t>
<t> <t>
The usage of STAMP extensions defined in this document is intended for deploy ment in a single network administrative domain. The usage of STAMP extensions defined in this document is intended for deploy ment in a single network administrative domain.
As such, the Session-Sender address, Session-Reflector address, and Return Pa th are provisioned by the operator for the STAMP session. As such, the Session-Sender address, Session-Reflector address, and Return Pa th are provisioned by the operator for the STAMP session.
It is assumed that the operator has It is assumed that the operator has
verified the integrity of the Return Path and identity of the far-end Session -Reflector.</t> verified the integrity of the Return Path and identity of the far-end Session -Reflector.</t>
<t> <t>
The STAMP extensions defined in this document may be used for The STAMP extensions defined in this document may be used for
potential address spoofing. For example, a Session-Sender potential address spoofing. For example, a Session-Sender
may specify a Return Path IP Address that is different from the Session-Sende r address. may specify a Return Path IP Address that is different from the Session-Sende r address.
The Session-Reflector MAY drop the Session-Sender test packet when it cannot The Session-Reflector <bcp14>MAY</bcp14> drop the Session-Sender test packet when it cannot
determine whether the Return Path IP Address is local on the determine whether the Return Path IP Address is local on the
Session-Sender. To help Session-Reflector to make that determination, the Ret urn Path Session-Sender. To help the Session-Reflector to make that determination, the Return Path
IP Address may also be provisioned by the operator, for example, in an access control list. IP Address may also be provisioned by the operator, for example, in an access control list.
</t> </t>
</section> </section>
<section anchor="sect-8" numbered="true" toc="default"> <section anchor="sect-8" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t> <t>
IANA has created the "STAMP TLV Types" registry for <xref target="RFC8972" fo IANA has allocated a value for the Destination Address TLV Type and a value f
rmat="default"/>. or the
IANA has early allocated a value for the Return Path TLV Type from the IETF Review TLV range in the "STAMP TLV Types"
Destination Address TLV Type and a value for the registry <xref target="RFC8972" format="default"/> as follows.
Return Path TLV Type from the IETF Review TLV range of the same registry. </t </t>
>
<table anchor="iana-tlv-type-tbl" align="center"> <table anchor="iana-tlv-type-tbl" align="center">
<name>STAMP TLV Types</name> <name>STAMP 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">9 (Early Allocation)</td> <td align="left">9</td>
<td align="center">Destination Node IPv4 or IPv6 Address</td> <td align="left">Destination Node IPv4 or IPv6 Address</td>
<td align="left">This document</td> <td align="left">RFC 9503</td>
</tr> </tr>
<tr> <tr>
<td align="left">10 (Early Allocation)</td> <td align="left">10</td>
<td align="center">Return Path</td> <td align="left">Return Path</td>
<td align="left">This document</td> <td align="left">RFC 9503</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
IANA is requested to create a sub-registry for "Return Path Sub-TLV Type". IANA has created the "Return Path Sub-TLV Types" registry.
All code points in the range 1 through 175 in this registry shall be All code points in the range 1 through 175 in this registry shall be
allocated according to the "IETF Review" procedure as specified in allocated according to the "IETF Review" procedure as specified in
<xref target="RFC8126" format="default"/>. Code points in the range 176 thro <xref target="RFC8126" format="default"/>. Code points in the range 176 thro
ugh 239 in this ugh 239 shall be allocated according to the "First Come First
registry shall be allocated according to the "First Come, First
Served" procedure as specified in <xref target="RFC8126" format="default"/>. Served" procedure as specified in <xref target="RFC8126" format="default"/>.
Remaining code points are allocated according to <xref target="iana-return-pa th-tbl" format="default"/>: Remaining code points shall be allocated according to <xref target="iana-retu rn-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 Types Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left">Range</th>
<th align="center">Description</th> <th align="left">Registration Procedures</th>
<th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0 - 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>
</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>
</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>
</tr> </tr>
<tr> <tr>
<td align="left">252 - 255</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>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
IANA is requested to allocate the values for the following Sub-TLV Types from this registry.</t> IANA has allocated values for the following Sub-TLV Types in the "Return Path Sub-TLV Types" registry.</t>
<table anchor="iana-return-path-reg-types" align="center"> <table anchor="iana-return-path-reg-types" align="center">
<name>Return Path Sub-TLV Types</name> <name>Return Path Sub-TLV Types</name>
<thead> <thead>
<tr> <tr>
<th align="left">Type</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 9503</td>
</tr> </tr>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="center">Return Path Control Code</td> <td align="left">Return Path Control Code</td>
<td align="left">This document</td> <td align="left">RFC 9503</td>
</tr> </tr>
<tr> <tr>
<td align="left">2</td> <td align="left">2</td>
<td align="center">Return IPv4 or IPv6 Address</td> <td align="left">Return IPv4 or IPv6 Address</td>
<td align="left">This document</td> <td align="left">RFC 9503</td>
</tr> </tr>
<tr> <tr>
<td align="left">3</td> <td align="left">3</td>
<td align="center">SR-MPLS Label Stack of the Return Path</td> <td align="left">SR-MPLS Label Stack of the Return Path</td>
<td align="left">This document</td> <td align="left">RFC 9503</td>
</tr> </tr>
<tr> <tr>
<td align="left">4</td> <td align="left">4</td>
<td align="center">SRv6 Segment List of the Return Path</td> <td align="left">SRv6 Segment List of the Return Path</td>
<td align="left">This document</td> <td align="left">RFC 9503</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 9503</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
IANA is requested to create a sub-registry for "Return Path Control Code Flag s" for the Return Path Control Code Sub-TLV. IANA has created the "Return Path Control Code Flags" registry for Return Pat h Control Code Sub-TLVs.
All code points in the bit position 31 (counting from bit 31 as the least sig nificant bit) through 12 in this registry shall be All code points in the bit position 31 (counting from bit 31 as the least sig nificant bit) through 12 in this registry shall be
allocated according to the "IETF Review" procedure as specified in allocated according to the "IETF Review" procedure as specified in
<xref target="RFC8126" format="default"/>. Code points in the bit position 1 <xref target="RFC8126" format="default"/>. Code points in the bit position 1
1 through 8 in this 1 through 8 shall be allocated according to the "First Come First
registry shall be allocated according to the "First Come, First
Served" procedure as specified in <xref target="RFC8126" format="default"/>. Served" procedure as specified in <xref target="RFC8126" format="default"/>.
Remaining code points are allocated according to <xref target="iana-return-pa th-cc-tbl" format="default"/>: Remaining code points shall be allocated according to <xref target="iana-retu rn-path-cc-tbl" format="default"/>:
</t> </t>
<table anchor="iana-return-path-cc-tbl" align="center"> <table anchor="iana-return-path-cc-tbl" align="center">
<name>Return Path Control Code Flags Registry</name> <name>Return Path Control Code Flags Registry</name>
<thead> <thead>
<tr> <tr>
<th align="left">Bit</th> <th align="left">Range</th>
<th align="center">Description</th> <th align="left">Registration Procedures</th>
<th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">31 - 12</td> <td align="left">31-12</td>
<td align="center">IETF Review</td> <td align="left">IETF Review</td>
<td align="left">This document</td>
</tr> </tr>
<tr> <tr>
<td align="left">11 - 8</td> <td align="left">11-8</td>
<td align="center">First Come, First Served</td> <td align="left">First Come First Served</td>
<td align="left">This document</td>
</tr> </tr>
<tr> <tr>
<td align="left">7 - 4</td> <td align="left">7-4</td>
<td align="center">Experimental Use</td> <td align="left">Experimental Use</td>
<td align="left">This document</td>
</tr> </tr>
<tr> <tr>
<td align="left">3 - 0</td> <td align="left">3-0</td>
<td align="center">Private Use</td> <td align="left">Private Use</td>
<td align="left">This document</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
IANA is requested to allocate the value for the following Return Path Control Code Flag from this registry.</t> IANA has allocated a value in the "Return Path Control Code Flags" registry a s follows.</t>
<table anchor="iana-return-path-cc-reg-types" align="center"> <table anchor="iana-return-path-cc-reg-types" align="center">
<name>Return Path Control Code Flags</name> <name>Return Path Control Code Flags</name>
<thead> <thead>
<tr> <tr>
<th align="left">Bit</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">31</td> <td align="left">31</td>
<td align="center">Reply Request</td> <td align="left">Reply Request</td>
<td align="left">This document</td> <td align="left">RFC 9503</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-pce-binding-label-sid" to="PCE-BINDING-LABEL-
SID"/>
<displayreference target="I-D.ietf-ippm-stamp-yang" to="IPPM-STAMP-YANG"/>
<displayreference target="I-D.ietf-ippm-stamp-on-lag" to="STAMP-ON-LAG"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.21 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
19.xml"> 19.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<title>Key words for use in RFCs to Indicate Requirement Levels</tit 74.xml"/>
le> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.87
<author initials="S." surname="Bradner" fullname="S. Bradner"> 62.xml"/>
<organization/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.89
</author> 72.xml"/>
<date year="1997" month="March"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/>
</author>
<date year="2017" month="May"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8762" target="https://www.rfc-editor.org/info/rfc8
762" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.87
62.xml">
<front>
<title>Simple Two-Way Active Measurement Protocol</title>
<author initials="G." surname="Mirsky" fullname="G. Mirsky">
<organization/>
</author>
<author initials="G." surname="Jun" fullname="G. Jun">
<organization/>
</author>
<author initials="H." surname="Nydell" fullname="H. Nydell">
<organization/>
</author>
<author initials="R." surname="Foote" fullname="R. Foote">
<organization/>
</author>
<date year="2020" month="March"/>
</front>
<seriesInfo name="RFC" value="8762"/>
<seriesInfo name="DOI" value="10.17487/RFC8762"/>
</reference>
<reference anchor="RFC8972" target="https://www.rfc-editor.org/info/rfc8
972" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.89
72.xml">
<front>
<title>Simple Two-Way Active Measurement Protocol Optional Extension
s</title>
<author initials="G." surname="Mirsky" fullname="G. Mirsky">
<organization/>
</author>
<author initials="X." surname="Min" fullname="X. Min">
<organization/>
</author>
<author initials="H." surname="Nydell" fullname="H. Nydell">
<organization/>
</author>
<author initials="R." surname="Foote" fullname="R. Foote">
<organization/>
</author>
<author initials="A." surname="Masputra" fullname="A. Masputra">
<organization/>
</author>
<author initials="E." surname="Ruffini" fullname="E. Ruffini">
<organization/>
</author>
<date year="2021" month="January"/>
</front>
<seriesInfo name="RFC" value="8972"/>
<seriesInfo name="DOI" value="10.17487/RFC8972"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8
402" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.84
02.xml">
<front>
<title>Segment Routing Architecture</title>
<author initials="C." surname="Filsfils" fullname="C. Filsfils" role
="editor">
<organization/>
</author>
<author initials="S." surname="Previdi" fullname="S. Previdi" role="
editor">
<organization/>
</author>
<author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
<organization/>
</author>
<author initials="B." surname="Decraene" fullname="B. Decraene">
<organization/>
</author>
<author initials="S." surname="Litkowski" fullname="S. Litkowski">
<organization/>
</author>
<author initials="R." surname="Shakir" fullname="R. Shakir">
<organization/>
</author>
<date year="2018" month="July"/>
</front>
<seriesInfo name="RFC" value="8402"/>
<seriesInfo name="DOI" value="10.17487/RFC8402"/>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
126" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.81
26.xml">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author initials="M." surname="Cotton" fullname="M. Cotton">
<organization/>
</author>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/>
</author>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization/>
</author>
<date year="2017" month="June"/>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC8545" target="https://www.rfc-editor.org/info/rfc8
545" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.85
45.xml">
<front>
<title>Well-Known Port Assignments for the One-Way Active Measuremen
t Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)</title>
<author initials="A." surname="Morton" fullname="A. Morton" role="ed
itor">
<organization/>
</author>
<author initials="G." surname="Mirsky" fullname="G. Mirsky" role="ed
itor">
<organization/>
</author>
<date year="2019" month="March"/>
</front>
<seriesInfo name="RFC" value="8545"/>
<seriesInfo name="DOI" value="10.17487/RFC8545"/>
</reference>
<reference anchor="RFC9256" target="https://www.rfc-editor.org/info/rfc9 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
256" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.92 02.xml"/>
56.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<front> 26.xml"/>
<title>Segment Routing Policy Architecture</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.85
<author fullname="Clarence Filsfils"> 45.xml"/>
<organization>Cisco Systems</organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
</author> 56.xml"/>
<author fullname="Ketan Talaulikar">
<organization>Cisco Systems</organization>
</author>
<author fullname="Daniel Voyer">
<organization>Bell Canada</organization>
</author>
<author fullname="Alex Bogdanov">
<organization>British Telecom</organization>
</author>
<author fullname="Paul Mattes">
<organization>Microsoft</organization>
</author>
<date month="July" year="2022"/>
</front>
<seriesInfo name="RFC" value="9256"/>
<seriesInfo name="DOI" value="10.17487/RFC9256"/>
</reference>
<reference anchor="I-D.ietf-pce-binding-label-sid" xml:base="https://xml
2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-binding-label-sid.
xml" target="https://www.ietf.org/archive/id/draft-ietf-pce-binding-label-sid-16
.txt">
<front>
<title>Carrying Binding Label/Segment Identifier in PCE-based Networ
ks.</title>
<author fullname="Siva Sivabalan">
<organization>Ciena Corporation</organization>
</author>
<author fullname="Clarence Filsfils">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Jeff Tantsura">
<organization>Microsoft Corporation</organization>
</author>
<author fullname="Stefano Previdi">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Cheng Li (editor)">
<organization>Huawei Technologies</organization>
</author>
<date month="March" day="27" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-binding-label-
sid-16"/>
</reference>
<reference anchor="I-D.ietf-ippm-stamp-yang" xml:base="https://xml2rfc.t <!-- [I-D.ietf-pce-binding-label-sid] in MISSREF state as of 10/30/23; entered t
ools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ippm-stamp-yang.xml" target= he long way to capture the editor role -->
"https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-yang-11.txt"> <reference anchor="I-D.ietf-pce-binding-label-sid" target="https://datatracker.i
<front> etf.org/doc/html/draft-ietf-pce-binding-label-sid-16">
<title>Simple Two-way Active Measurement Protocol (STAMP) Data Model <front>
</title> <title>Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks
<author fullname="Greg Mirsky"> .</title>
<organization>ZTE Corp.</organization> <author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
</author> <organization>Ciena Corporation</organization>
<author fullname="Xiao Min"> </author>
<organization>ZTE Corp.</organization> <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
</author> <organization>Cisco Systems, Inc.</organization>
<author fullname="Wei S Luo"> </author>
<organization>Ericsson</organization> <author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
</author> <organization>Nvidia</organization>
<date month="March" day="13" year="2023"/> </author>
</front> <author fullname="Stefano Previdi" initials="S." surname="Previdi">
<seriesInfo name="Internet-Draft" value="draft-ietf-ippm-stamp-yang-11 <organization>Huawei Technologies</organization>
"/> </author>
</reference> <author fullname="Cheng Li" initials="C." surname="Li" role="editor">
<organization>Huawei Technologies</organization>
</author>
<date day="27" month="March" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-binding-label-sid-16"/
>
</reference>
<reference anchor="I-D.ietf-ippm-stamp-on-lag" xml:base="https://xml2rfc. <!-- [I-D.ietf-ippm-stamp-yang] Expired as of 10/30/23 -->
tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ippm-stamp-on-lag.xml" targ <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ip
et="https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-on-lag-03.txt"> pm-stamp-yang.xml"/>
<front>
<title>Simple Two-Way Active Measurement Protocol Extensions for Perform
ance Measurement on LAG</title>
<author fullname="Zhenqiang Li">
<organization> China Mobile</organization>
</author>
<author fullname="Tianran Zhou">
<organization> Huawei</organization>
</author>
<author fullname="Jun Guo">
<organization> ZTE Corp.</organization>
</author>
<author fullname="Greg Mirsky">
<organization> Ericsson</organization>
</author>
<author fullname="Rakesh Gandhi">
<organization> Cisco</organization>
</author>
<date month="July" day="02" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ippm-stamp-on-lag-
03"/>
</reference>
<!-- [I-D.ietf-ippm-stamp-on-lag] In last call as of 10/30/23. Added the long
way to get correct author name-->
<reference anchor="I-D.ietf-ippm-stamp-on-lag" target="https://datatracker.ietf.
org/doc/html/draft-ietf-ippm-stamp-on-lag-05">
<front>
<title>Simple Two-Way Active Measurement Protocol Extensions for Performance
Measurement on LAG</title>
<author fullname="Zhenqiang Li" initials="Z." surname="Li">
<organization>China Mobile</organization>
</author>
<author fullname="Tianran Zhou" initials="T." surname="Zhou">
<organization>Huawei</organization>
</author>
<author fullname="Guo Jun" initials="J." surname="Guo">
<organization>ZTE Corp.</organization>
</author>
<author fullname="Greg Mirsky" initials="G." surname="Mirsky">
<organization>Ericsson</organization>
</author>
<author fullname="Rakesh Gandhi" initials="R." surname="Gandhi">
<organization>Cisco</organization>
</author>
<date day="17" month="October" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ippm-stamp-on-lag-05"/>
</reference>
<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 -- Lin k Aggregation</title>
<author> <author>
<organization> <organization>IEEE
IEEE Std. 802.1AX
</organization> </organization>
</author> </author>
<date month="November" year="2008"/> <date month="December" year="2014"/>
</front> </front>
<seriesInfo name="IEEE" value="Std 802.1AX-2014"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2014.7055197"/>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="app-A" toc="default"> <section anchor="app-A" toc="default">
<name>Destination Node Address TLV Use-case Example</name> <name>Destination Node Address TLV Use-Case Example</name>
<t>STAMP test packets can be
<t>The STAMP test packets can be encapsulated with 1) an SR-MPLS Label Stack and IPv4 header containing
encapsulated with an SR-MPLS Segment List and IPv4 header containing an IPv4 Destination Address from the 127/8 range or 2) an outer IPv6 header
destination IPv4 address from 127/8 range or STAMP test packets encapsulated and a Segment Routing
with outer IPv6 header and Segment Routing Header (SRH) with an inner IPv6 header containing an IPv6 Destination Addres
Header (SRH) with inner IPv6 header containing IPv6 destination IPv6 address s from the ::1/128 range.</t>
::1/128.</t>
<t>In an ECMP environment, the hashing function in forwarding may decide the outgoing <t>In an ECMP environment, the hashing function in forwarding may decide the outgoing
path using the source address, destination address, UDP ports, IPv6 flow-lab path using the Source Address, Destination Address, UDP ports, IPv6 flow-lab
el, etc. from the packet. el, etc. from the packet.
Hence, for IPv4, for example, different values of IPv4 destination Hence, for IPv4, for example, different values of an IPv4 Destination
address from 127/8 range may be used in the IPv4 header of the STAMP test pa Address from the 127/8 range may be used in the IPv4 header of the STAMP tes
ckets to measure different ECMP paths. t packets to measure different ECMP paths.
For IPv6, for example, different values of flow-label may be used in the IPv 6 header of the STAMP test packets to measure different ECMP paths.</t> For IPv6, for example, different values of flow-label may be used in the IPv 6 header of the STAMP test packets to measure different ECMP paths.</t>
<t> <t>
In those cases, the STAMP test packets may reach a node that is not the Sess ion-Reflector In those cases, the STAMP test packets may reach a node that is not the Sess ion-Reflector
for this STAMP session in an error condition, and this un-intended node may for this STAMP session in an error condition, and this unintended node may t
transmit reply ransmit a reply
test packet that can result in reporting of invalid measurement metrics. The test packet that can result in the reporting of invalid measurement metrics.
intended Session-Reflector address The intended Session-Reflector address
can be carried in the Destination Node Address TLV to help detect this error . can be carried in the Destination Node Address TLV to help detect this error .
</t> </t>
</section> </section>
<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 Thierry Couture for the discussions The authors would like to thank Thierry Couture for the discussions
on the use-cases for Performance Measurement in Segment Routing. The authors on the use cases for Performance Measurement in Segment Routing. The authors
would also like to thank Greg Mirsky, Mike Koldychev, Gyan Mishra, Tianran Zh would also like to thank <contact fullname="Greg Mirsky"/>, <contact fullname
ou, ="Mike Koldychev"/>, <contact fullname="Gyan Mishra"/>, <contact fullname="Tianr
Al Mortons, Reshad Rahman, Zhenqiang Li, Frank Brockners, Henrik Nydell, an Zhou"/>,
and Cheng Li for providing comments and suggestions. Thank you Joel Halpern f <contact fullname="Al Morton"/>, <contact fullname="Reshad Rahman"/>, <contac
or t fullname="Zhenqiang Li"/>, <contact fullname="Frank Brockners"/>, <contact ful
Gen-ART review, Martin Duke for AD review, and Kathleen Moriarty for Security lname="Henrik Nydell"/>,
review. and <contact fullname="Cheng Li"/> for providing comments and suggestions. Th
The authors would like to thank Robert Wilton, Eric Vyncke, Paul Wouters, Joh ank you to <contact fullname="Joel Halpern"/> for the
n Scudder, Roman Danyliw, and Jim Guichard for IESG review.</t> Gen-ART review, <contact fullname="Martin Duke"/> for the AD review, and <con
tact fullname="Kathleen Moriarty"/> for the Security review.
The authors would also like to thank <contact fullname="Robert Wilton"/>, <co
ntact fullname="Éric Vyncke"/>, <contact fullname="Paul Wouters"/>, <contact ful
lname="John Scudder"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="
Lars Eggert"/>, <contact fullname="Erik Kline"/>, <contact fullname="Warren Kuma
ri"/>, and <contact fullname="Jim Guichard"/> for the IESG review.</t>
</section> </section>
<section numbered="false" title="Contributors"> <section numbered="false" anchor="contributors" toc="default">
<t>The following people have substantially contributed to this document:</t> <name>Contributors</name>
<t>The following person has contributed substantially to this document:</t>
<artwork><![CDATA[Daniel Voyer
Bell Canada
Email: daniel.voyer@bell.ca
]]></artwork> <contact fullname="Daniel Voyer">
</section> <organization showOnFrontPage="true">Bell Canada</organization>
<address>
<email> daniel.voyer@bell.ca</email>
</address>
</contact>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 133 change blocks. 
622 lines changed or deleted 457 lines changed or added

This html diff was produced by rfcdiff 1.48.