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

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 17 February 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

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 to provide 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. [RFC9503] further augments that framework to define STAMP extensions for SR networks.¶

This document describes the procedures for Performance Measurement in SR-MPLS 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 SR-MPLS paths [RFC8402] (including Segment Lists of SR-MPLS Policies [RFC9256], SR-MPLS IGP best paths, and Flexible Algorithm (Flex-Algo) paths [RFC9350]), as well as Layer-3 (L3) and Layer-2 (L2) services over the SR-MPLS 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 the return test packets need to be generated. This limits the frequency of STAMP test packets and the ability to provide faster measurement intervals. This document adds new mechanisms to enhance the procedures for Performance Measurement using STAMP to improve the scalability of the number of STAMP sessions and the measurement interval for SR-MPLS paths by defining new measurement modes: one-way, loopback, and loopback with Timestamp and Forward (TSF).¶

2. Conventions Used in This Document

3. Overview

For performance measurement in SR-MPLS 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 SR-MPLS networks, where the STAMP test packets are further encapsulated with an MPLS header.¶

STAMP test packets are transmitted in one of the following performance measurement modes in SR-MPLS 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 referenced in the STAMP process in [RFC8762] and is further described for SR-MPLS networks in this document. The other measurement modes are new, specific to SR-MPLS networks, and 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 SR-MPLS encapsulation as the data traffic flow. 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 transport data paths. The 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. Further, the STAMP test packets carry the same MPLS headers as the data packets transmitted on the SR-MPLS path and on the L3 and L2 services for the data traffic forwarded on those services.¶

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 the return path for STAMP test packets, even for directly connected nodes, is not guaranteed. In SR-MPLS networks, it may be desired that the same path (i.e., the same set of links and nodes) between the Session-Sender and Session-Reflector be used for the STAMP test packets in both directions, for example, in an ECMP environment.¶

In two-way measurement mode, this is achieved by using the optional STAMP extensions for SR-MPLS, as specified in [RFC9503]. 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 [RFC9503]. In loopback measurement mode, this is achieved by adding both the forward direction path and the return path in the SR-MPLS 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 SR-MPLS 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 SR-MPLS networks.¶

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

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

The nodes S1 and R1 may be connected via an SR-MPLS path [RFC8402]. The SR-MPLS path may be a Segment List (i.e., a stack of MPLS labels) of an SR-MPLS Policy [RFC9256] on node S1 (referred to as the "head-end") with node R1 as the destination (referred to as the "endpoint"), an SR-MPLS IGP best path, or an SR-MPLS IGP Flex-Algo path [RFC9350]. Additionally, a L3 or L2 VPN service may be carried over the SR-MPLS path between nodes S1 and R1.¶

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Label(1) (Top of Stack)    | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Label(n)                   | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Test Packet as shown in Figure 3                   |
 .                                                               .
 +---------------------------------------------------------------+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Label(1) (Top of Stack)    | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            L3VPN Label                | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Test Packet as shown in Figure 3                   |
 .            Destination IP Address in L3VPN table              .
 .            Source IP Address in L3VPN table-reverse direction .
 .                                                               .
 +---------------------------------------------------------------+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Label(1) (Top of Stack)    | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            L2VPN Label                | TC  |1|      TTL=1    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Test Packet as shown in Figure 3                   |
 .                                                               .
 +---------------------------------------------------------------+

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

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

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)

The Session-Sender retrieves timestamp T1 from the received Session-Sender test packet and collects 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.¶

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Label(1) (Top of Stack)    | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Label(n)                   | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Return Path Label(1)       | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Return Path Label(n)       | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Test Packet as shown in Figure 10 (Return Path)    |
 .                                                               .
 +---------------------------------------------------------------+

       Example 1: Encapsulation Using SR-MPLS Return Path

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Label(1) (Top of Stack)    | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Label(n)                   | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Test Packet as shown in Figure 10 (Return Path)    |
 .                                                               .
 +---------------------------------------------------------------+

       Example 2: Encapsulation Using IP Return Path

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Label(1) (Top of Stack)    | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Label(n)                   | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Return Path Label(1)       | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            L3VPN Label (Return Path)  | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Test Packet as shown in Figure 10 (Return Path)    |
 .            Source and Destination IP Address in L3VPN table   .
 .                                                               .
 +---------------------------------------------------------------+

       Example 1: Encapsulation Using SR-MPLS Return Path


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Label(1) (Top of Stack)    | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            L3VPN Label (Forward Path) | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Test Packet as shown in Figure 10 (Return Path)    |
 .            Source and Destination IP Address in L3VPN table   .
 .                                                               .
 +---------------------------------------------------------------+

       Example 2: Encapsulation Using IP Return Path

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Label(1) (Top of Stack)    | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Label(n)                   | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Return Path Label(1)       | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            L2VPN Label (Return Path)  | TC  |1|      TTL=1    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Test Packet as shown in Figure 10 (Return Path)    |
 .                                                               .
 +---------------------------------------------------------------+

              Encapsulation Using SR-MPLS Return Path

