]> Cisco Systems, Inc.

Canada rgandhi@cisco.com

Cisco Systems, Inc.

cfilsfil@cisco.com

Colt

Bart.Janssens@colt.net

Individual

mach.chen@outlook.com

Nokia

footer.foote@nokia.com

SPRING Working Group 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 defined in RFC 8762, along with its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The described procedures are used for links and SRv6 paths (including Segment Lists of SRv6 Policies, SRv6 IGP best paths, and SRv6 IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services over the SRv6 paths.

Introduction 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. SR takes advantage of Equal-Cost Multipath (ECMP) between source and transit nodes, between transit nodes, and between transit and destination nodes. SR Policies, as defined in , are used to steer traffic through specific user-defined paths using a list of segments. A comprehensive SR performance measurement toolset is an essential requirement for measuring network performance and providing Service Level Agreements (SLAs). The Simple Two-Way Active Measurement Protocol (STAMP), as specified in , provides capabilities for measuring various performance metrics in IP networks without the use of a control channel to pre-signal session parameters. defines optional extensions in the form of Type-Length-Value (TLV) objects for STAMP, and further augments that framework to define STAMP extensions for SR networks. This document describes the procedures for performance measurement in SRv6 networks using STAMP as defined in , along with its optional extensions defined in and augmented in . The described procedures are used for links and SRv6 paths (including Segment Lists of SRv6 Policies , SRv6 IGP best paths, and SRv6 Flexible Algorithm (Flex-Algo) paths ), as well as Layer-3 (L3) and Layer-2 (L2) services over the SRv6 paths. STAMP requires protocol support on the Session-Reflector to process the received test packets. As a result, the received test packets need to be punted from the fast path in the data plane, and return test packets need to be generated. This limits the frequency of STAMP test packets and the ability to provide shorter measurement intervals. This document adds new mechanisms to enhance the procedures for performance measurement using STAMP, improve the scalability of the 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).

Conventions Used in This Document

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 when, and only when, they appear in all capitals, as shown here.

Abbreviations Abbreviations

Abbreviation	Expansion	Reference
ARP	Address Resolution Protocol
CSID	Compressed Segment Identifier
GTSM	Generalized TTL Security Mechanism
HMAC	Hashed Message Authentication Code
HL	Hop Limit
LAG	Link Aggregation Group
L2	Layer-2
L2VPN	Layer-2 Virtual Private Network
L3	Layer-3
L3VPN	Layer-3 Virtual Private Network
NDP	Neighbor Discovery Protocol
NTP	Network Time Protocol
OAM	Operations, Administration, and Maintenance
PSP	Penultimate Segment Popping
PTP	Precision Time Protocol
SHA	Secure Hash Algorithms
SID	Segment Identifier
SR	Segment Routing
SRH	Segment Routing Header
SRv6	Segment Routing over the IPv6 data plane
SSID	STAMP Session Identifier
STAMP	Simple Two-Way Active Measurement Protocol
TLV	Type-Length-Value
TSF	Timestamp and Forward	This document
TTL	Time-To-Live
VPN	Virtual Private Network

Overview For performance measurement in SRv6 networks, the STAMP Session-Sender and Session-Reflector use the STAMP test packets defined in , along with optional extensions defined in . The STAMP test packets are encapsulated using an IP/UDP header, as specified in . In this document, the STAMP test packets using the IP/UDP header are used for SRv6 networks, where the STAMP test packets are further encapsulated with an IPv6 Segment Routing Header (SRH). STAMP test packets are transmitted in one of the following performance measurement modes in SRv6 networks:

1. Two-way measurement.
2. One-way measurement.
3. Loopback measurement.
4. Loopback measurement with TSF.

Note that the two-way measurement mode is described as part of the STAMP process in and is further described for SRv6 networks in this document. The other measurement modes are new, specific to SRv6 networks, and are not defined in . STAMP test packets are transmitted on the same path as the data traffic flow under measurement to measure the delay and packet loss experienced by the data traffic flow, using the same IPv6/SRH encapsulation. Similarly, 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. Furthermore, STAMP test packets carry the same IPv6/SRH headers as the data packets transmitted on the SRv6 path and over the L3 and L2 services. For encapsulating the STAMP test packets for the SRv6 data plane, two modes of encoding are defined in this document: Insert-Mode and Encaps-Mode. The Session-Sender generates the 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 .
• In Encaps-Mode, the test packets with an IP header are further encapsulated with an outer IPv6/SRH. This is further described in .

