Internet-Draft STAMP for Segment Routing over IPv6 August 2026
Gandhi, et al. Expires 19 February 2027 [Page]
Workgroup:
SPRING Working Group
Internet-Draft:
draft-ietf-spring-stamp-srpm-srv6-03
Published:
Intended Status:
Informational
Expires:
Authors:
R. Gandhi, Ed.
Cisco Systems, Inc.
C. Filsfils
Cisco Systems, Inc.
B. Janssens
Colt
M. Chen
Individual
R. Foote
Nokia

Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over IPv6 (SRv6) Data Plane

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 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.

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 19 February 2027.

▲

Table of Contents

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 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 [RFC9256], 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 [RFC8762], provides capabilities for measuring various performance metrics in IP networks without the use of a control channel to pre-signal session parameters. [RFC8972] defines 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 the procedures for performance measurement in SRv6 networks using STAMP as defined in [RFC8762], along with its optional extensions defined in [RFC8972] and augmented in [RFC9503]. The described procedures are used for 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 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).

2. Conventions Used in This Document

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. Abbreviations

Table 1: Abbreviations
Abbreviation Expansion Reference
ARP Address Resolution Protocol [RFC0826]
CSID Compressed Segment Identifier [RFC9800]
GTSM Generalized TTL Security Mechanism [RFC5082]
HMAC Hashed Message Authentication Code [RFC6234]
HL Hop Limit [RFC8200]
LAG Link Aggregation Group [IEEE802.1AX]
L2 Layer-2 [RFC4026]
L2VPN Layer-2 Virtual Private Network [RFC4026]
L3 Layer-3 [RFC4026]
L3VPN Layer-3 Virtual Private Network [RFC4026]
NDP Neighbor Discovery Protocol [RFC4861]
NTP Network Time Protocol [RFC5905]
OAM Operations, Administration, and Maintenance [RFC8762]
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 data plane [RFC8402]
SSID STAMP Session Identifier [RFC8972]
STAMP Simple Two-Way Active Measurement Protocol [RFC8762]
TLV Type-Length-Value [RFC8972]
TSF Timestamp and Forward This document
TTL Time-To-Live [RFC5082]
VPN Virtual Private Network [RFC4026]

3. Overview

For performance measurement in SRv6 networks, the STAMP Session-Sender and Session-Reflector use the STAMP test packets defined in [RFC8762], along with optional extensions defined in [RFC8972]. The STAMP test packets are encapsulated using an IP/UDP header, as specified in [RFC8762]. 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 [RFC8762] 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 [RFC8762].

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.

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:

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 [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 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) [RFC9800].

3.1. STAMP Reference Model

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

                            +------------+
                            |    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 1: STAMP Reference Model

The procedure defined in [RFC8972] uses the two-way measurement mode.

The destination User Datagram Protocol (UDP) port number is selected for the STAMP function as described in [RFC8762]. By default, the reflector UDP port 862 is selected as the destination UDP port for STAMP sessions [RFC8762] 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 Section 4 of [RFC8762]. Stateless Session-Reflector mode is applicable only in two-way measurement mode.

The SSID field in the STAMP test packets [RFC8972], 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 [RFC8762].

