SPRING Working Group R. Gandhi, Ed. Internet-Draft C. Filsfils Intended status: Informational Cisco Systems, Inc. Expires: 11 April 2027 B. Janssens Colt M. Chen Huawei R. Foote Nokia 8 October 2026 Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the IPv6 (SRv6) Data Plane draft-ietf-spring-stamp-srpm-srv6-08 Abstract Segment Routing (SR) can be used to steer packets through a network employing source routing. SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for performance measurement in SRv6 networks using the Simple Two-Way Active Measurement Protocol (STAMP), as specified in RFC 8762, along with its optional extensions specified in RFC 8972 and the SR- specific extensions specified in RFC 9503. These procedures measure links and SRv6 paths (including Segment Lists of SRv6 Policies, SRv6 IGP best paths, and SRv6 IGP Flexible Algorithm (Flex-Algo) paths), as well as Layer-3 and Layer-2 services carried over those paths. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 11 April 2027. Gandhi, et al. Expires 11 April 2027 [Page 1] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Measurement Modes . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Two-Way Measurement Mode . . . . . . . . . . . . . . . . 9 4.2. One-Way Measurement Mode . . . . . . . . . . . . . . . . 10 4.3. Loopback Measurement Mode . . . . . . . . . . . . . . . . 10 4.4. Loopback with TSF Measurement Mode . . . . . . . . . . . 11 5. STAMP Reference Model . . . . . . . . . . . . . . . . . . . . 12 5.1. STAMP for One-Way Measurement Mode . . . . . . . . . . . 15 5.2. STAMP for Loopback and Loopback with TSF Measurement Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Measurement Mode Comparison for STAMP . . . . . . . . . . 16 5.3.1. STAMP TLV Applicability . . . . . . . . . . . . . . . 17 6. Encapsulations for Two-Way Measurement Mode . . . . . . . . . 18 6.1. Session-Sender Test Packet . . . . . . . . . . . . . . . 18 6.2. Session-Sender Test Packet for Links . . . . . . . . . . 18 6.3. Session-Sender Test Packet for SRv6 Data Plane . . . . . 19 6.3.1. Session-Sender Test Packet for SRv6 Paths . . . . . . 20 6.3.2. Session-Sender Test Packet for Layer-3 Services over SRv6 Path . . . . . . . . . . . . . . . . . . . . . . 23 6.3.3. Session-Sender Test Packet for Layer-2 Services over SRv6 Path . . . . . . . . . . . . . . . . . . . . . . 25 6.4. Session-Reflector Test Packet . . . . . . . . . . . . . . 27 6.4.1. Session-Reflector Test Packet for Links . . . . . . . 28 6.4.2. Session-Reflector Test Packet for SRv6 Paths . . . . 29 6.4.3. Session-Reflector Test Packet for L3 Service over SRv6 Path . . . . . . . . . . . . . . . . . . . . . . . . 29 Gandhi, et al. Expires 11 April 2027 [Page 2] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 6.4.4. Session-Reflector Test Packet for L2 Service over SRv6 Path . . . . . . . . . . . . . . . . . . . . . . . . 30 7. Encapsulations for One-Way Measurement Mode . . . . . . . . . 31 8. Encapsulations for Loopback Measurement Mode . . . . . . . . 31 8.1. Loopback Measurement Mode for Links . . . . . . . . . . . 31 8.2. Loopback Measurement Mode for SRv6 Paths . . . . . . . . 32 8.2.1. SRv6 Return Path . . . . . . . . . . . . . . . . . . 34 8.2.2. IP Return Path . . . . . . . . . . . . . . . . . . . 34 8.3. Loopback Measurement Mode for Layer-3 Services over SRv6 Path . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.3.1. SRv6 Return Path . . . . . . . . . . . . . . . . . . 36 8.3.2. IP Return Path . . . . . . . . . . . . . . . . . . . 37 8.4. Loopback Measurement Mode for Layer-2 Services over SRv6 Path . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.4.1. SRv6 Return Path . . . . . . . . . . . . . . . . . . 38 8.4.2. IP Return Path . . . . . . . . . . . . . . . . . . . 38 9. Encapsulations for Loopback with TSF Measurement Mode . . . . 38 9.1. STAMP TSF Endpoint Behaviors for SRv6 . . . . . . . . . . 39 9.1.1. TSF Endpoint Behavior Node Capability . . . . . . . . 41 10. Packet Loss Measurement in SRv6 Networks . . . . . . . . . . 41 11. Direct Measurement in SRv6 Networks . . . . . . . . . . . . . 41 12. ECMP Measurement in SRv6 Networks . . . . . . . . . . . . . . 42 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 42 13.1. Cisco Implementation . . . . . . . . . . . . . . . . . . 42 13.2. Teaparty Implementation . . . . . . . . . . . . . . . . 42 14. Operational and Manageability Considerations . . . . . . . . 43 14.1. STAMP Session State Notification . . . . . . . . . . . . 44 14.2. Operational Considerations for TSF . . . . . . . . . . . 45 15. Security Considerations . . . . . . . . . . . . . . . . . . . 45 15.1. Security Considerations for TSF . . . . . . . . . . . . 46 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 17.1. Normative References . . . . . . . . . . . . . . . . . . 47 17.2. Informative References . . . . . . . . . . . . . . . . . 49 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 51 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 1. Introduction Segment Routing (SR) [RFC8402] can be used to steer packets through a network employing source routing. SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. SR can take advantage of Equal-Cost Multipath (ECMP) between source and transit nodes, between transit nodes, and between transit and destination nodes. SR Policies, as specified in [RFC9256], are used to steer traffic through specific user-defined paths using a list of segments. Gandhi, et al. Expires 11 April 2027 [Page 3] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 A comprehensive SR performance measurement toolset is essential for measuring network performance and meeting Service Level Agreements (SLAs). The Simple Two-Way Active Measurement Protocol (STAMP), as specified in [RFC8762], provides the capability to measure various performance metrics in IP networks without the use of a control channel to pre- signal session parameters. [RFC8972] specifies optional extensions in the form of Type-Length-Value (TLV) objects for STAMP, and [RFC9503] further augments that framework to define STAMP extensions for SR networks. This document describes procedures for measuring performance in SRv6 networks using STAMP as specified in [RFC8762], along with the optional extensions specified in [RFC8972] and the SR-specific extensions specified in [RFC9503]. The procedures in this document measure links and SRv6 paths [RFC8402] (including Segment Lists of SRv6 Policies [RFC9256], SRv6 IGP best paths, and SRv6 Flexible Algorithm (Flex-Algo) paths [RFC9350]), as well as Layer-3 (L3) and Layer-2 (L2) services carried over those paths. STAMP requires protocol support as specified in [RFC8762] on the Session-Reflector to process the received STAMP-Test packets, including optional TLVs specified in [RFC8972], and to generate Session-Reflector test packets as well as reflect received TLVs. In addition, use of the UDP port in STAMP-Test packets exposes the Session-Reflector to security threats and requires rate limiting and operational considerations. These requirements necessitate that STAMP-Test packets follow an exception path (e.g., be punted from the IP- or MPLS-forwarding fast path). This results in limiting the frequency of STAMP-Test packets and the ability to provide shorter measurement intervals. This document defines new mechanisms to enhance the procedures for performance measurement using STAMP, improve scalability by supporting a larger number of STAMP sessions, and shorten the measurement interval for SRv6 paths by defining three new measurement modes: one-way, loopback, and loopback with Timestamp and Forward (TSF). The new measurement modes, loopback and loopback with TSF, take advantage of source routing. 2. Conventions Used in This Document Gandhi, et al. Expires 11 April 2027 [Page 4] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.2. Terminology This document uses terms defined in [RFC8762], specifically Session- Sender, Session-Reflector, and Session-Test packet. This document uses terms defined in [RFC6374], specifically timestamps (T1, T2, T3 and T4), the one-way delay metric, defined as (T2 - T1); the two-way delay metric, defined as ((T4 - T1) - (T3 - T2)); and the round-trip delay metric, defined as (T4 - T1). 2.3. Abbreviations +==============+====================================+===============+ | Abbreviation | Expansion | Reference | +==============+====================================+===============+ | ARP | Address Resolution Protocol | [RFC0826] | +--------------+------------------------------------+---------------+ | CSID | Compressed Segment Identifier | [RFC9800] | +--------------+------------------------------------+---------------+ | HMAC | Hashed Message Authentication | [RFC6234] | | | Code | | +--------------+------------------------------------+---------------+ | HL | Hop Limit | [RFC8200] | +--------------+------------------------------------+---------------+ | LAG | Link Aggregation Group | [IEEE802.1AX] | +--------------+------------------------------------+---------------+ | L2 | Layer-2 | [RFC4026] | +--------------+------------------------------------+---------------+ | L2VPN | Layer-2 Virtual Private | [RFC4026] | | | Network | | +--------------+------------------------------------+---------------+ | L3 | Layer-3 | [RFC4026] | +--------------+------------------------------------+---------------+ | L3VPN | Layer-3 Virtual Private | [RFC4026] | | | Network | | +--------------+------------------------------------+---------------+ | NDP | Neighbor Discovery Protocol | [RFC4861] | +--------------+------------------------------------+---------------+ | NTP | Network Time Protocol | [RFC5905] | +--------------+------------------------------------+---------------+ Gandhi, et al. Expires 11 April 2027 [Page 5] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 | OAM | Operations, Administration, | [RFC8762] | | | and Maintenance | | +--------------+------------------------------------+---------------+ | PSP | Penultimate Segment Popping | [RFC8986] | +--------------+------------------------------------+---------------+ | PTP | Precision Time Protocol | [IEEE.1588] | +--------------+------------------------------------+---------------+ | SHA | Secure Hash Algorithms | [RFC6234] | +--------------+------------------------------------+---------------+ | SID | Segment Identifier | [RFC8402] | +--------------+------------------------------------+---------------+ | SR | Segment Routing | [RFC8402] | +--------------+------------------------------------+---------------+ | SRH | Segment Routing Header | [RFC8754] | +--------------+------------------------------------+---------------+ | SRv6 | Segment Routing over the IPv6 | [RFC8402] | | | data plane | | +--------------+------------------------------------+---------------+ | SSID | STAMP Session Identifier | [RFC8972] | +--------------+------------------------------------+---------------+ | STAMP | Simple Two-Way Active | [RFC8762] | | | Measurement Protocol | | +--------------+------------------------------------+---------------+ | TLV | Type-Length-Value | [RFC8972] | +--------------+------------------------------------+---------------+ | TSF | Timestamp and Forward | This document | +--------------+------------------------------------+---------------+ | TTL | Time to Live | [RFC0791] | +--------------+------------------------------------+---------------+ | VPN | Virtual Private Network | [RFC4026] | +--------------+------------------------------------+---------------+ Table 1: Abbreviations 3. Overview For performance measurement in SRv6 networks, the STAMP Session- Sender and Session-Reflector use the STAMP-Test packets specified in [RFC8762], along with optional extensions specified in [RFC8972]. The STAMP-Test packets are encapsulated using an IP/UDP header, as specified in [RFC8762]. In this document, STAMP-Test packets use an IP/UDP header and are further encapsulated with an IPv6 Segment Routing Header (SRH) for use in SRv6 networks. In SRv6 networks, STAMP-Test packets can use one of the following measurement modes, which differ in how the Session-Reflector processes the packets: Gandhi, et al. Expires 11 April 2027 [Page 6] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 1. Two-Way measurement mode: The Session-Reflector generates and transmits Session-Reflector test packets (see Section 4.1). 2. One-Way measurement mode: The Session-Reflector does not generate and transmit Session- Reflector test packets (see Section 4.2). 3. Loopback measurement mode: The Session-Reflector does not perform STAMP processing (see Section 4.3). 4. Loopback with TSF measurement mode: The Session-Reflector writes the receive timestamp in the fast path but does not perform STAMP processing (see Section 4.4). Note that the two-way measurement mode is described as part of the STAMP process in [RFC8762] and is further described for SRv6 networks in this document. The other measurement modes are new, specific to SRv6 networks, and are not specified in [RFC8762]. STAMP-Test packets are transmitted on the same path as the data traffic flow being measured to measure the delay and packet loss experienced by the data traffic flow, using the same IPv6/SRH encapsulation. * STAMP-Test packets are transmitted on various transport data paths in the network to measure the delay and packet loss experienced by the traffic forwarded on those paths. * STAMP-Test packets are transmitted over L3 and L2 services in the network to measure the delay and packet loss experienced by the traffic carried by those services. Two encoding modes are defined in this document for STAMP-Test packets in the SRv6 data plane: Insert-Mode and Encaps-Mode. The Session-Sender generates STAMP-Test packets locally in either of the two encapsulation modes, based on local provisioning. * In Insert-Mode: An SRH is inserted after the IPv6 header of the test packets. This is further described in Section 6.3. Gandhi, et al. Expires 11 April 2027 [Page 7] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 * In Encaps-Mode: The test packets with an IP header are further encapsulated with an outer IPv6/SRH. This is further described in Section 6.3. Typically, STAMP Session-Reflector test packets are transmitted along an IP path between the Session-Reflector and Session-Sender. The forward-direction path and the return path of STAMP-Test packets are not guaranteed to match, even for directly connected nodes. In SRv6 networks, the same path (i.e., the same set of links and nodes) between the Session-Sender and Session-Reflector may be desired for the STAMP-Test packets in both directions, for example, in an ECMP environment. This is achieved as follows: * In two-way measurement mode: The optional STAMP extensions for SRv6 networks, as specified in [RFC9503], are used. The STAMP Session-Reflector uses the return path parameters for the Session-Reflector test packet from the STAMP extensions in the received Session-Sender test packet, as specified in [RFC9503]. * In loopback and loopback with TSF measurement modes: Both the forward path and the return path are included in the IPv6/SRH encapsulation of the Session-Sender test packets using source routing. The procedures in this document measure delay and packet loss in SRv6 networks by transmitting and receiving STAMP-Test packets. The optional STAMP extensions specified in [RFC8972] are used for direct measurement in SRv6 networks. The compression of an SRv6 Segment List, as specified in [RFC9800], is equally applicable to the performance measurement procedures defined in this document and can significantly reduce the size of the SRv6 encapsulation needed to transmit STAMP-Test packets over long Segment Lists. All examples described in this document using SRv6 Segment Identifiers (SIDs) can be similarly implemented using SRv6 Compressed-SIDs (CSIDs) [RFC9800]. 4. Measurement Modes In Figure 1 to Figure 4, the nodes S1 and R1 may be connected via a link or an SRv6 path [RFC8402]. The link can be a physical interface, a virtual link, a Link Aggregation Group (LAG) [IEEE802.1AX], or a LAG member link. Gandhi, et al. Expires 11 April 2027 [Page 8] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 The SRv6 path may be a Segment List of an SRv6 Policy [RFC9256] on node S1 (referred to as the "head-end") with node R1 as the destination (referred to as the "endpoint"), an SRv6 IGP best path, or an SRv6 IGP Flex-Algo path [RFC9350]. Additionally, an L3 or L2 VPN service may be carried over the SRv6 path between nodes S1 and R1. 4.1. Two-Way Measurement Mode As shown in Figure 1, in the reference topology for two-way measurement mode, the STAMP Session-Sender S1 initiates a Session- Sender test packet, and the STAMP Session-Reflector R1 generates and transmits a Session-Reflector test packet. The Session-Reflector test packets are transmitted to the Session-Sender S1 on the same path (i.e., the same set of links and nodes) or on a different path in the reverse direction from the path taken toward the Session- Reflector R1. T1 T2 / \ +-------+ Test Packet +-------+ | | - - - - - - - - - ->| | | S1 |=====================| R1 | | |<- - - - - - - - - - | | +-------+ Reply Test Packet +-------+ \ / T4 T3 STAMP Session-Sender STAMP Session-Reflector Figure 1: Reference Topology for Two-Way Measurement Mode T1 is a transmit timestamp, and T4 is a receive timestamp added by node S1. T2 is a receive timestamp, and T3 is a transmit timestamp added by node R1. All four timestamps are used by the Session-Sender to measure the two-way delay metric, defined as ((T4 - T1) - (T3 - T2)) in Section 2.4 of [RFC6374]. Timestamps T1 and T2 are used by the Session-Sender to measure the one-way delay metric, defined as (T2 - T1) in Section 2.4 of [RFC6374], also referred to as the near- end (forward direction) delay metric. Note that the delay value (T4 - T3), measured by the Session-Sender, is referred to as the far-end (backward direction) one-way delay metric. The "two-way delay" is the sum of the one-way delays in each direction and reflects the delay of the bidirectional path, irrespective of processing delays within the Session-Reflector. Gandhi, et al. Expires 11 April 2027 [Page 9] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 The computation of the one-way delay metric requires the clocks on the Session-Sender and Session-Reflector to be synchronized using either PTPv2 or NTPv4. 4.2. One-Way Measurement Mode As shown in Figure 2, in the reference topology for one-way measurement mode, the STAMP Session-Sender S1 initiates a Session- Sender test packet. The STAMP Session-Reflector does not transmit Session-Reflector test packets upon receiving the Session-Sender test packets. T1 T2 / \ +-------+ Test Packet +-------+ | | - - - - - - - - - ->| | | S1 |=====================| R1 | | | | | +-------+ +-------+ STAMP Session-Sender STAMP Session-Reflector Figure 2: Reference Topology for One-Way Measurement Mode T1 is a transmit timestamp added by node S1, and T2 is a receive timestamp added by node R1. Timestamps T1 and T2 are used by the Session-Reflector to measure the one-way delay metric, defined as (T2 - T1) in Section 2.4 of [RFC6374]. The computation of the one-way delay metric requires the clocks on the Session-Sender and Session-Reflector to be synchronized using either PTPv2 or NTPv4. 4.3. Loopback Measurement Mode As shown in Figure 3, in the reference topology for loopback measurement mode, the STAMP Session-Sender S1 initiates a Session- Sender test packet to measure the round-trip delay using source routing. At the STAMP Session-Reflector, the received STAMP-Test packets remain in the fast path in the data plane and are simply forwarded. In other words, the Session-Reflector does not perform STAMP processing or generate Session-Reflector test packets. Gandhi, et al. Expires 11 April 2027 [Page 10] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 T1 / +-------+ Test Packet +-------+ | | - - - - - - - - - - | | | S1 |====================|| R1 | | |<- - - - - - - - - - | | +-------+ Return Test Packet +-------+ \ T4 STAMP Session-Sender STAMP Session-Reflector (Loopback, Forward) Figure 3: Reference Topology for Loopback Measurement Mode The Session-Sender retrieves timestamp T1 from the received Session- Sender test packet and collects the receive timestamp T4 locally to measure the round-trip delay metric, defined as (T4 - T1) in Section 2.4 of [RFC6374]. This delay includes STAMP-Test packet processing on the Session-Reflector in the data plane. The processing delay includes only the time required to forward the test packet from the incoming interface to the outgoing interface in the data plane. The Session-Reflector does not timestamp the test packets and therefore does not require a timestamping capability. The round-trip delay is defined in [RFC2681]. 4.4. Loopback with TSF Measurement Mode As shown in Figure 4, in the reference topology for "loopback with TSF measurement mode", the STAMP Session-Sender S1 initiates a Session-Sender test packet in loopback measurement mode using source routing. The TSF mechanism is used to optimize the operation of punting the test packet from the fast path in the data plane for control-plane processing and generating the return test packet on the STAMP Session-Reflector, because timestamp writing is implemented in the fast path in the data plane. This helps achieve a higher number of STAMP sessions and faster measurement intervals. Gandhi, et al. Expires 11 April 2027 [Page 11] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 T1 T2 / \ +-------+ Test Packet +-------+ | | - - - - - - - - - - | | | S1 |====================|| R1 | | |<- - - - - - - - - - | | +-------+ Return Test Packet +-------+ \ T4 STAMP Session-Sender STAMP Session-Reflector (Loopback, TSF) Figure 4: Reference Topology for Loopback with TSF Measurement Mode The Session-Sender adds the transmit timestamp (T1) to the payload of the Session-Sender test packet. The Session-Reflector writes the receive timestamp (T2) in the received STAMP-Test packet in the fast path in the data plane, without punting the test packet from the fast path in the data plane for control-plane STAMP processing. The Session-Sender retrieves timestamps T1 and T2 from the received Session-Sender test packet and collects the receive timestamp T4 locally. Timestamps T1 and T2 are used by the Session-Sender to measure the one-way delay metric, defined as (T2 - T1) in Section 2.4 of [RFC6374]. Timestamps T1 and T4 are used by the Session-Sender to measure the round-trip delay metric, defined as (T4 - T1) in Section 2.4 of [RFC6374]. 5. STAMP Reference Model The STAMP Reference Model and typical measurement parameters for a STAMP session, as specified in [RFC8972], are shown in Figure 5. Gandhi, et al. Expires 11 April 2027 [Page 12] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 +------------+ | SDN | | Controller | +------------+ / \ Performance Measurement Mode / \ Stateful or Stateless Destination UDP Port / \ Destination UDP Port Authentication Mode / \ Authentication Mode Keychain / \ Keychain Timestamp Format / \ Timestamp Format SSID / \ SSID (Stateful) Metric Types / \ v v +-------+ +-------+ | | STAMP | | | S1 |==========| R1 | | | Session | | +-------+ +-------+ STAMP Session-Sender STAMP Session-Reflector Figure 5: STAMP Reference Model The procedure specified in [RFC8972] uses the two-way measurement mode. The base STAMP-Test packet payloads specified in [RFC8972] are transported using an IP/UDP header and a destination UDP port number [RFC6335], selected as specified in Section 4.1 of [RFC8762]. The same destination UDP port number can be used for STAMP sessions for links and SRv6 paths, and for L3 and L2 services carried over those paths. The source UDP port number is selected by the Session-Sender. The same or different source UDP port numbers may be used for different STAMP sessions. The Session-Sender and Session-Reflector IP addresses are provisioned on both endpoints of the STAMP session. In addition, SRv6 node prefix SIDs can be provisioned for the Session-Sender and the Session-Reflector and used in STAMP-Test packets instead of their IP addresses. The Session-Reflector mode can be either Stateful or Stateless, as specified in Section 4 of [RFC8762]. Stateless Session-Reflector mode is applicable only in two-way measurement mode. Gandhi, et al. Expires 11 April 2027 [Page 13] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 The SSID in each STAMP-Test packet [RFC8972] must be set to a nonzero value in both directions. The SSID in a STAMP-Test packet, along with the local configuration for the performance measurement mode, is used to identify STAMP sessions. When authentication mode is enabled for STAMP sessions, the matching Authentication Type (e.g., HMAC-SHA-256) and Keychain must be configured on both the Session-Sender and Session-Reflector [RFC8762]. Examples of timestamp formats include a 64-bit truncated Precision Time Protocol (PTPv2) timestamp [IEEE.1588] and a 64-bit Network Time Protocol (NTPv4) timestamp [RFC5905]. By default, the Session- Reflector replies using the same timestamp format as the one received in the Session-Sender test packet, as indicated by the "Z" flag in the Error Estimate field, as specified in [RFC8762]. This behavior depends on the Session-Reflector's capability. Examples of delay metrics are one-way delay, two-way delay, near-end delay (forward direction), and far-end delay (backward direction), as specified in [RFC8762]. Examples of packet loss metric types are round-trip packet loss, near-end packet loss (forward direction), and far-end packet loss (backward direction), as specified in [RFC8762]. The IPv4 TTL and IPv6 Hop Limit (HL) fields follow the specification defined in [RFC8762]. The IPv4 TTL and IPv6 HL must be set to 255 in both Session-Sender and Session-Reflector test packets, as this allows the number of hops that IP-forwarded the test packet to be determined. The IPv6 HL from the outer IPv6 header of the received STAMP-Test packet is copied into the Session-Sender TTL field of the Session-Reflector test packet. The Flow Label field in the IPv6 header of the Session-Sender test packets is set to the value used by the data packets for the IPv6 traffic flow being measured by the Session-Sender. The Session- Reflector sets the Flow Label in its test packet to the value received in the Session-Sender test packet, subject to local policy. A Software-Defined Networking (SDN) controller can be used for the configuration and management of STAMP sessions, as specified in [RFC8762]. The controller can also receive streaming telemetry of operational data. The YANG data model for STAMP, defined in [I-D.ietf-ippm-stamp-yang], can be used to configure Session-Senders and Session-Reflectors and to stream telemetry of operational data. Gandhi, et al. Expires 11 April 2027 [Page 14] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 STAMP can be used in two-way mode to collect timestamps T1, T2, T3 and T4 to compute one-way delay metric, defined as (T2 - T1) in Section 2.4 of [RFC6374], and two-way delay metric, defined as ((T4 - T1) - (T3i - T2)) in Section 2.4 of [RFC6374]. As defined in [RFC2681], round-trip delay measurement requires the destination to immediately send the packet back to the source. STAMP does not provide an accurate measurement of the round-trip delay, defined as (T4 - T1) in Section 2.4 of [RFC6374], because of the STAMP-Test packet processing time at the Session-Reflector. This processing includes handling the UDP header in the exception path, generating STAMP-Test packets, and reflecting optional TLVs. 5.1. STAMP for One-Way Measurement Mode In one-way measurement mode, the Session-Reflector operates in Stateful mode. The SSID field in the received Session-Sender test packets [RFC8972] at the Session-Reflector, along with the local configuration, is used to identify the STAMP sessions that use one-way measurement mode on the Stateful Session-Reflector. A different destination UDP port number can be selected for one-way measurement mode instead of the UDP port number used by the Session- Reflector for two-way measurement mode. The UDP port number must be chosen from the Dynamic Ports range (49152-65535) [RFC6335] to avoid conflicts with well-known and registered service ports. When the same Session-Reflector UDP port number is selected for one- way measurement mode as the UDP port number used by the Session- Reflector for two-way measurement mode, the Session-Sender requests, in the test packets, that the Session-Reflector not transmit Session- Reflector test packets. To achieve this, it must use the "No Reply Requested" flag in the Control Code Sub-TLV within the Return Path TLV defined in [RFC9503]. STAMP can be used in one-way mode to collect timestamps T1 and T2 to compute the one-way delay metric but it cannot compute the two-way and round-trip delay metrics. 5.2. STAMP for Loopback and Loopback with TSF Measurement Modes The Session-Reflector does not perform STAMP processing. Instead, in loopback and loopback with TSF measurement modes, it processes the IPv6/SRH header, ignores the UDP header, and forwards the STAMP-Test packet to the Session-Sender without modifying it. Gandhi, et al. Expires 11 April 2027 [Page 15] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 The Session-Sender must set the destination UDP port number to the UDP port number it uses to receive return Session-Reflector test packets, except for UDP port number 862, which is used by the Session-Reflector. The same UDP port number may be used as both the destination and source UDP port numbers in the Session-Sender test packets. At the Session-Sender, the "Session-Sender Sequence Number", the "Session-Sender Timestamp", the "Session-Sender Error Estimate", and the "Session-Sender TTL" fields [RFC8762] must all be set to zero in the transmitted Session-Sender test packets and must be ignored in the received test packets. STAMP can be used in the loopback measurement mode to collect timestamps T1 and T4 to compute the round-trip delay metric but it cannot compute the one-way and two-way delay metrics. STAMP can be used in the loopback with TSF measurement mode to collect timestamps T1, T2 and T4 to compute the one-way and round- trip delay metrics but it cannot compute the two-way delay metric. 5.3. Measurement Mode Comparison for STAMP +========+=========+=========+=====+============+======+===========+ |Mode |Reflector|Timestamp|Clock| Loss |Direct| Reference | | | | |Sync | Metrics | | | | | | | | Applicable | | | +========+=========+=========+=====+============+======+===========+ |Two-Way |Stateful |T1/T2/T3/|OW, | One-Way, |Yes | [RFC8762] | | |or |T4 |TW | Round-trip | | | | |Stateless| | | | | | +--------+---------+---------+-----+------------+------+-----------+ |One-Way |Stateful |T1/T2 |OW | One-Way |Yes | This | | | | | | | | document | +--------+---------+---------+-----+------------+------+-----------+ |Loopback|N/A |T1/T4 |RT | Round-trip |No | This | | | | | | | | document | +--------+---------+---------+-----+------------+------+-----------+ |Loopback|N/A |T1/T2/T4 |OW, | Round-trip |No | This | |with TSF| | |RT | | | document | +--------+---------+---------+-----+------------+------+-----------+ Table 2: Measurement Mode Comparison for STAMP OW: One-way delay metric (T2 - T1) computation requires clock synchronization. Gandhi, et al. Expires 11 April 2027 [Page 16] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 TW: Two-way delay metric ((T4 - T1) - (T3 - T2)) computation does not require clock synchronization. RT: Round-trip delay metric (T4 - T1) computation does not require clock synchronization. 5.3.1. STAMP TLV Applicability The following STAMP TLVs specified for two-way measurement mode are applicable in one-way, loopback, and loopback with TSF measurement modes: * Type 1 (Extra Padding) [RFC8972]. * Type 8 (HMAC) [RFC8972]. * Type 11 (Micro-Session ID) [RFC9534]. The following STAMP TLVs specified for two-way measurement mode are not applicable in one-way, loopback, and loopback with TSF measurement modes: * Type 2 (Location) [RFC8972]. * Type 3 (Timestamp Information) [RFC8972]. * Type 4 (Class of Service) [RFC8972]. * Type 5 (Direct Measurement) [RFC8972]. * Type 6 (Access Report) [RFC8972]. * Type 7 (Follow-Up Telemetry) [RFC8972]. * Type 9 (Destination Node IPv4 or IPv6 Address) [RFC9503]. * Type 10 (Return Path) [RFC9503]. * Type 12 (Reflected Test Packet Control) [RFC10052]. * Reflected IPv6 Extension Header Data [I-D.ietf-ippm-stamp-ext-hdr]. * Reflected Fixed Header Data [I-D.ietf-ippm-stamp-ext-hdr]. Gandhi, et al. Expires 11 April 2027 [Page 17] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 6. Encapsulations for Two-Way Measurement Mode 6.1. Session-Sender Test Packet The content of a Session-Sender test packet is shown in Figure 6. The Session-Sender test packet payload, as specified in Section 3 of [RFC8972], is transmitted with an IP header and a UDP header [RFC0768]. +---------------------------------------------------------------+ | IP Header | . Source IP Address = Session-Sender IP Address . . Destination IP Address = Session-Reflector IP Address . . IPv4 Protocol or IPv6 Next-header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header | . Source Port = Selected by Session-Sender . . Destination Port = User-configured Destination Port Or 862 . . . +---------------------------------------------------------------+ | Payload = Test Packet as specified in Figure 1 and Figure 3 | . in Section 3 of RFC 8972 . . . +---------------------------------------------------------------+ Figure 6: Content of Session-Sender Test Packet 6.2. Session-Sender Test Packet for Links The Session-Sender test packet, as shown in Figure 6, is transmitted over the link for delay measurement. The local and remote IP addresses of the link must be used as the Source IP Address and Destination IP Address in the IP header of the Session-Sender test packet, respectively. For IPv6 links, the link-local IPv6 address [RFC7404] may also be used in the IP header. The Session-Sender uses a discovery protocol or another method to obtain the peer IP and MAC addresses for the links. For example, the Session-Sender can use the Address Resolution Protocol (ARP) [RFC0826] or the Neighbor Discovery Protocol (NDP) [RFC4861] table to obtain the IP and MAC addresses for the links when transmitting STAMP packets. Note that the Session-Sender test packet is further encapsulated with an L2 header containing the Session-Reflector MAC address as the Destination MAC address and the Session-Sender MAC address as the Source MAC address for Ethernet links. Gandhi, et al. Expires 11 April 2027 [Page 18] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 For delay measurement of LAG member links, a separate STAMP micro- session is created for each member of the LAG. The STAMP extension for the Micro-Session ID TLV, as specified in [RFC9534], is used to identify each member link of the LAG associated with the STAMP micro- session on the Session-Sender and Session-Reflector. The Session- Reflector replies on the same member of the LAG in the reverse direction, based on the received Session-Sender test packet and either the local configuration or the information received from the data plane. 6.3. Session-Sender Test Packet for SRv6 Data Plane The Session-Sender generates STAMP-Test packets for the SRv6 data plane, which can be encoded in either Encaps-Mode or Insert-Mode as follows: * Encaps-Mode: When Session-Sender test packets are encoded in Encaps-Mode, they are generated with an IP header, and an outer IPv6/SRH encapsulation is added by the forwarding path in the data plane when the SRv6 path is present in the data plane. This encoding mode requires the Session-Reflector to process two IP headers and one UDP header before the STAMP-Test packets are terminated for control-plane processing. * Insert-Mode: When Session-Sender test packets are encoded in Insert-Mode, the test packets are generated with an IPv6/SRH encapsulation. For example, when explicitly configured SRv6 paths are used, these paths may not be present in the data plane. This encoding mode requires the Session-Reflector to process fewer headers before the STAMP-Test packets are terminated for control- plane processing. In both encoding modes, the timestamps are collected in the data plane, ensuring that the measured delay values are similar. Gandhi, et al. Expires 11 April 2027 [Page 19] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 A Segment List of an SRv6 Policy optionally contains the node prefix SID of the SRv6 Policy endpoint as the ultimate SID. Similarly, the L3 and L2 services steered over the SRv6 Policy also ensure that the traffic reaches the endpoint of the SRv6 Policy. Thus, there are two incoming SRv6 SIDs for the Session-Reflector in the packet: the node prefix SID for the endpoint and the SID for the L3 or L2 service. As an optimization to avoid processing additional SIDs, the Session- Sender excludes the endpoint node prefix SID when the packet carries an L3 or L2 service SID in its Segment List. The SRv6 network programming procedures are described in [RFC8986]. The procedure specified for Upper-Layer Header processing for SRv6 End SIDs in Section 4.1.1 of [RFC8986] is used to process the UDP header in the received Session-Sender test packets on the Session- Reflector. 6.3.1. Session-Sender Test Packet for SRv6 Paths A Candidate-Path of an SRv6 Policy contains one or more Segment Lists [RFC9256]. To measure delay for an SRv6 Policy, the Session-Sender must transmit test packets for each Segment List in the Candidate- Path, using a separate STAMP session for each Segment List. Each Segment List contains a number of SRv6 SIDs as specified in [RFC8986]. The Session-Sender test packets carry the Segment List in an IPv6 header and an SRv6 Segment Routing Header (SRH) [RFC8754]. A Session-Sender test packet using the same IPv6/SRH encapsulation as the data traffic on the path is shown in Figure 7. The IPv6/SRH encapsulation is encoded in Insert-Mode or Encaps-Mode. In Insert-Mode, an SRH is inserted after the IPv6 header of the test packets, as shown in Example 1 of Figure 7. In Encaps-Mode, the test packets are encapsulated in an outer IPv6 header with an SRH, as shown in Example 2 of Figure 7. Gandhi, et al. Expires 11 April 2027 [Page 20] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 +---------------------------------------------------------------+ | IPv6 Header | . Source IP Address = Session-Sender IPv6 Address . . Destination IP Address = Segment List[Segments Left] . . Next-Header = 43 (IPv6-Route) . . . +---------------------------------------------------------------+ | Routing Type = 4 (SRH) | . Segment List(0) = Session-Reflector IPv6 Address or . . Last Segment of Segment List . . . . Next-Header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 6 | . . +---------------------------------------------------------------+ Example 1: Encapsulation Using Insert-Mode Encoding +---------------------------------------------------------------+ | IPv6 Header | . Source IP Address = Session-Sender IPv6 Address . . Destination IP Address = Segment List[Segments Left] . . Next-Header = 43 (IPv6-Route) . . . +---------------------------------------------------------------+ | Routing Type = 4 (SRH) | . Segment List(0) = Session-Reflector IPv6 Address or . . Last Segment of Segment List . . . . Next-Header = 41 (IPv6) or 4 (IPv4) . . . +---------------------------------------------------------------+ | IP Header, UDP Header and Payload as shown in Figure 6 | . . +---------------------------------------------------------------+ Example 2: Encapsulation Using Encaps-Mode Encoding Figure 7: Content of Session-Sender Test Packet for SRv6 Path In the IPv6/SRH header for the Insert-Mode and in the outer IPv6/SRH header for the Encaps-Mode, the head-end node IPv6 address of the SRv6 Policy must be used as the Source IPv6 Address. The Destination IPv6 Address must be set as follows: Gandhi, et al. Expires 11 April 2027 [Page 21] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 * The next Segment in the Segment List must be used when the Segment List of the Candidate-Path of the SRv6 Policy is not empty. * Otherwise, the Session-Reflector IPv6 address must be used. In Encaps-Mode, the Session-Sender adds an inner IPv6 header whose Source IPv6 Address must be the IPv6 address of the SRv6 Policy's head-end node. There are two cases for the SRv6 Policy endpoints, as described below. 1. If the SRv6 Policy's endpoint is specified and is not the null endpoint, its IPv6 address must be used as the Destination IPv6 Address in the inner IPv6 header. In the case of Penultimate Segment Popping (PSP), the IPv6/SRH encapsulation is removed by the penultimate node. In this case, the Session-Sender must ensure that the specified Destination IPv6 Address in the inner IPv6 header causes the test packets to reach the Session-Reflector at the SRv6 Policy endpoint. 2. For an SRv6 Policy with Color-Only Destination Steering, where the endpoint is an unspecified IPv6 address (the null endpoint :: with all bits set to 0), as specified in Section 8.8.1 of [RFC9256], an IPv6 address from the Dummy IPv6 Prefix 100:0:0:1::/64 block [RFC9780] [IANA-IPv6-REG] is used as the Destination IPv6 Address in the inner IPv6 header. In this case, the Session-Sender must ensure that the Session- Sender test packets using the Segment List reach the Session- Reflector at the SRv6 Policy endpoint (for example, by adding the Prefix SID or the IPv6 address of the SRv6 Policy endpoint to the Segment List). In addition, the Session-Sender test packets may carry the "Destination Node IPv4 or IPv6 Address" STAMP TLV as defined in [RFC9503] to identify the intended Session-Reflector IP address. Each IGP Flex-Algo path in SRv6 networks [RFC9350] has Prefix SIDs advertised by the nodes. For delay measurement of SRv6 IGP Flex-Algo paths, the Session-Sender test packets carry the SRv6 Flex-Algo Prefix SIDs of the Session-Sender and Session-Reflector as the Source IPv6 Address and Destination IPv6 Address in the IPv6 header, respectively, for that SRv6 IGP Flex-Algo path under measurement. Gandhi, et al. Expires 11 April 2027 [Page 22] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 Similarly, each IGP best path in SRv6 networks [RFC9350] has Prefix SIDs advertised by the nodes. For delay measurement of SRv6 IGP best paths, the Session-Sender test packets carry the SRv6 Prefix SIDs of the Session-Sender and Session-Reflector as the Source IPv6 Address and Destination IPv6 Address in the IPv6 header, respectively, for that SRv6 best path under measurement. 6.3.2. Session-Sender Test Packet for Layer-3 Services over SRv6 Path To measure delay for an L3 service carried over an SRv6 path, the IPv6/SRH encapsulation of the data packets transmitted over the L3 service includes the L3VPN SRv6 SID instantiated on the Session- Reflector (for example, the End.DT6 SID instance, the End.DT4 SID instance, or the End.DT46 SID instance, as specified in [RFC8986]). The encapsulation of the Session-Sender test packet is shown in Figure 8 for both encoding modes: Insert-Mode and Encaps-Mode. +---------------------------------------------------------------+ | IPv6 Header | . Source IP Address = Session-Sender IPv6 Address . . Destination IP Address = Segment List[Segments Left] . . Next-Header = 43 (IPv6-Route) . . . +---------------------------------------------------------------+ | Routing Type = 4 (SRH) | . Segment List(0) = End.DT6/End.DT46 SID . . . . Next-Header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 6 | . . +---------------------------------------------------------------+ Example 1: Encapsulation Using Insert-Mode Encoding +---------------------------------------------------------------+ | IPv6 Header | . Source IP Address = Session-Sender IPv6 Address . . Destination IP Address = Segment List[Segments Left] . . Next-Header = 43 (IPv6-Route) . . . +---------------------------------------------------------------+ | Routing Type = 4 (SRH) | . Segment List(0) = End.DT4/End.DT46 SID . . . . Next-Header = 4 (IPv4) . Gandhi, et al. Expires 11 April 2027 [Page 23] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 . . +---------------------------------------------------------------+ | IPv4 Header as shown in Figure 6 | . Destination IPv4 Address in L3VPN table . . Source IPv4 Address in L3VPN table (reverse direction) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 6 | . . +---------------------------------------------------------------+ Example 2: Encapsulation Using Encaps-Mode Encoding for IPv4 +---------------------------------------------------------------+ | IPv6 Header | . Source IP Address = Session-Sender IPv6 Address . . Destination IP Address = Segment List[Segments Left] . . Next-Header = 43 (IPv6-Route) . . . +---------------------------------------------------------------+ | Routing Type = 4 (SRH) | . Segment List(0) = End.DT6/End.DT46 SID . . . . Next-Header = 41 (IPv6) . . . +---------------------------------------------------------------+ | IPv6 Header as shown in Figure 6 | . Destination IPv6 Address in L3VPN table . . Source IPv6 Address in L3VPN table (reverse direction) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 6 | . . +---------------------------------------------------------------+ Example 3: Encapsulation Using Encaps-Mode Encoding for IPv6 Figure 8: Content of Session-Sender Test Packet for L3 Service over SRv6 Path * In Insert-Mode: An SRH is inserted after the IPv6 header of the STAMP-Test packets, as shown in Example 1 of Figure 8. Gandhi, et al. Expires 11 April 2027 [Page 24] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 The ultimate End.DT6/End.DT46 SID in the Segment List is interpreted as an End SID, and local configuration on the Session- Reflector permits processing of UDP as the upper-layer header for OAM as described in Section 4.1.1 of [RFC8986]. * In Encaps-Mode: The STAMP-Test packets are encapsulated in an outer IPv6 header with an SRH, as shown in Examples 2 and 3 of Figure 8. An inner IP header is added to the Session-Sender test packets after the outer IPv6/SRH encapsulation. In both modes, the Session-Sender IPv6 address is used as the Source IPv6 Address, and the Session-Reflector IPv6 address is used as the Destination IPv6 Address in the outer IPv6 header. The IPv6 Destination Address in the inner IPv6 header must be reachable through the IPv6 table lookup associated with the added L3VPN SRv6 SID. Similarly, the IPv4 Destination Address in the inner IPv4 header must be reachable through the IPv4 table lookup associated with the added L3VPN SRv6 SID. The IPv6 Source Address in the inner IPv6 header must be reachable through the IPv6 table lookup for the reverse-direction L3 service so that the Session-Reflector test packets are returned over that service. Similarly, the IPv4 Source Address in the inner IPv4 header must be reachable through the IPv4 table lookup for the reverse- direction L3 service. 6.3.3. Session-Sender Test Packet for Layer-2 Services over SRv6 Path To measure delay for an L2 service carried over an SRv6 path, the IPv6/SRH encapsulation of the data packets transmitted over the L2 service includes the L2VPN SRv6 SID instantiated on the Session- Reflector (for example, the End.DT2U SID instance as specified in [RFC8986]). The encapsulation of the Session-Sender test packet is shown in Figure 9 for both encoding modes: Insert-Mode and Encaps-Mode. Gandhi, et al. Expires 11 April 2027 [Page 25] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 +---------------------------------------------------------------+ | IPv6 Header | . Source IP Address = Session-Sender IPv6 Address . . Destination IP Address = Segment List[Segments Left] . . Next-Header = 43 (IPv6-Route) . . . +---------------------------------------------------------------+ | Routing Type = 4 (SRH) | . Segment List(0) = End.DT2U SID . . . . Next-Header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 6 | . . +---------------------------------------------------------------+ Example 1: Encapsulation Using Insert-Mode Encoding +---------------------------------------------------------------+ | IPv6 Header | . Source IP Address = Session-Sender IPv6 Address . . Destination IP Address = Segment List[Segments Left] . . Next-Header = 43 (IPv6-Route) . . . +---------------------------------------------------------------+ | Routing Type = 4 (SRH) | . Segment List(0) = End.DT2U SID . . . . Next-Header = 41 (IPv6) . . . +---------------------------------------------------------------+ | IPv6 Header as shown in Figure 6 | . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 6 | . . +---------------------------------------------------------------+ Example 2: Encapsulation Using Encaps-Mode Encoding Figure 9: Content of Session-Sender Test Packet for L2 Service over SRv6 Path * In Insert-Mode: An SRH is inserted after the IPv6 header of the STAMP-Test packets, as shown in Example 1 of Figure 9. Gandhi, et al. Expires 11 April 2027 [Page 26] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 The ultimate End.DT2U SID in the Segment List is interpreted as an End SID, and local configuration on the Session-Reflector permits processing of UDP as the upper-layer header for OAM as described in Section 4.1.1 of [RFC8986]. * In Encaps-Mode: In addition to the outer IPv6/SRH encapsulation, an inner IPv6 header is added, as shown in Example 2 of Figure 9. The inner IPv6 header contains the Session-Sender IPv6 address as the Source IPv6 Address and the Session-Reflector IPv6 address as the Destination IPv6 Address. * For security reasons, the Router Alert IP option [RFC2113] is not used in Session-Sender or Session-Reflector test packets when STAMP-Test packets are terminated for control-plane processing, as described in [RFC6398]. In both encoding modes, the Session-Sender IPv6 address is used as the Source IPv6 Address, and the Session-Reflector IPv6 address is used as the Destination IPv6 Address in the outer IPv6 header. 6.4. Session-Reflector Test Packet In two-way measurement mode, the Session-Reflector transmits Session- Reflector test packets for links, SRv6 paths, L3 services, and L2 services in the reverse direction toward the Session-Sender. For Ethernet links, the Session-Reflector decapsulates the L2 header from the received Session-Sender test packets. For SRv6, it decapsulates the IPv6/SRH header, if present, from the received Session-Sender test packets. The Session-Reflector generates the Session-Reflector test packet using the source and destination IP addresses and UDP port numbers extracted from the received Session-Sender test packet, as shown in Figure 10. Gandhi, et al. Expires 11 April 2027 [Page 27] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 +---------------------------------------------------------------+ | IP Header | . Source IP Address . . = Session-Reflector IP Address . . Destination IP Address . . = Source IP Address from Session-Sender Test Packet . . IPv4 Protocol or IPv6 Next-header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header | . Source Port = Selected by Session-Reflector . . Destination Port . . = Source Port from Session-Sender Test Packet . . . +---------------------------------------------------------------+ | Payload = Test Packet as specified in Figure 2 and Figure 4 | . in Section 3 of RFC 8972 . . . +---------------------------------------------------------------+ Figure 10: Content of Session-Reflector Test Packet The payload contains the Session-Reflector test packet specified in Section 3 of [RFC8972]. The source UDP port number in the received UDP header is used as the destination UDP port number, and the destination UDP port number in the received UDP header is used as the source UDP port number. The source IP address in the received IP header must be used as the destination IP address, and the Session- Reflector IP address must be used as the source IP address. The Session-Reflector encapsulates the Session-Reflector test packets for transmission over links, SRv6 paths, L3 services, or L2 services in the reverse direction. For SRv6 encapsulation, the Session-Reflector encodes the Session- Reflector test packet using the same mode as the received Session- Sender test packet. 6.4.1. Session-Reflector Test Packet for Links The Session-Reflector test packet defined in Figure 10 is encapsulated with an L2 header containing the Session-Sender MAC address as the Destination MAC address and the Session-Reflector MAC address as the Source MAC address for Ethernet links. Gandhi, et al. Expires 11 April 2027 [Page 28] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 When the Session-Reflector receives the "Reply Requested on the Same Link" flag in the Control Code Sub-TLV of the Return Path TLV specified in [RFC9503], it transmits the Session-Reflector test packet over the same link in the reverse direction. 6.4.2. Session-Reflector Test Packet for SRv6 Paths When the Session-Reflector receives a Segment List sub-TLV in the Return Path TLV specified in [RFC9503], it uses that Segment List as the reverse-direction SRv6 path and encapsulates the Session- Reflector test packet with an IPv6/SRH header. The Source IPv6 Address in the added IPv6 header is set to the Session-Reflector IPv6 address. Examples of specific SRv6 return paths include: * The Segment List of the associated reverse Candidate-Path. * The Binding SID of the reverse SRv6 Policy. * The SRv6 Prefix SID of the Session-Sender. For an SRv6 IGP Flex-Algo path, the Segment List sub-TLV in the Return Path TLV carries the Session-Sender Prefix SID for the same SRv6 IGP Flex-Algo path and requests that the Session-Reflector transmit the Session-Reflector test packet over that path in the reverse direction. If a Return Path TLV containing a Segment List sub-TLV is not received, the Session-Reflector transmits the Session-Reflector test packet with additional IPv6/SRH encapsulation over the locally selected reverse-direction SRv6 path to the Session-Sender. In Insert-Mode: After adding the IPv6/SRH encapsulation, the IP header shown in Figure 10 is not added. In Encaps-Mode: After adding the IPv6/SRH encapsulation, the IP header shown in Figure 10 is added as an inner IP header. If no reverse SRv6 path can be selected, the Session-Reflector transmits the test packet shown in Figure 10 without additional IPv6/ SRH encapsulation. 6.4.3. Session-Reflector Test Packet for L3 Service over SRv6 Path In Insert-Mode: Follow the procedure described in Section 6.4.2. Gandhi, et al. Expires 11 April 2027 [Page 29] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 In Encaps-Mode: The Session-Reflector transmits Session-Reflector test packets with IPv6/SRH encapsulation for the reverse-direction L3 service as follows: * The Session-Reflector adds the IPv6/SRH encapsulation using reachability information for the Source IP Address in the inner IP header of the received test packet. This address must be reachable through the IPv4 or IPv6 table lookup associated with the received L3VPN SRv6 SID instantiated on the Session-Reflector. The Source IPv6 Address in the added IPv6 header is the Session- Reflector IPv6 address. * An inner IP header is added as shown in Figure 10. Its Destination IP Address and Source IP Address must be set to the source and destination IP addresses, respectively, from the received inner IP header. * If the Session-Reflector cannot find the corresponding reverse- direction L3 service, it must drop the test packet and must not transmit a reply test packet. 6.4.4. Session-Reflector Test Packet for L2 Service over SRv6 Path In Insert-Mode: Follow the procedure described in Section 6.4.2. In Encaps-Mode: The Session-Reflector transmits Session-Reflector test packets with IPv6/SRH encapsulation for the reverse-direction L2 service as follows: * The Session-Reflector adds the IPv6/SRH encapsulation for the corresponding reverse-direction L2 service associated with the received L2VPN SRv6 SID instantiated on the Session-Reflector. The Source IPv6 Address in the added IPv6 header is the Session- Reflector IPv6 address. * An inner IP header is added as shown in Figure 10. * If the Session-Reflector cannot find the corresponding reverse- direction L2 service, it must drop the test packet and must not transmit a reply test packet. Gandhi, et al. Expires 11 April 2027 [Page 30] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 7. Encapsulations for One-Way Measurement Mode In one-way measurement mode for links, the Session-Sender transmits STAMP-Test packets using the encapsulations defined in Section 6.2. In one-way measurement mode for SRv6 paths and for L3 and L2 services carried over those SRv6 paths, the Session-Sender transmits STAMP- Test packets using the encapsulations defined in Section 6.3. Because no Session-Reflector test packets are transmitted, the encapsulation defined in Section 6.4 does not apply. 8. Encapsulations for Loopback Measurement Mode In loopback measurement mode for links, SRv6 paths, and L3 and L2 services carried over those SRv6 paths, the Session-Sender transmits the STAMP-Test packets defined in Section 6.1. An IP header is added for the return path in the Session-Sender test packets, with its Destination IP Address must be set to the Session-Sender IP address, as shown in Figure 11, to return the test packets to the Session- Sender. +---------------------------------------------------------------+ | IP Header (Return Path) | . Source IP Address = Session-Sender IP Address . . Destination IP Address = Session-Sender IP Address . . IPv4 Protocol or IPv6 Next-header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header | . Source Port = Selected by Session-Sender . . Destination Port = Source Port . . . +---------------------------------------------------------------+ | Payload = Test Packet as specified in Figure 1 and Figure 3 | . in Section 3 of RFC 8972 . . . +---------------------------------------------------------------+ Figure 11: Content of Session-Sender Return Test Packet in Loopback Measurement Mode 8.1. Loopback Measurement Mode for Links The Session-Sender test packets in loopback measurement mode for Ethernet links are transmitted with an L2 header for the forward direction path. The L2 header contains the link MAC address at the Session-Reflector as the Destination MAC address and the link MAC address at the Session-Sender as the Source MAC address, as shown in Figure 12. Gandhi, et al. Expires 11 April 2027 [Page 31] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 +---------------------------------------------------------------+ | L2 MAC Header (Forward Path) | . Source MAC Address = Session-Sender Link MAC . . Destination MAC Address = Session-Reflector Link MAC . . Ether-Type = 0x0800 (IPv4) Or 0x86DD (IPv6) . . . +---------------------------------------------------------------+ | Test Packet as shown in Figure 11 (Return Path) | . . +---------------------------------------------------------------+ Figure 12: Content of Session-Sender Test Packet in Loopback Measurement Mode for Ethernet Link The IP header for the return path of the Session-Sender test packets is also added, with the Source IP Address and Destination IP Address both set to the Session-Sender IP address on the link to return the test packet to the Session-Sender. The Session-Reflector decapsulates the L2 header and forwards the test packet using the IP header to the Session-Sender. 8.2. Loopback Measurement Mode for SRv6 Paths In loopback measurement mode for SRv6 paths, the Session-Sender test packet carries either only the Segment List for the forward path (using Encaps-Mode encoding) or both the forward and return paths in the IPv6/SRH encapsulation (using Insert-Mode encoding), as shown in Figure 13. Gandhi, et al. Expires 11 April 2027 [Page 32] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 +---------------------------------------------------------------+ | IPv6 Header | . Source IP Address = Session-Sender IPv6 Address . . Destination IP Address = Segment List[Segments Left] . . Next-Header = 43 (IPv6-Route) . . . +---------------------------------------------------------------+ | Routing Type = 4 (SRH) | . Segment List(0) = Session-Sender IPv6 Address or . . Last Segment of Segment List of Return Path. . . . . . Next-Header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 11 | . . +---------------------------------------------------------------+ Example 1: Encapsulation Using Insert-Mode Encoding with SRv6 Return Path +---------------------------------------------------------------+ | IPv6 Header | . Source IP Address = Session-Sender IPv6 Address . . Destination IP Address = Segment List[Segments Left] . . Next-Header = 43 (IPv6-Route) . . . +---------------------------------------------------------------+ | Routing Type = 4 (SRH) | . Segment List(0) = Session-Reflector IPv6 Address or . . Last Segment of Segment List or . . . . Next-Header = 41 (IPv6) or 4 (IPv4) . . . +---------------------------------------------------------------+ | IP Header as shown in Figure 11 (Return Path) | . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 11 | . . +---------------------------------------------------------------+ Example 2: Encapsulation Using Encaps-Mode Encoding with IP Return Path Figure 13: Content of Session-Sender Test Packet in Loopback Measurement Mode for SRv6 Path Gandhi, et al. Expires 11 April 2027 [Page 33] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 In the case of an SRv6 Policy using PSP, the Session-Sender must ensure that the Session-Sender test packets using the Segment List reach the SRv6 Policy endpoint, for example, by adding the Prefix SID or IPv6 address of the SRv6 Policy endpoint to the Segment List, in both encoding modes. 8.2.1. SRv6 Return Path For the SRv6 return path, the Session-Sender test packets are encoded in Insert-Mode, as shown in Example 1 of Figure 13. The Session-Sender test packets carry the return path in the SRv6 Segment List in addition to the forward path. Examples of specific SRv6 return paths include: * The Segment List of the associated reverse Candidate-Path. * The Binding SID of the reverse SRv6 Policy. * The SRv6 Prefix SID of the Session-Sender. For SRv6 IGP Flex-Algo paths, the Session-Sender test packets carry the SRv6 Prefix SID of the Session-Sender on the same SRv6 IGP Flex- Algo path in the reverse direction. The Binding SID of the reverse SRv6 Policy can be configured on the Session-Sender using an SDN controller, for example. Encaps-Mode using an SRv6 return path does not preclude carrying an inner IP header of the IP return path. When adding SRv6 CSIDs to Session-Sender test packets for the SRv6 return path in loopback measurement mode, it is RECOMMENDED that the CSIDs be carried in a separate CSID container to avoid altering the ECMP path taken by the test packets. 8.2.2. IP Return Path For the IP return path, the Session-Sender test packets are encoded in Encaps-Mode, as shown in Example 2 of Figure 13. The Session-Sender test packets carry the Segment List of the SRv6 forward direction path only. An inner IP header for the return path is added to the Session-Sender test packets, with the Destination IP Address must be set to the Session-Sender IP address to return the test packet to the Session- Sender. Gandhi, et al. Expires 11 April 2027 [Page 34] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 The Session-Reflector decapsulates the IPv6/SRH headers and forwards the test packet using the inner IP header for the return path. 8.3. Loopback Measurement Mode for Layer-3 Services over SRv6 Path In loopback measurement mode for the L3 service carried over an SRv6 path, the IPv6/SRH encapsulation of the data packets transmitted over the L3 service, including the L3VPN SRv6 SID (e.g., the End.DT6 SID instance, the End.DT4 SID instance, etc., as specified in [RFC8986]), is used to encapsulate the Session-Sender test packets, as shown in Figure 14. +---------------------------------------------------------------+ | IPv6 Header | . Source IP Address = Session-Sender IPv6 Address . . Destination IP Address = Segment List[Segments Left] . . Next-Header = 43 (IPv6-Route) . . . +---------------------------------------------------------------+ | Routing Type = 4 (SRH) | . Segment List(0) = End.DT4/End.DT6/End.DT46 SID of Return Path. . . . . . Next-Header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 11 | . . +---------------------------------------------------------------+ Example 1: Encapsulation Using Insert-Mode Encoding with SRv6 Return Path +---------------------------------------------------------------+ | IPv6 Header | . Source IP Address = Session-Sender IPv6 Address . . Destination IP Address = Segment List[Segments Left] . . Next-Header = 43 (IPv6-Route) . . . +---------------------------------------------------------------+ | Routing Type = 4 (SRH) | . Segment List(0) = End.DT4/End.DT46 SID of Forward Path . . . . Next-Header = 4 (IPv4) . . . +---------------------------------------------------------------+ | IPv4 Header as shown in Figure 11 (Return Path) | . Destination IPv4 Address in L3VPN table . Gandhi, et al. Expires 11 April 2027 [Page 35] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 11 | . . +---------------------------------------------------------------+ Example 2: Encapsulation Using Encaps-Mode Encoding with IPv4 Return Path +---------------------------------------------------------------+ | IPv6 Header | . Source IP Address = Session-Sender IPv6 Address . . Destination IP Address = Segment List[Segments Left] . . Next-Header = 43 (IPv6-Route) . . . +---------------------------------------------------------------+ | Routing Type = 4 (SRH) | . Segment List(0) = End.DT6/End.DT46 SID of Forward Path . . . . Next-Header = 41 (IPv6) . . . +---------------------------------------------------------------+ | IPv6 Header as shown in Figure 11 (Return Path) | . Destination IPv6 Address in L3VPN table . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 11 | . . +---------------------------------------------------------------+ Example 3: Encapsulation Using Encaps-Mode Encoding with IPv6 Return Path Figure 14: Content of Session-Sender Test Packet in Loopback Measurement Mode for L3 Service over SRv6 Path 8.3.1. SRv6 Return Path For the SRv6 return path, the Session-Sender test packets are encoded in Insert-Mode, as shown in Example 1 of Figure 14. The SRv6 Segment List, excluding the L3VPN SRv6 SID instantiated on the Session-Reflector for the forward direction L3 service, is added to the IPv6/SRH encapsulation of the Session-Sender test packet. In addition, the SRv6 Segment List, including the L3VPN SRv6 SID instantiated on the Session-Sender for the reverse direction L3 service, is also added to the IPv6/SRH encapsulation to return the test packet to the Session-Sender from the Session-Reflector. Gandhi, et al. Expires 11 April 2027 [Page 36] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 Encaps-Mode using an SRv6 return path does not preclude carrying an inner IP header of the IP return path. 8.3.2. IP Return Path For the IP return path, the Session-Sender test packets are encoded in Encaps-Mode, as shown in Examples 2 and 3 of Figure 14. The SRv6 Segment List, including the L3VPN SRv6 SID instantiated on the Session-Reflector for the forward direction L3 service, is added to the IPv6/SRH encapsulation of the Session-Sender test packets sent to the Session-Reflector. An inner IP header for the return path is also added to the Session- Sender test packets, with the Destination IP Address must be set to the Session-Sender IP address to forward the test packet to the Session-Sender from the Session-Reflector. In this case, the Destination IP Address added in the inner IP header for the return path must be reachable via the IPv4 or IPv6 table lookup associated with the L3VPN SRv6 SID on the Session-Reflector. The Session-Reflector decapsulates the IPv6/SRH and forwards the Session-Sender test packet using the inner IP header, after adding IPv6/SRH encapsulation for the reverse direction L3 service. 8.4. Loopback Measurement Mode for Layer-2 Services over SRv6 Path In loopback measurement mode for the L2 service carried over an SRv6 path, the IPv6/SRH encapsulation of the data packets transmitted over the L2 service, including the L2VPN SRv6 SID (e.g., the End.DT2U SID instance, as specified in [RFC8986]), is used to encapsulate the Session-Sender test packets, as shown in Figure 15. Gandhi, et al. Expires 11 April 2027 [Page 37] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 +---------------------------------------------------------------+ | IPv6 Header | . Source IP Address = Session-Sender IPv6 Address . . Destination IP Address = Segment List[Segments Left] . . Next-Header = 43 (IPv6-Route) . . . +---------------------------------------------------------------+ | Routing Type = 4 (SRH) | . Segment List(0) = End.DT2U SID of Return Path . . . . . . Next-Header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 11 | . . +---------------------------------------------------------------+ Encapsulation Using Insert-Mode Encoding with SRv6 Return Path Figure 15: Content of Session-Sender Test Packet in Loopback Mode for L2 Service over SRv6 Path 8.4.1. SRv6 Return Path For the SRv6 return path, the Session-Sender test packets are encoded in Insert-Mode, as shown in Figure 15. The SRv6 Segment List, excluding the L2VPN SRv6 SID instantiated on the Session-Reflector for the forward direction L2 service, is added to the IPv6/SRH encapsulation of the Session-Sender test packet. In addition, the SRv6 Segment List, including the L2VPN SRv6 SID instantiated on the Session-Sender for the reverse direction L2 service, is also added to the IPv6/SRH encapsulation to return the test packet to the Session-Sender from the Session-Reflector. 8.4.2. IP Return Path The STAMP-Test packets that do not use the SRv6 return path are not supported. 9. Encapsulations for Loopback with TSF Measurement Mode The encapsulations for loopback with TSF measurement mode are defined for SRv6 paths and do not support links or L3 and L2 services carried over the SRv6 paths. Gandhi, et al. Expires 11 April 2027 [Page 38] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 9.1. STAMP TSF Endpoint Behaviors for SRv6 [RFC8986] defines SRv6 Endpoint Behaviors for SRv6 nodes. This document defines two SRv6 Endpoint Behaviors for TSF: * STAMP TSF with PTPv2 (End.TSF behavior TBA1): A 64-bit PTPv2 timestamp written at a begin offset of 16 bytes from the start of the STAMP-Test packet payload. * STAMP TSF with NTPv4 (End.TSF behavior TBA2): A 64-bit NTPv4 timestamp written at a begin offset of 16 bytes from the start of the STAMP-Test packet payload. The timestamp is written in the "Receive Timestamp" field [RFC8972], located at a begin offset of 16 bytes from the start of the STAMP- Test packet payload, as shown in the Session-Reflector test packet in Figure 2 of Section 3 of [RFC8972]. The TBA1 and TBA2 End.TSF endpoint behaviors are bound to SRv6 SIDs and instantiated on Session-Reflector nodes. For SRv6 paths in loopback with TSF measurement mode, the Session- Sender test packets carry the applicable End.TSF behavior with the target SRv6 SID in an SRH [RFC8754], as shown in Figure 16, for Insert-Mode in Example 1 and Encaps-Mode in Example 2. Gandhi, et al. Expires 11 April 2027 [Page 39] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 +---------------------------------------------------------------+ | IPv6 Header | . Source IP Address = Session-Sender IPv6 Address . . Destination IP Address = Segment List[Segments Left] . . Next-Header = 43 (IPv6-Route) . . . +---------------------------------------------------------------+ | Routing Type = 4 (SRH) | . . . . . Next-Header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 11 | . . +---------------------------------------------------------------+ Example 1: Encapsulation Using Insert-Mode Encoding with SRv6 Return Path +---------------------------------------------------------------+ | IPv6 Header | . Source IP Address = Session-Sender IPv6 Address . . Destination IP Address = Segment List[Segments Left] . . Next-Header = 43 (IPv6-Route) . . . +---------------------------------------------------------------+ | Routing Type = 4 (SRH) | . Segment List(0) = End.TSF SID . . . . Next-Header = 41 (IPv6) or 4 (IPv4) . . . +---------------------------------------------------------------+ | IP Header as shown in Figure 11 (Return Path) | . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 11 | . . +---------------------------------------------------------------+ Example 2: Encapsulation Using Encaps-Mode Encoding with IP Return Path Figure 16: Content of Session-Sender Test Packet in Loopback Measurement Mode with End.TSF for SRv6 Paths Gandhi, et al. Expires 11 April 2027 [Page 40] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 The Session-Sender test packets are encoded in Insert-Mode for the SRv6 return path and in Encaps-Mode for the IP return path, as defined in the loopback measurement mode for SRv6 paths in this document. When a Session-Reflector receives a STAMP-Test packet with the applicable End.TSF behavior for the target SRv6 SID, it writes the timestamp to the STAMP test-packet payload and forwards the test packet as defined in the loopback measurement mode for SRv6 paths. If the Session-Reflector cannot write the timestamp, it must drop the packet. 9.1.1. TSF Endpoint Behavior Node Capability The Session-Sender must determine whether the Session-Reflector can process the applicable End.TSF behavior to avoid dropping the test packets. This capability can be locally configured on the Session- Sender or signaled. Signaling extensions for this capability exchange are outside the scope of this document. 10. Packet Loss Measurement in SRv6 Networks The two-way measurement mode supports inferred measurements of round- trip packet loss, near-end packet loss (forward direction), and far- end packet loss (backward direction). However, these measurements provide only an approximate view of data packet loss. The loopback measurement mode and the loopback with TSF measurement mode, defined in this document, allow only round-trip packet loss measurement. Note that the packet loss measurement does not require the clocks on the Session-Sender and Session-Reflector to be synchronized using either PTPv2 or NTPv4. 11. Direct Measurement in SRv6 Networks The STAMP "Direct Measurement" TLV (Type 5), defined in [RFC8972], is used to measure data-packet loss. To collect direct-measurement counters for data-packet flows, STAMP-Test packets containing this TLV are transmitted using the two-way measurement-mode procedure. The procedure collects Session-Sender transmit counters and Session- Reflector receive and transmit counters. The procedure for measuring transmitted and received data-packet counters for links, SRv6 paths, and L3 and L2 services over those paths is outside the scope of this document. Gandhi, et al. Expires 11 April 2027 [Page 41] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 In loopback measurement mode and in loopback with TSF measurement mode, direct measurement is not applicable. 12. ECMP Measurement in SRv6 Networks The Segment List of an SRv6 path can have ECMP paths between the source and transit nodes, between transit nodes, and between transit and destination nodes, for example, due to: * Use of a node prefix SID [RFC8402]. * Use of an Anycast SID [RFC8402], which can result in ECMP paths via transit nodes that are part of that anycast group. To measure delay on different ECMP paths of a Segment List, the Session-Sender transmits STAMP-Test packets using the following mechanism: * Different Flow Label values [RFC6437] in the IPv6 header are used in the Session-Sender and Session-Reflector test packets to take advantage of the hashing function in the forwarding plane and influence the ECMP path taken by the packets. The considerations for loss measurement for different ECMP paths of an SRv6 path are outside the scope of this document. 13. Implementation Status Editorial note: Please remove this section prior to publication. 13.1. Cisco Implementation The following Cisco routing platforms running the IOS XR operating system have participated in interoperability testing for one-way, two-way, and loopback measurement modes for links and SRv6: * Cisco 8000 (based on Cisco Silicon One ASIC) * Cisco ASR9904 with Lightspeed line card and Tomahawk line card * Cisco NCS5500 (based on Broadcom Jericho1 ASIC) * Cisco NCS5700 (based on Broadcom Jericho2 ASIC) 13.2. Teaparty Implementation An open-source implementation of the Simple Two-Way Active Measurement Protocol [RFC8762] is available in Teaparty. Gandhi, et al. Expires 11 April 2027 [Page 42] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 https://github.com/cerfcast/teaparty An implementation of the solution specified in [RFC9503] is available at the following location: https://github.com/cerfcast/teaparty/ commit/393abf9357a6c2439877d9bcf2dc426dd89c7158 The features implemented are: 1. Destination Node IPv4 or IPv6 Address TLV. 2. Return Path TLV. There is also support for these TLVs in the Wireshark dissector: https://github.com/cerfcast/teaparty/commit/ fb74e2e02396e9bb3ead017e8d9a0c187e3573e2 Contact: William Hawkins University of Cincinnati Email: hawkinsw@obs.cr 14. Operational and Manageability Considerations The operational considerations specified in Section 5 of [RFC8762] also apply to the procedures specified in this document. Further, the operation and management considerations for performance measurement based on STAMP specified in Section 3 of [RFC8762] also apply to the procedures specified in this document. The manageability considerations described in Section 9 of [RFC8402] apply to this specification. When a destination UDP port number other than the default UDP port number 862 is used, the same network-impact study and agreement requirements specified in Section 4.1 of [RFC8762] apply. The operational considerations specified in [RFC8986] are also applicable to the procedures specified in this document. Gandhi, et al. Expires 11 April 2027 [Page 43] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 The procedures can compute delay statistics, such as the average, minimum, maximum, and variance, as well as packet-loss statistics, such as the percentage of packets lost and the number of consecutive packets lost. They can also track STAMP session-state changes. Operator alerts are generated when metrics cross user-configured thresholds or when the session state changes. When STAMP sessions are created for Segment Lists of SRv6 Policies, the scalability of the resulting number of STAMP sessions needs to be carefully considered. 14.1. STAMP Session State Notification The system generates a threshold-based notification for delay and packet-loss metrics only when the metrics change significantly. To support unambiguous monitoring, the controller needs to distinguish between an active STAMP session whose delay and packet-loss metrics have not crossed their thresholds and a failed session that is not transmitting or receiving test packets. Monitoring of the STAMP session state allows the Session-Sender to determine whether the STAMP session is idle, active, or failed and to generate state-change notifications, as specified in [I-D.ietf-ippm-stamp-ext-hdr], in two-way, loopback, and loopback with TSF measurement modes. Similarly, in one-way measurement mode, the Session-Reflector reports the STAMP session state as follows: * The Session-Reflector initially reports the STAMP session state as active when it receives one or more Session-Sender test packets. * The Session-Reflector reports the STAMP session state as failed if it does not receive N consecutive Session-Sender test packets after reporting the session as active, where N is a locally provisioned consecutive-packet-loss count. * The Session-Reflector changes the STAMP session state from failed to active when it again receives one or more Session-Sender test packets. A failed STAMP session can be related to a connectivity failure of the link, SRv6 path, or L3 or L2 service carried over that path. Gandhi, et al. Expires 11 April 2027 [Page 44] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 14.2. Operational Considerations for TSF Processing of End.TSF depends on the applicable TBA1 or TBA2 endpoint behavior and the corresponding timestamp format capability. Operators should verify that the Session-Reflector supports the applicable behavior before enabling STAMP sessions with End.TSF. Implementations should maintain counters for the following End.TSF events: * Packets with End.TSF received. * Packets in which End.TSF was invoked. * Packets with End.TSF dropped because the Endpoint Behavior was unknown. * Packets with End.TSF skipped and forwarded. * Packets with End.TSF dropped because of malformed packets. * Packets with End.TSF timestamp write failures. Successful and failed End.TSF invocations should be distinguishable. Notifications for sustained failures, malformed packets, or excessive packets with the End.TSF should be rate-limited. 15. Security Considerations The security considerations specified in [RFC8762], [RFC8972], and [RFC9503] also apply to the procedures described in this document. The measures specified in Section 7 of [RFC8762] to mitigate attacks also apply. The security considerations specified in [RFC8986] are also applicable to the procedures described in this document. The use of HMAC-SHA-256 in the authenticated mode protects the data integrity of the STAMP-Test packets. The message integrity protection using HMAC, as specified in Section 4.4 of [RFC8762], can be used with the procedures described in this document. The STAMP-Test packets with an SRH can use the HMAC authentication specified in [RFC8754]. Gandhi, et al. Expires 11 April 2027 [Page 45] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 The source UDP port number should be selected using a randomized allocation method as specified in [RFC6056] to provide protection against off-path attacks, as recommended in [RFC8085]. Furthermore, implementations must not assign STAMP Session-IDs [RFC8972] in a predictable manner to protect against off-path attacks. To avoid predictability, implementations can leverage a Cryptographically Secure Pseudorandom Number Generator [NIST-CSPRNG]. The procedures defined in this document are intended for deployment in a single network administrative domain. As such, the Session- Sender and Session-Reflector IP addresses and the forward and return paths are provisioned by the operator for the STAMP session. It is assumed that the operator has verified the integrity of the forward and return paths taken by the STAMP-Test packets. If desired, attacks can be mitigated by performing basic validation checks on the timestamp fields of reply test packets received by the Session-Sender. For example, verifying that T2 is later than T1 in the STAMP Reference Topology shown in Figure 1 requires clock synchronization between the Session-Sender and Session-Reflector. In contrast, checking that T3 is greater than or equal to T2, or that T4 is later than T1, compares timestamps generated at the same node and does not require clock synchronization. The minimal state associated with this protocol also limits the extent of measurement disruption that can be caused by a corrupt or invalid test packet to a single test cycle. STAMP-Test packets received through a transport path or a service context must be processed only in that context. This document does not provide a mechanism for cross-service OAM interactions. 15.1. Security Considerations for TSF The TSF uses the IANA-assigned endpoint behaviors TBA1 and TBA2 with timestamp formats and begin offsets. Processing of these endpoint behaviors must therefore be restricted to trusted nodes and trusted STAMP sessions. An attacker who can inject packets with End.TSF could cause unauthorized data-plane timestamping or influence measured paths. Network operators must filter IPv6 packets carrying End.TSF at administrative-domain boundaries and must restrict the behavior to Session-Reflector nodes that support the applicable behavior. The Session-Reflector writes the timestamp specified by the TBA1 or TBA2 behavior in the STAMP-Test packet payload. Implementations must validate the Endpoint Behavior, the timestamp format, and the available payload length before writing the timestamp. Gandhi, et al. Expires 11 April 2027 [Page 46] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 Implementations must perform bounds checking to prevent malformed packets from causing memory corruption, packet corruption, or denial- of-service conditions. Any malformed packet with End.TSF must be dropped. 16. IANA Considerations This document requests IANA to allocate the following code points in the First Come First Served "SRv6 Endpoint Behaviors" subregistry under the top-level "Segment Routing" registry. +=======+==========+===================+===========+============+ | Value | Hex | Endpoint Behavior | Reference | Change | | | | | | Controller | +=======+==========+===================+===========+============+ | TBA1 | TBA1-HEX | STAMP TSF with | This | IETF | | | | PTPv2 | document | | +-------+----------+-------------------+-----------+------------+ | TBA2 | TBA2-HEX | STAMP TSF with | This | IETF | | | | NTPv4 | document | | +-------+----------+-------------------+-----------+------------+ Table 3: SRv6 Endpoint Behaviors 17. References 17.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC768, August 1980, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . Gandhi, et al. Expires 11 April 2027 [Page 47] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, . [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, "Simple Two-Way Active Measurement Protocol Optional Extensions", RFC 8972, DOI 10.17487/RFC8972, January 2021, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . [RFC9503] Gandhi, R., Ed., Filsfils, C., Chen, M., Janssens, B., and R. Foote, "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks", RFC 9503, DOI 10.17487/RFC9503, October 2023, . Gandhi, et al. Expires 11 April 2027 [Page 48] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 [RFC9534] Li, Z., Zhou, T., Guo, J., Mirsky, G., and R. Gandhi, "Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group", RFC 9534, DOI 10.17487/RFC9534, January 2024, . [RFC9800] Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F. Clad, Ed., "Compressed SRv6 Segment List Encoding", RFC 9800, DOI 10.17487/RFC9800, June 2025, . [I-D.ietf-ippm-stamp-ext-hdr] Gandhi, R., Zhou, T., Li, Z., and W. Hawkins, "Simple Two- Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers", Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-ext-hdr-16, 7 October 2026, . 17.2. Informative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC791, September 1981, . [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC826, November 1982, . [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, DOI 10.17487/RFC2113, February 1997, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . Gandhi, et al. Expires 11 April 2027 [Page 49] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, . [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, . [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local Addressing inside an IPv6 Network", RFC 7404, DOI 10.17487/RFC7404, November 2014, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC6398] Internet Engineering Task Force, "IP Router Alert Considerations and Usage", November 2011, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, . [RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, February 2023, . [RFC9780] Mirsky, G., Mishra, G., and D. Eastlake 3rd, "Bidirectional Forwarding Detection (BFD) for Multipoint Networks over Point-to-Multipoint MPLS Label Switched Paths (LSPs)", RFC 9780, DOI 10.17487/RFC9780, May 2025, . Gandhi, et al. Expires 11 April 2027 [Page 50] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 [RFC10052] Mirsky, G., Ruffini, E., Nydell, H., Foote, R., and W. Hawkins, "Performance Measurement with Asymmetrical Traffic Using the Simple Two-Way Active Measurement Protocol (STAMP)", RFC 10052, DOI 10.17487/RFC10052, September 2026, . [I-D.ietf-ippm-stamp-yang] Mirsky, G., Min, X., Luo, W. S., and R. Gandhi, "Simple Two-way Active Measurement Protocol (STAMP) Data Model", Work in Progress, Internet-Draft, draft-ietf-ippm-stamp- yang-12, 5 November 2023, . [IEEE.1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", March 2008. [NIST-CSPRNG] National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators, Revision 1", NIST Special Publication 800-90A Revision 1, 2015, . [IEEE802.1AX] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation", IEEE Std 802.1AX-2020, DOI 10.1109/IEEESTD.2020.9105034, May 2020, . [IANA-IPv6-REG] IANA, "IANA IPv6 Special-Purpose Address Registry", . Acknowledgments The authors would like to thank Ianik Semco and Thierry Couture for their discussions on the use cases for Performance Measurement in Segment Routing. The authors would also like to thank Greg Mirsky, Gyan Mishra, Xie Jingrong, Zafar Ali, Boris Hassanov, Ruediger Geib, Liyan Gong, Zhenqiang Li, Maria Matejka, William Hawkins, and Mike Koldychev for reviewing this document and providing useful comments and suggestions. Additionally, Patrick Khordoc, Haowei Shi, Amila Tharaperiya Gamage, Pengyan Zhang, Ruby Lin, Senni Tan, and Radu Gandhi, et al. Expires 11 April 2027 [Page 51] Internet-Draft STAMP for Segment Routing over IPv6 October 2026 Valceanu have helped improve the mechanisms described in this document. Contributors The following people have substantially contributed to this document: Daniel Voyer Cisco Systems, Inc. Email: davoyer@cisco.com Moses Nagarajah Individual Email: mosesnehru@gmail.com Amit Dhamija Arrcus India Email: amitd@arrcus.com Authors' Addresses Rakesh Gandhi (editor) Cisco Systems, Inc. Canada Email: rgandhi@cisco.com Clarence Filsfils Cisco Systems, Inc. Email: cfilsfil@cisco.com Bart Janssens Colt Email: Bart.Janssens@colt.net Mach(Guoyi) Chen Huawei Email: mach.chen@outlook.com Richard Foote Nokia Email: footer.foote@nokia.com Gandhi, et al. Expires 11 April 2027 [Page 52]