Typically, STAMP Session-Reflector test packets are transmitted along an IP path between the Session-Reflector and Session-Sender. Matching the forward-direction path and return path for STAMP test packets, even for directly connected nodes, is not guaranteed. 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 , 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 described in .
• In loopback measurement mode and loopback measurement mode with TSF, both the forward direction path and the return path are added in the IPv6/SRH encapsulation of the Session-Sender test packets.

The performance measurement procedures defined in this document are used to measure both delay and packet loss in SRv6 networks based on the transmission and reception of STAMP test packets. The optional STAMP extensions, as defined in , are used for direct measurement in SRv6 networks. The compression of an SRv6 Segment List as specified in is equally applicable to the performance measurement procedures defined in this document to 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 SIDs can be similarly implemented using SRv6 Compressed-SIDs (CSIDs) .

STAMP Reference Model The STAMP Reference Model, along with some typical measurement parameters, as defined in for a STAMP session, is shown in .

STAMP Reference Model

The procedure defined in uses the two-way measurement mode. The destination User Datagram Protocol (UDP) port number is selected for the STAMP function as described in . By default, the reflector UDP port 862 is selected as the destination UDP port for STAMP sessions for links, SRv6 paths, and for L3 and L2 services over the SRv6 paths. The source UDP port is selected by the Session-Sender. The same or different source UDP ports may be used for different STAMP sessions. Session-Reflector mode can be either Stateful or Stateless, as described in . Stateless Session-Reflector mode is applicable only in two-way measurement mode. The SSID field in the STAMP test packets , along with the local configuration for the performance measurement mode, is used to identify the 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 . Examples of the Timestamp Format include 64-bit truncated Precision Time Protocol (PTPv2) and 64-bit Network Time Protocol (NTPv4) . By default, the Session-Reflector replies using the same timestamp format as received in the Session-Sender test packet, as indicated by the "Z" flag in the Error Estimate field, as described in . This behavior depends on the Session-Reflector's capability. Examples of Delay Metrics are one-way delay, round-trip delay, near-end delay (forward direction), and far-end delay (backward direction), as defined in . 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 defined in . A Software-Defined Networking (SDN) controller can be used for the configuration and management of STAMP sessions, as described in . The controller can also receive streaming telemetry of operational data. The YANG data model for STAMP, defined in , can be used to configure Session-Senders and Session-Reflectors and to stream telemetry of operational data.

Two-Way Measurement Mode As shown in , 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 towards the Session-Reflector R1. 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 round-trip delay metric as ((T4 - T1) - (T3 - T2)). Timestamps T1 and T2 are used by the Session-Sender to measure the one-way delay metric as (T2 - T1), 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 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.

Reference Topology for Two-Way Measurement Mode | | | S1 |=====================| R1 | | |<- - - - - - - - - - | | +-------+ Reply Test Packet +-------+ \ / T4 T3 STAMP Session-Sender STAMP Session-Reflector ]]>

The nodes S1 and R1 may be connected via a link or an SRv6 path . The link can be a physical interface, a virtual link, a Link Aggregation Group (LAG) , or a LAG member link. The SRv6 path may be a Segment List of an SRv6 Policy 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 . Additionally, an L3 or L2 VPN service may be carried over the SRv6 path between nodes S1 and R1.

Session-Sender Test Packet The content of a Session-Sender test packet is shown in . The Session-Sender test packet payload, as defined in , is transmitted with an IP header and a UDP header .

Content of Session-Sender Test Packet

Session-Sender Test Packet for Links The Session-Sender test packet, as shown in , is transmitted over the link for delay measurement. The local and remote IP addresses of the link are used as the Source and Destination Addresses in the IP header of the Session-Sender test packet, respectively. For IPv6 links, the link-local address may also be used in the IP header. The Session-Sender uses a discovery protocol or other means to discover the peer IP and MAC addresses for the links. For example, the Session-Sender can use the Address Resolution Protocol (ARP) or the Neighbor Discovery Protocol (NDP) 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. 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 defined in , 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.

Session-Sender Test Packet for SRv6 Data Plane The Session-Sender generates the STAMP test packets for the SRv6 data plane, which can be encoded in either Encaps-Mode or Insert-Mode as follows.