Examples of the Timestamp Format include 64-bit truncated Precision Time Protocol (PTPv2) [IEEE.1588] and 64-bit Network Time Protocol (NTPv4) [RFC5905]. 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 [RFC8762]. 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 [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 defined in [RFC8762].

A Software-Defined Networking (SDN) controller can be used for the configuration and management of STAMP sessions, as described 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.

4. Two-Way Measurement Mode

As shown in Figure 2, 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.

                       T1                T2
                      /                   \
             +-------+     Test Packet     +-------+
             |       | - - - - - - - - - ->|       |
             |   S1  |=====================|   R1  |
             |       |<- - - - - - - - - - |       |
             +-------+  Reply Test Packet  +-------+
                      \                   /
                       T4                T3

       STAMP Session-Sender          STAMP Session-Reflector
Figure 2: Reference Topology for Two-Way Measurement Mode

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. 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. Session-Sender Test Packet

The content of a Session-Sender test packet is shown in Figure 3. The Session-Sender test packet payload, as defined 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 = Chosen by Session-Sender                       .
 .  Destination Port = User-configured Destination Port Or 862   .
 .                                                               .
 +---------------------------------------------------------------+
 | Payload = Test Packet as specified in Section 3 of RFC 8972   |
 .           in Figures 1 and 3                                  .
 .                                                               .
 +---------------------------------------------------------------+
Figure 3: Content of Session-Sender Test Packet

4.2. Session-Sender Test Packet for Links

The Session-Sender test packet, as shown in Figure 3, 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 [RFC7404] 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) [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.

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 [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.

4.3. 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 [RFC8986]. The procedure defined 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.

4.3.1. Session-Sender Test Packet for SRv6 Paths

An SRv6 Policy Candidate-Path contains one or more Segment Lists [RFC9256]. 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 [RFC8986]. The Session-Sender test packets carry the Segment List in an IPv6 header and an SRv6 Segment Routing Header (SRH) [RFC8754].

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 Figure 4. 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 4. In Encaps-Mode, the test packets are encapsulated in an outer IPv6 header with an SRH, as shown in Example 2 of Figure 4.

 +---------------------------------------------------------------+
 | 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               .
 .  <Remaining Segment List of Forward 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               .
 .  <Remaining Segment List of Forward Path>                     .
 .  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
Figure 4: 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 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 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 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 [RFC9503] to identify the intended Session-Reflector 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 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 [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 Address and Destination Address in the IPv6 header, respectively, for that SRv6 best path under measurement.

4.3.2. 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 [RFC8986]), is used to encapsulate the Session-Sender test packets, as shown in Figure 5 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                       .
 .  <Remaining Segment List of Forward 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                       .
 .  <Remaining Segment List of Forward Path>                     .
 .  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                       .
 .  <Remaining Segment List of Forward Path>                     .
 .  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
Figure 5: 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 5. 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 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 5. 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.

4.3.3. 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 [RFC8986]), is used to encapsulate the Session-Sender test packets, as shown in Figure 6 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.DT2U SID                               .
 .  <Remaining Segment List of Forward 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                               .
 .  <Remaining Segment List of Forward Path>                     .
 .  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
Figure 6: 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 6. 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 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 6, 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.

4.4. 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 Figure 7.

 +---------------------------------------------------------------+
 | 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 = Chosen by Session-Reflector                    .
 .  Destination Port                                             .
 .     = Source Port from Session-Sender Test Packet             .
 .                                                               .
 +---------------------------------------------------------------+
 | Payload = Test Packet as specified in Section 3 of RFC 8972   |
 .           in Figures 2 and 4                                  .
 .                                                               .
 +---------------------------------------------------------------+
Figure 7: Content of Session-Reflector Test Packet

The payload contains the Session-Reflector test packet defined in Section 3 of [RFC8972].

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 [RFC9503] 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 [RFC9503] 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 [RFC9503] to request that the Session-Reflector transmit the Session-Reflector test packet on the same SRv6 IGP Flex-Algo path in the reverse direction.

5. One-Way Measurement Mode

As shown in Figure 8, 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.

                       T1                T2
                      /                   \
             +-------+     Test Packet     +-------+
             |       | - - - - - - - - - ->|       |
             |   S1  |=====================|   R1  |
             |       |                     |       |
             +-------+                     +-------+

       STAMP Session-Sender          STAMP Session-Reflector
Figure 8: Reference Topology for One-Way Measurement Mode

5.1. 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 Section 4 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 [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.

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 [RFC9503].

6. Loopback Measurement Mode

As shown in Figure 9, 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.

                       T1
                      /
             +-------+     Test Packet     +-------+
             |       | - - - - - - - - - - |       |
             |   S1  |====================||   R1  |
             |       |<- - - - - - - - - - |       |
             +-------+  Return Test Packet +-------+
                      \
                       T4

       STAMP Session-Sender          STAMP Session-Reflector
                                           (Loopback,
                                            Forward)
Figure 9: 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.

6.1. 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 Section 4 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 Figure 10, 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 = Chosen by Session-Sender                       .
 .  Destination Port = Source Port                               .
 .                                                               .
 +---------------------------------------------------------------+
 | Payload = Test Packet as specified in Section 3 of RFC 8972   |
 .           in Figures 1 and 3                                  .
 .                                                               .
 +---------------------------------------------------------------+
Figure 10: 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 [RFC8762].

The SSID field in the received Session-Sender test packets [RFC8972] 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 Figure 10.

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.

6.2. 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 Figure 11.

 +---------------------------------------------------------------+
 | L2 MAC Header (Forward Path)                                  |
 .  Source Address = Link MAC Address on Session-Sender          .
 .  Destination Address = Link MAC Address on Session-Reflector  .
 .  Ether-Type = 0x0800 (IPv4) Or 0x86DD (IPv6)                  .
 .                                                               .
 +---------------------------------------------------------------+
 | Test Packet as shown in Figure 10 (Return Path)               |
 .                                                               .
 +---------------------------------------------------------------+
Figure 11: 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.

6.3. 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 Figure 12.

 +---------------------------------------------------------------+
 | 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.
 .  <Remaining Segment List for Return Path>                     .
 .  <Segment List for Forward 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            .
 .  <Remaining Segment List of Forward Path>                     .
 .  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
Figure 12: Content of Session-Sender Test Packet in Loopback Measurement Mode for SRv6 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.

6.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 12.

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.

6.3.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 12.

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.

6.4. 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 [RFC8986]), is used to encapsulate the Session-Sender test packets, as shown in Figure 13.

 +---------------------------------------------------------------+
 | 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.
 .  <Remaining Segment List of Return Path>                      .
 .  <Segment List of Forward 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       .
 .  <Remaining Segment List 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       .
 .  <Remaining Segment List 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
Figure 13: Content of Session-Sender Test Packet in Loopback Measurement Mode for L3 Service over SRv6 Path

6.4.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 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.

6.4.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 13.

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.

6.5. 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 [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.DT2U SID of Return Path                .
 .  <Remaining Segment List of Return Path>                      .
 .  <Segment List of Forward Path>                               .
 .  Next-Header = 17 (UDP)                                       .
 .                                                               .
 +---------------------------------------------------------------+
 | UDP Header and Payload as shown in Figure 10                  |
 .                                                               .
 +---------------------------------------------------------------+

   Encapsulation Using Insert-Mode Encoding with SRv6 Return Path
Figure 14: Content of Session-Sender Test Packet in Loopback Mode for L2 Service over SRv6 Path

6.5.1. SRv6 Return Path

For the SRv6 return path, the Session-Sender test packets are encoded in Insert-Mode, as shown in Figure 14.

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.

6.5.2. IP Return Path

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

7. Loopback Measurement Mode with TSF

As shown in Figure 15, 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.

                       T1                T2
                      /                   \
             +-------+     Test Packet     +-------+
             |       | - - - - - - - - - - |       |
             |   S1  |====================||   R1  |
             |       |<- - - - - - - - - - |       |
             +-------+  Return Test Packet +-------+
                      \
                       T4

       STAMP Session-Sender          STAMP Session-Reflector
                                           (Loopback,
                                            TSF)
Figure 15: 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.

7.1. Loopback Measurement Mode with TSF Endpoint Behavior for SRv6 Data Plane

[RFC8986] 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 [RFC8754], as shown in Figure 16, 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.

 +---------------------------------------------------------------+
 | 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 for Return Path>                               .
 .  <Segment List for Forward Path including End.TSF SID>        .
 .  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                                .
 .  <Remaining Segment List of Forward Path>                     .
 .  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
Figure 16: Content of Session-Sender Test Packet in Loopback Measurement Mode with End.TSF for SRv6 Paths

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.

7.1.1. 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 [RFC8762] 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.

8. 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.

9. Direct Measurement in SRv6 Networks

The STAMP "Direct Measurement" TLV (Type 5), defined in [RFC8972], 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:

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

10. 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 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:

The considerations for loss measurement for different ECMP paths of an SRv6 path are outside the scope of this document.

11. 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:

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

12. Additional STAMP Test Packet Processing Rules

12.1. 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) [RFC5082].

12.2. IPv6 Hop Limit

The HL field [RFC8200] 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) [RFC5082], 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.