7. Loopback Measurement Mode with TSF

As shown in Figure 14, 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)

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Label(1) (Top of Stack)    | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Label(n)                   | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            MNA Label                  | TC  |S|      TTL      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |7-bit MNA.TSF|  13-bit (value 0x0)     |R|IHS|S|  NASL |U| NAL |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Test Packet as shown in Figure 10 (Return Path)    |
 .                                                               .
 +---------------------------------------------------------------+

8. Packet Loss Measurement in SR-MPLS 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 SR-MPLS Networks

The STAMP "Direct Measurement" TLV (Type 5), defined in [RFC8972], is used in SR-MPLS networks for data packet loss measurement. The STAMP test packets with this TLV are transmitted using the procedure described for two-way measurement mode, while collecting the Session-Sender transmit counters and Session-Reflector receive and transmit counters of the data packet flows for direct measurement.¶

The Path Segment Identifier (PSID) [RFC9545] of an SR-MPLS Policy (for the Segment List or for the Candidate-Path) may be carried in the data packets to measure received data packets (for the receive traffic counter) on the associated SR-MPLS path when the egress node supports PSID processing.¶

In the case of L3 and L2 services in SR-MPLS networks, the associated SR-MPLS service labels are used to measure received data packets (for the receive traffic counters) on the Session-Reflector.¶

In loopback measurement mode and loopback measurement mode with TSF, defined in this document, direct measurement is not applicable.¶

10. ECMP Measurement in SR-MPLS Networks

The Segment List of an SR-MPLS 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 [RFC8402].¶
• The usage of an Anycast SID [RFC8402], 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 mechanisms.¶

• Different entropy label values [RFC6790] 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.¶
• Different Destination Address values from the IPv4 range 127/8 are used in the Session-Sender and Session-Reflector test packets to traverse different IPv4 ECMP paths, as described in Section 2.1 of [RFC8029]. In this case, the Session-Sender test packets may carry the "Destination Node IPv4 or IPv6 Address" STAMP TLV, as defined in [RFC9503], to identify the intended Session-Reflector IP address.¶

The considerations for loss measurement for different ECMP paths of an SR-MPLS 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 SR-MPLS path or of the L3/L2 service over the SR-MPLS 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 and loopback measurement modes, 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.¶

12. Additional STAMP Test Packet Processing Rules

13. Implementation Status

Editorial note: Please remove this section prior to publication.¶

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

The operational considerations specified in [RFC9994] and [I-D.ietf-mpls-stamp-pw] are also applicable to the procedures described in this document.¶

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 the 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 SR-MPLS Policies, the scalability regarding the number of STAMP sessions needs to be carefully considered.¶

The operational considerations described in [I-D.ietf-mpls-stamp-pw] apply when selecting a routable or non-routable IP address as a destination address.¶

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 security considerations specified in [RFC9994] and [I-D.ietf-mpls-stamp-pw] are also applicable to the procedures described 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.¶

16. IANA Considerations

This document does not require any IANA action.¶

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. The authors would also like to thank Haoyu Song for the Shepherd's review and Alvaro Retana for the WG chair's review, which helped improve this document.¶

Contributors

The following people have substantially contributed to this document:¶

Daniel Voyer
Cisco Systems, Inc.
Email: davoyer@cisco.com

Navin Vaghamshi
Reliance
Email: Navin.Vaghamshi@ril.com

Moses Nagarajah
Individual
Email: mosesnehru@gmail.com

Amit Dhamija
Arrcus
India
Email: amitd@arrcus.com

Authors' Addresses