• Encaps-Mode: When the Session-Sender test packets are encoded in Encaps-Mode, the test packets are generated with an IP header, and an outer IPv6/SRH encapsulation is added by the forwarding path in the data plane that also encapsulates the data packets (when the SRv6 path is present in the data plane). This encoding mode requires the Session-Reflector to process two IP headers and a UDP header to locally punt the test packets from the data plane to the CPU or the slow path.
• Insert-Mode: On the other hand, when the Session-Sender test packets are encoded in Insert-Mode, the test packets are generated with an IPv6/SRH encapsulation. For example, when using explicitly configured SRv6 paths, these paths may not be present in the data plane. This encoding mode requires the Session-Reflector to process fewer headers to locally punt the test packets from the data plane to the CPU or the slow path.

In both encoding modes, the timestamps are collected in the data plane, ensuring that the measured delay values are similar. A Segment List of an SRv6 Policy optionally contains the node SID of the SRv6 Policy endpoint as the ultimate SID. Similarly, the L3/L2 service steered over the SRv6 Policy also ensures 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 SID for the endpoint and the SID for the L3/L2 service. As an optimization to avoid processing additional SIDs, the Session-Sender excludes the node SID of the endpoint when carrying an L3/L2 service SID in the packet's Segment List. The SRv6 network programming procedures are described in . The procedure defined for Upper-Layer Header processing for SRv6 End SIDs in is used to process the UDP header in the received Session-Sender test packets on the Session-Reflector.

Session-Sender Test Packet for SRv6 Paths An SRv6 Policy Candidate-Path contains one or more Segment Lists . For delay measurement of an SRv6 Policy, the Session-Sender test packets are transmitted for every Segment List of the Candidate-Path of the SRv6 Policy by creating a separate STAMP session for each Segment List. Each Segment List contains a number of SRv6 SIDs as defined in . The Session-Sender test packets carry the Segment List in an IPv6 header and an SRv6 Segment Routing Header (SRH) . The content of a Session-Sender test packet for an SRv6 path using the IPv6/SRH encapsulation of the data traffic transmitted over the path is shown in . 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 . In Encaps-Mode, the test packets are encapsulated in an outer IPv6 header with an SRH, as shown in Example 2 of .

Content of Session-Sender Test Packet for SRv6 Path . . Next-Header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 3 | . . +---------------------------------------------------------------+ 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 3 | . . +---------------------------------------------------------------+ Example 2: Encapsulation Using Encaps-Mode Encoding ]]>

In the IPv6/SRH header for the Insert-Mode and in the outer IPv6/SRH header for the Encaps-Mode, the head-end node address of the SRv6 Policy is used as the Source Address. The Destination Address is set as follows:

• The next Segment in the Segment List is used when the Segment List of the Candidate-Path of the SRv6 Policy is not empty.
• Otherwise, the endpoint address of the SRv6 Policy is used when the endpoint is not null.
• Otherwise, the Session-Reflector address is used.

In Encaps-Mode, an inner IPv6 header is added that contains the head-end node address of the SRv6 Policy as the Source Address. There are two cases for the SRv6 Policy endpoints, as described below.

• The endpoint address of the SRv6 Policy is used as the Destination Address in the inner IPv6 header when it is specified and is not a null endpoint. In the case of Penultimate Segment Popping (PSP), the IPv6/SRH encapsulation is removed by the penultimate node. In this case, the specified Destination Address in the inner IPv6 header ensures that the test packets reach the Session-Reflector at the SRv6 Policy endpoint.
• For an SRv6 Policy with Color-Only Destination Steering, where the endpoint is an unspecified address (the null endpoint :: for IPv6 with all bits set to 0), as defined in , an IPv6 address from the Dummy IPv6 Prefix 100:0:0:1::/64 block is used as the Destination Address in the inner IPv6 header. In this case, the Session-Sender ensures 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, Session-Sender test packets may carry the "Destination Node IPv4 or IPv6 Address" STAMP TLV as defined in to identify the intended Session-Reflector address.

Each IGP Flex-Algo path in SRv6 networks 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 Address and Destination Address in the IPv6 header, respectively, for that SRv6 IGP Flex-Algo path under measurement. Similarly, each IGP best path in SRv6 networks 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 Address and Destination Address in the IPv6 header, respectively, for that SRv6 best path under measurement.

Session-Sender Test Packet for Layer-3 Services over SRv6 Path For delay measurement of the L3 service over an SRv6 path, the IPv6/SRH encapsulation of the data packets transmitted over the L3 service, including 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 defined in ), is used to encapsulate the Session-Sender test packets, as shown in for both encoding modes: Insert-Mode and Encaps-Mode.