12.3. Router Alert Option

The Router Alert IP option [RFC2113] 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.

12.4. IPv6 Flow Label

The Flow Label field [RFC8200] 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.

12.5. 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 [RFC7820], the Session-Sender and Session-Reflector use the procedure defined in [RFC6936] 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.

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.

https://github.com/cerfcast/teaparty

An implementation of the solution defined in [RFC9503] 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

14. Operational and Manageability Considerations

The operational considerations described in Section 5 of [RFC8762] and the manageability considerations described in Section 9 of [RFC8402] 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.

14.1. 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.

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 using the registered UDP port apply to the UDP ports used by STAMP sessions.

Furthermore, implementations should not assign STAMP Session Identifiers (SSIDs) [RFC8972] in a predictable manner. To avoid predictability, implementations can leverage a Cryptographically Secure Pseudorandom Number Generator [NIST-CSPRNG].

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 Section 4.4 of [RFC8762], 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 [RFC6936], the security considerations specified in [RFC6936] also apply.

The STAMP test packets for SRv6 can use the HMAC authentication defined for SRH in [RFC8754].

The security considerations specified in [RFC8986] 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.

15.1. 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.

16. 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.

Table 2: SRv6 Endpoint Behaviors
Value Hex Endpoint Behavior Reference Change Controller
TBA1 TBA1-HEX Timestamp and Forward (TSF) This document IETF