Content of Session-Sender Test Packet for L3 Service over SRv6 Path . . Next-Header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 3 | . . +---------------------------------------------------------------+ 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) . . . +---------------------------------------------------------------+ | IPv4 Header as shown in Figure 3 | . Destination IPv4 Address in L3VPN table . . Source IPv4 Address in L3VPN table (reverse direction) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 3 | . . +---------------------------------------------------------------+ 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 3 | . Destination IPv6 Address in L3VPN table . . Source IPv6 Address in L3VPN table (reverse direction) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 3 | . . +---------------------------------------------------------------+ Example 3: Encapsulation Using Encaps-Mode Encoding for IPv6 ]]>

• In Insert-Mode, an SRH is inserted after the IPv6 header of the STAMP test packets, as shown in Example 1 of . In Insert-Mode, 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 .
• 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 . An inner IP header is added to the Session-Sender test packets after the outer IPv6/SRH encapsulation.

In both modes, the Session-Sender address is used as the Source Address, and the Session-Reflector address is used as the Destination Address in the outer IPv6 header. The IPv6 Destination Address added in the inner IPv6 header MUST be reachable via the IPv6 table lookup associated with the L3VPN SRv6 SID added. Similarly, the IPv4 Destination Address added in the inner IPv4 header MUST be reachable via the IPv4 table lookup associated with the L3VPN SRv6 SID that was added. The IPv6 Source Address added in the inner IPv6 header MUST be reachable via the IPv6 table lookup for the L3 service in the reverse direction to return the Session-Reflector test packets over that L3 service. Similarly, the IPv4 Source Address added in the inner IPv4 header MUST be reachable via the IPv4 table lookup for the L3 service in the reverse direction.

Session-Sender Test Packet for Layer-2 Services over SRv6 Path For delay measurement of the L2 service over an SRv6 path, the IPv6/SRH encapsulation of the data packets transmitted over the L2 service, including the L2VPN SRv6 SID instantiated on the Session-Reflector (for example, the End.DT2U SID instance as defined in ), is used to encapsulate the Session-Sender test packets, as shown in for both encoding modes: Insert-Mode and Encaps-Mode.

Content of Session-Sender Test Packet for L2 Service over SRv6 Path . . Next-Header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 3 | . . +---------------------------------------------------------------+ 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 3 | . Hop Limit = 1 . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 3 | . . +---------------------------------------------------------------+ Example 2: Encapsulation Using Encaps-Mode Encoding ]]>

• In Insert-Mode, an SRH is inserted after the IPv6 header of the STAMP test packets, as shown in Example 1 of . In Insert-Mode, 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 .
• In Encaps-Mode, in addition to the outer IPv6/SRH encapsulation, an inner IPv6 header is added, as shown in Example 2 of , with a Hop Limit (HL) value of 1 to punt the Session-Sender test packets from the data plane to the CPU or the slow path on the Session-Reflector for STAMP processing. The inner IPv6 header contains the Session-Sender address as the Source Address and the Session-Reflector address as the Destination Address.

In both encoding modes, the Session-Sender address is used as the Source Address, and the Session-Reflector address is used as the Destination Address in the outer IPv6 header.

Session-Reflector Test Packet In two-way measurement mode, the Session-Reflector test packets are transmitted on the same link or the same SRv6 path (i.e., the same set of links and nodes) in the reverse direction to the Session-Sender to perform accurate two-way delay measurement. The Session-Reflector decapsulates the IPv6/SRH header, if present, from the received Session-Sender test packets. The Session-Reflector test packet is generated using the information from the received IP/UDP header of the Session-Sender test packet, as shown in .

Content of Session-Reflector Test Packet

The payload contains the Session-Reflector test packet defined in . In the case of links, the IPv6/SRH is not present in the received Session-Sender test packet. The Session-Sender sets the "Reply Requested on the Same Link" flag in the Control Code Sub-TLV in the Return Path TLV defined in to request the Session-Reflector to transmit the Session-Reflector test packet on the same link in the reverse direction. For SRv6 paths, the Session-Sender uses the Segment List sub-TLV in the Return Path TLV defined in to request that the Session-Reflector transmit the Session-Reflector test packet on a specific SRv6 return path. Examples of specific SRv6 return paths include:

• The reverse SRv6 path associated with the forward direction SRv6 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 uses the Segment List sub-TLV in the Return Path TLV defined in to request that the Session-Reflector transmit the Session-Reflector test packet on the same SRv6 IGP Flex-Algo path in the reverse direction.

One-Way Measurement Mode As shown in , 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 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 as (T2 - T1). 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.

Reference Topology for One-Way Measurement Mode | | | S1 |=====================| R1 | | | | | +-------+ +-------+ STAMP Session-Sender STAMP Session-Reflector ]]>

STAMP Reference Model Considerations for One-Way Measurement Mode In one-way measurement mode, for links, SRv6 paths, and L3 and L2 services over the SRv6 paths, the Session-Sender test packets, as specified in for STAMP sessions, are transmitted. In one-way measurement mode, the Stateful mode of the Session-Reflector is used. The SSID field in the received Session-Sender test packets 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. Typically, a different destination UDP port is selected for one-way measurement mode than the one used by the Session-Reflector for two-way measurement mode. When the same Session-Reflector UDP port is selected for one-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 uses the "No Reply Requested" flag in the Control Code Sub-TLV within the Return Path TLV defined in .

Loopback Measurement Mode As shown in , in the reference topology for loopback measurement mode, the STAMP Session-Sender S1 initiates a Session-Sender test packet to measure the loopback delay of a bidirectional path. At the STAMP Session-Reflector, the received Session-Sender test packets are not punted out of the fast path in the data plane (i.e., to the CPU or the slow path) but are simply forwarded. In other words, the Session-Reflector does not perform STAMP functions or generate Session-Reflector test packets.

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. The loopback delay is measured as (T4 - T1). This delay includes STAMP test packet processing on the Session-Reflector. 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 timestamping capability.

STAMP Reference Model Considerations for Loopback Measurement Mode In loopback measurement mode, for links, SRv6 paths, and L3 and L2 services over the SRv6 paths, the Session-Sender test packets, as defined in for STAMP sessions, are transmitted. The IP header for the return path is added to the Session-Sender test packets, and the Destination Address is set to the Session-Sender address in the IP header, as shown in , to return the test packets to the Session-Sender.

Content of Session-Sender Return Test Packet in Loopback Measurement Mode

The Session-Reflector does not perform the STAMP process. Instead, its loopback function simply processes the IPv6/SRH headers (ignoring the UDP header) to forward the test packet back to the Session-Sender without any STAMP modifications . The SSID field in the received Session-Sender test packets at the Session-Sender, along with the local configuration for the performance measurement mode, is used to identify the STAMP sessions that use loopback measurement mode. The Session-Sender sets the destination UDP port to the UDP port it uses to receive the return Session-Reflector test packets (other than the destination UDP port 862, which is used by the Session-Reflector). The same UDP port is used as both the destination and source UDP port in the Session-Sender test packets, as shown in . At the Session-Sender, the "Session-Sender Sequence Number", the "Session-Sender Timestamp", the "Session-Sender Error Estimate", and the "Session-Sender TTL" fields are all set to zero in the transmitted Session-Sender test packets and are ignored in the received test packets.

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 on the Session-Reflector as the Destination Address and the link MAC address on the Session-Sender as the Source MAC address, as shown in .

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 and Destination Addresses set equal to the link address on the Session-Sender 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.

Loopback Measurement Mode for SRv6 Paths In loopback measurement mode for SRv6 paths, the Session-Sender test packet carries either the Segment List of the forward direction path only (using Encaps-Mode encoding), or both the forward direction and return paths in IPv6/SRH (using Insert-Mode encoding), as shown in .

Content of Session-Sender Test Packet in Loopback Measurement Mode for SRv6 Path . . . . Next-Header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 10 | . . +---------------------------------------------------------------+ 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 10 (Return Path) | . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 10 | . . +---------------------------------------------------------------+ Example 2: Encapsulation Using Encaps-Mode Encoding with IP Return Path ]]>

The Session-Sender ensures 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.

SRv6 Return Path For the SRv6 return path, the Session-Sender test packets are encoded in Insert-Mode, as shown in Example 1 of . The Session-Sender test packets, in the SRv6 Segment List, carry the return path in addition to the forward direction 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 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 for the SRv6 return path in the Session-Sender test packets in the loopback measurement mode, it is RECOMMENDED to carry it in a separate CSID container so as not to alter the ECMP path taken by the test packets.

IP Return Path For the IP return path, the Session-Sender test packets are encoded in Encaps-Mode, as shown in Example 2 of . 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 Address set to the Session-Sender address to return the test packet to the Session-Sender. The Session-Reflector decapsulates the IPv6/SRH headers and forwards the test packet using the inner IP header for the return path.

Loopback Measurement Mode for Layer-3 Services over SRv6 Path In loopback measurement mode for the L3 service 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 defined in ), is used to encapsulate the Session-Sender test packets, as shown in .