17. References

17.1. Normative References

[RFC0768]
Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC768, , <https://www.rfc-editor.org/info/rfc768>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4026]
Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, , <https://www.rfc-editor.org/info/rfc4026>.
[RFC5082]
Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, , <https://www.rfc-editor.org/info/rfc5082>.
[RFC6234]
Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, , <https://www.rfc-editor.org/info/rfc6234>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <https://www.rfc-editor.org/info/rfc8200>.
[RFC8762]
Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, , <https://www.rfc-editor.org/info/rfc8762>.
[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, , <https://www.rfc-editor.org/info/rfc8972>.
[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, , <https://www.rfc-editor.org/info/rfc8986>.
[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, , <https://www.rfc-editor.org/info/rfc9503>.
[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, , <https://www.rfc-editor.org/info/rfc9534>.
[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, , <https://www.rfc-editor.org/info/rfc9800>.

17.2. Informative References

[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, , <https://www.rfc-editor.org/info/rfc826>.
[RFC2113]
Katz, D., "IP Router Alert Option", RFC 2113, DOI 10.17487/RFC2113, , <https://www.rfc-editor.org/info/rfc2113>.
[RFC4861]
Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, , <https://www.rfc-editor.org/info/rfc4861>.
[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, , <https://www.rfc-editor.org/info/rfc5905>.
[RFC6437]
Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, , <https://www.rfc-editor.org/info/rfc6437>.
[RFC6936]
Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, , <https://www.rfc-editor.org/info/rfc6936>.
[RFC7404]
Behringer, M. and E. Vyncke, "Using Only Link-Local Addressing inside an IPv6 Network", RFC 7404, DOI 10.17487/RFC7404, , <https://www.rfc-editor.org/info/rfc7404>.
[RFC7820]
Mizrahi, T., "UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)", RFC 7820, DOI 10.17487/RFC7820, , <https://www.rfc-editor.org/info/rfc7820>.
[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, , <https://www.rfc-editor.org/info/rfc8402>.
[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, , <https://www.rfc-editor.org/info/rfc8754>.
[RFC9256]
Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, , <https://www.rfc-editor.org/info/rfc9256>.
[RFC9350]
Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, , <https://www.rfc-editor.org/info/rfc9350>.
[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, , <https://www.rfc-editor.org/info/rfc9780>.
[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, , <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-yang-12>.
[I-D.ietf-spring-srv6-path-segment]
Li, C., Cheng, W., Zeng, G., Dhody, D., and Y. Zhu, "Path Segment Identifier (PSID) in SRv6 (Segment Routing in IPv6)", Work in Progress, Internet-Draft, draft-ietf-spring-srv6-path-segment-15, , <https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-path-segment-15>.
[IEEE.1588]
IEEE, "1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", .
[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, , <https://csrc.nist.gov/pubs/sp/800/90/a/r1/final>.
[IEEE802.1AX]
IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation", IEEE Std 802.1AX-2020, DOI 10.1109/IEEESTD.2020.9105034, , <https://doi.org/10.1109/IEEESTD.2020.9105034>.
[IANA-IPv6-REG]
IANA, "IANA IPv6 Special-Purpose Address Registry", <https://www.iana.org/assignments/iana-ipv6-special-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 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
Clarence Filsfils
Cisco Systems, Inc.
Bart Janssens
Colt
Mach(Guoyi) Chen
Individual
Richard Foote
Nokia