Content of Session-Sender Test Packet in Loopback Measurement Mode for L3 Service over SRv6 Path . . . . Next-Header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 10 | . . +---------------------------------------------------------------+ 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 10 (Return Path) | . Destination IPv4 Address in L3VPN table . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 10 | . . +---------------------------------------------------------------+ 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 10 (Return Path) | . Destination IPv6 Address in L3VPN table . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 10 | . . +---------------------------------------------------------------+ Example 3: Encapsulation Using Encaps-Mode Encoding with IPv6 Return Path ]]>

SRv6 Return Path For the SRv6 return path, the Session-Sender test packets are encoded in Insert-Mode, as shown in Example 1 of . 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. Encaps-Mode using an SRv6 return path does not preclude carrying an inner IP header of the IP return path.

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 . 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 to encapsulate 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 Address set to the Session-Sender address to forward the test packet to the Session-Sender from the Session-Reflector. In this case, the Destination 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.

Loopback Measurement Mode for Layer-2 Services over SRv6 Path In loopback measurement mode for the L2 service 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 defined in ), is used to encapsulate the Session-Sender test packets, as shown in .

Content of Session-Sender Test Packet in Loopback Mode for L2 Service over SRv6 Path . . . . Next-Header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 10 | . . +---------------------------------------------------------------+ Encapsulation Using Insert-Mode Encoding with SRv6 Return Path ]]>

SRv6 Return Path For the SRv6 return path, the Session-Sender test packets are encoded in Insert-Mode, as shown in . 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.

IP Return Path The STAMP test packets that do not use the SRv6 return path are not supported.

Loopback Measurement Mode with TSF As shown in , in the reference topology for "loopback measurement mode with TSF", the STAMP Session-Sender S1 initiates a Session-Sender test packet in loopback measurement mode. The TSF mechanism is used to optimize the "operation of punting the test packet and generating the return test packet" on the STAMP Session-Reflector, as timestamping is implemented in the fast path in the data plane. This helps achieve a higher number of STAMP sessions and faster measurement intervals.

Reference Topology for Loopback Measurement Mode with TSF

The Session-Sender retrieves the 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 as (T2 - T1). Timestamps T1 and T4 are used by the Session-Sender to measure the loopback delay metric as (T4 - T1). The Session-Sender adds the transmit timestamp (T1) to the payload of the Session-Sender test packet. The Session-Reflector adds the receive timestamp (T2) to the payload of the received test packet in the fast path in the data plane, without punting the test packet (e.g., to the CPU or the slow path) for STAMP packet processing.

Loopback Measurement Mode with TSF Endpoint Behavior for SRv6 Data Plane defines SRv6 Endpoint Behaviors for SRv6 nodes. A new SRv6 Endpoint Behavior, the "Timestamp and Forward (End.TSF)" (value TBA1), is defined for STAMP test packets. In the Session-Sender test packets for SRv6 paths, the End.TSF is carried with the target Segment Identifier (SID) in the SRH , as shown in , for both Insert-Mode and Encaps-Mode encoding, to collect timestamps in the "Receive Timestamp" field in the payload of the test packet from the Session-Reflector.

Content of Session-Sender Test Packet in Loopback Measurement Mode with End.TSF for SRv6 Paths . . . . Next-Header = 17 (UDP) . . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 10 | . . +---------------------------------------------------------------+ 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 10 (Return Path) | . . +---------------------------------------------------------------+ | UDP Header and Payload as shown in Figure 10 | . . +---------------------------------------------------------------+ Example 2: Encapsulation Using Encaps-Mode Encoding with IP Return Path ]]>

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 test packet with the End.TSF for the target SID, which is local, it timestamps the test packet at a specific offset and then forwards the test packet as defined in the loopback measurement mode for SRv6 paths. If the Session-Reflector cannot timestamp the packet because it is malformed, it must drop the packet otherwise it may forward it based on local policy.

TSF Endpoint Behavior Assignment and Node Capability A new SRv6 Endpoint Behavior, "Timestamp and Forward (End.TSF)", bound to an SRv6 SID and instantiated on the Session-Reflector node, with value TBA1 (to be assigned by IANA), is defined in this document and has the following properties.

• The timestamp format (e.g., 64-bit PTPv2 or NTPv4), to be added to the Session-Sender test packet payload, is locally configured for the End.TSF.
• The offset in the Session-Sender test packet payload (e.g., STAMP test packet in Figure 5 with an offset of 16 bytes for Receive Timestamp) is similarly locally configured for the End.TSF.

The Session-Sender needs to know if the Session-Reflector is capable of processing the End.TSF 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.

Packet Loss Measurement in SRv6 Networks The procedure described for two-way measurement mode allows for round-trip, near-end (forward direction), and far-end (backward direction) inferred packet loss measurement. However, this provides only an approximate view of the data packet loss. The loopback measurement mode and loopback measurement mode with TSF, 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.

Direct Measurement in SRv6 Networks The STAMP "Direct Measurement" TLV (Type 5), defined in , is used for data packet loss measurement. The STAMP test packets with this TLV are transmitted using the procedure described for two-way measurement mode for collecting the Session-Sender transmit counters and Session-Reflector receive and transmit counters of the data packet flows for direct measurement. The receive data traffic can be measured as follows:

• The Path Segment Identifier (PSID) of the SRv6 Policy (for the Segment List or for the Candidate-Path) may be carried in the data packets to measure received data traffic (for the receive packet counter) on the associated SRv6 path when the egress node supports PSID processing.
• In the case of L3 and L2 services over the SRv6 paths, the associated SRv6 service SIDs are used to measure received data traffic (for the receive packet counters) on the Session-Reflector.

In loopback measurement mode and loopback measurement mode with TSF, direct measurement is not applicable.

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, due to, for example:

• The usage of a node SID .
• The usage of an Anycast SID , which can result in ECMP paths via transit nodes that are part of that anycast group.

The STAMP test packets are transmitted to traverse different ECMP paths to measure the delay of each ECMP path of a Segment List, and can use the following mechanism:

• Different Flow Label values 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.

STAMP Session State The threshold-based notification for delay and packet loss metrics is generated only when the metrics change significantly. For unambiguous monitoring, the controller needs to distinguish whether the STAMP session is active but delay and packet loss metrics did not cross the thresholds, or if the STAMP session has failed and is not transmitting or receiving test packets. The STAMP session state monitoring allows the node to determine whether the performance measurement test is active, idle, or failed. The failed state of the STAMP session also indicates the connectivity failure of the link, SRv6 path, or L3/L2 service over the SRv6 path, where the STAMP session was active. In all measurement modes, the STAMP session state is notified as idle when the Session-Sender is not transmitting test packets. In two-way, loopback measurement mode, and loopback measurement mode with TSF, STAMP session state is notified on Session-Sender as follows:

• The STAMP session state is initially notified as active on the Session-Sender when the Session-Sender is transmitting test packets and at least one Session-Reflector test packet has been received.
• The STAMP session state is notified as failed when N consecutive Session-Reflector test packets are not received at the Session-Sender after the STAMP session state is notified as active, where N (the consecutive packet loss count) is a locally provisioned value.

Similarly, in one-way measurement mode, STAMP session state is notified on Session-Reflector as follows:

• The STAMP session state is initially notified as active on the Session-Reflector once one or more Session-Sender test packets are received.
• The STAMP session state is notified as failed when N consecutive Session-Sender test packets are not received at the Session-Reflector after the STAMP session state is notified as active, where N (the consecutive packet loss count) is a locally provisioned value.

Additional STAMP Test Packet Processing Rules

TTL The TTL field in the IPv4 headers of the Session-Sender and Session-Reflector test packets is set to 255, as per the Generalized TTL Security Mechanism (GTSM) .

IPv6 Hop Limit The HL field in all IPv6 headers of the Session-Sender and Session-Reflector test packets is set to 255, as per the Generalized TTL Security Mechanism (GTSM) , except for the inner IPv6 header used for L2 services over SRv6 paths, where an HL value of 1 is used to punt the test packets to the CPU or the slow path for STAMP processing.

Router Alert Option The Router Alert IP option is not required in the Session-Sender and Session-Reflector test packets to punt the STAMP test packets from the data plane to the CPU or the slow path.

IPv6 Flow Label 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 uses the Flow Label value received in the IPv6 header of the Session-Sender test packet for the Session-Reflector test packet, which can be based on a local policy.

UDP Checksum For IPv6 STAMP test packets, where the local processor, after adding the timestamp, is not capable of re-computing the UDP checksum or adding a checksum complement , the Session-Sender and Session-Reflector use the procedure defined in for the UDP checksum (with the value set to 0) for UDP ports used in STAMP sessions, which can be based on a local policy.

Implementation Status Editorial note: Please remove this section prior to publication.

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)

Teaparty Implementation An open-source implementation of the Simple Two-Way Active Measurement Protocol is available in Teaparty. https://github.com/cerfcast/teaparty An implementation of the solution defined in is available at the following location: https://github.com/cerfcast/teaparty/commit/393abf9357a6c2439877d9bcf2dc426dd89c7158 The features implemented are: 1. Destination Node 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

Operational and Manageability Considerations The operational considerations described in and the manageability considerations described in apply to this specification. Various statistics for one-way (near-end, far-end), round-trip, and loopback delay metrics (such as average delay, minimum delay, maximum delay, and delay variance), as well as for one-way (near-end, far-end) or round-trip packet loss metrics (such as percentage loss and consecutive packets lost), and STAMP session state changes can be computed using the performance measurement procedures described in this document. Operator alerts are generated for anomaly detection when delay or loss metrics cross user-configured thresholds or when the STAMP session state changes. When STAMP sessions are created for the Segment Lists of the SRv6 Policies, the scalability regarding the number of STAMP sessions needs to be carefully considered.

Operational Considerations for TSF The End.TSF processing depends on consistent configuration of the Endpoint Behavior, timestamp format, timestamp offset, and Session-Reflector capabilities. Operators should verify this configuration before enabling STAMP sessions with End.TSF. The configured End.TSF parameters should be included in operational state and made available to the Session-Sender and Session-Reflector management systems. Implementations should maintain counters for the following End.TSF events:

• Packets with End.TSF received.
• Number of End.TSF invocations.
• Packets with End.TSF dropped because the Endpoint Behavior was unknown.
• Packets with End.TSF skipped and forwarded.
• Timestamp insertion failures.
• Malformed packets dropped with End.TSF.

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.

Security Considerations The security considerations specified in , , and also apply to the procedures described in this document. The measures specified in to mitigate attacks using the registered UDP port apply to the UDP ports used by STAMP sessions. Furthermore, implementations should not assign STAMP Session Identifiers (SSIDs) in a predictable manner. To avoid predictability, implementations can leverage a Cryptographically Secure Pseudorandom Number Generator . The use of HMAC-SHA-256 in authenticated mode protects the data integrity of the STAMP test packets. The message integrity protection using HMAC, as defined in , can be used with the procedures described in this document. The procedures defined in this document are intended for deployment in a single network administrative domain. As such, the Session-Sender address, Session-Reflector address, and the forward direction 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 direction and return paths of the STAMP test packets. When using the procedures defined in , the security considerations specified in also apply. The STAMP test packets for SRv6 can use the HMAC authentication defined for SRH in . The security considerations specified in are also applicable to the procedures defined in this document. 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.

Security Considerations for TSF The End.TSF is a locally configured Endpoint Behavior on Session-Reflector and Session-Sender nodes. Its processing therefore needs to be restricted to trusted nodes and trusted STAMP sessions. An attacker that can inject packets with the End.TSF could cause unauthorized data-plane timestamping or influence measured paths. Network operators must filter IPv6 packets carrying the End.TSF at administrative-domain boundaries and should restrict the behavior to the Session-Reflector nodes for which it is configured. The Session-Reflector writes a timestamp into the STAMP test packet payload at a configured offset. Implementations must validate the Endpoint Behavior, timestamp format, timestamp offset, and available payload length before writing the timestamp. Bounds-checking is required to prevent malformed packets from causing memory corruption, packet corruption, or denial-of-service conditions. Any malformed packet with the End.TSF must be dropped.

IANA Considerations This document requests IANA to allocate the following codepoint within the First Come First Served, "SRv6 Endpoint Behaviors" subregistry, under the top-level "Segment Routing" registry. SRv6 Endpoint Behaviors

Value	Hex	Endpoint Behavior	Reference	Change Controller
TBA1	TBA1-HEX	Timestamp and Forward (TSF)	This document	IETF

References Normative References &RFC0768; &RFC2119; &RFC4026; &RFC5082; &RFC6234; &RFC8174; &RFC8200; &RFC8762; &RFC8972; &RFC8986; &RFC9503; &RFC9534; &RFC9800; Informative References &RFC0826; &RFC2113; &RFC4861; &RFC5905; &RFC6437; &RFC6936; &RFC7404; &RFC7820; &RFC8402; &RFC8754; &RFC9256; &RFC9350; &RFC9780; &I-D.ietf-ippm-stamp-yang; &I-D.ietf-spring-srv6-path-segment; IEEE National Institute of Standards and Technology IEEE IANA

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 Valceanu have helped improve the mechanisms described in this document.

Contributors The following people have substantially contributed to this document: