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 22 March 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 can take advantage of Equal-Cost Multipath (ECMP) between source and transit nodes, between transit nodes, and between transit and destination nodes. SR Policies, as 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 the capability to measure various performance metrics in IP networks without the use of a control channel to pre-signal session parameters. [RFC8972] specifies optional extensions in the form of Type-Length-Value (TLV) objects for STAMP, and [RFC9503] further augments that framework to define STAMP extensions for SR networks.¶

This document describes the procedures for performance measurement in SR-MPLS networks, using STAMP as specified in [RFC8762], along with its optional extensions specified in [RFC8972] and augmented in [RFC9503]. The procedures described in this document are used for SR-MPLS paths [RFC8402] (including Segment Lists of SR-MPLS Policies [RFC9256], SR-MPLS IGP best paths, and SR-MPLS IGP Flexible Algorithm (Flex-Algo) paths [RFC9350]), as well as Layer-3 (L3) and Layer-2 (L2) services carried 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 for control-plane processing, 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 defines new mechanisms to enhance the procedures for performance measurement using STAMP, improve scalability by supporting a larger number of STAMP sessions, and shorten the measurement interval for SR-MPLS paths by defining three new measurement modes: one-way, loopback, and loopback with Timestamp and Forward (TSF). The new measurement modes, loopback and loopback with TSF, take advantage of source routing.¶

The procedure for performance measurement of MPLS LSPs using the measurement modes defined in this document is outside the scope of this document.¶

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 specified in [RFC8762], along with optional extensions specified in [RFC8972]. The STAMP test packets are encapsulated using an IP/UDP header, as specified in [RFC8762]. In this document, 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 where processing on Session-Reflector varies:¶

1. Two-Way measurement:¶

   Session-Reflector generates and transmits Session-Reflector test packets (see Section 4.1).¶

2. One-Way measurement:¶

   Session-Reflector does not generate and transmit Session-Reflector test packets (see Section 4.2).¶

3. Loopback measurement:¶

   Session-Reflector does not perform STAMP processing (see Section 4.3).¶

4. Loopback measurement with TSF:¶

   Session-Reflector writes the receive timestamp in fast path but does not perform STAMP processing (see Section 4.4).¶

Note that the two-way measurement mode is described as part of the STAMP process in [RFC8762] and is further described for SR-MPLS networks in this document. The other measurement modes are new, specific to SR-MPLS 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 MPLS encapsulation.¶

• STAMP test packets are transmitted on various transport data paths in the network to measure the delay and packet loss experienced by the traffic forwarded on those paths.¶

• STAMP test packets are transmitted over L3 and L2 services in the network to measure the delay and packet loss experienced by the traffic carried by those services.¶

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 SR-MPLS networks, the same path (i.e., the same set of links and nodes) between the Session-Sender and Session-Reflector may be desired for the STAMP test packets in both directions, for example, in an ECMP environment. This is achieved as follows:¶

• In two-way measurement mode:¶

  The optional STAMP extensions for SR-MPL networks, as specified in [RFC9503], are used. The STAMP Session-Reflector uses the return path parameters for the Session-Reflector test packet from the STAMP extensions in the received Session-Sender test packet, as specified in [RFC9503].¶

• In loopback and loopback with TSF measurement modes:¶

  Both the forward direction path and the return path are added in the MPLS encapsulation of the Session-Sender test packets using source routing.¶

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

4. Measurement Modes

In Figure 1 to Figure 4, the nodes S1 and R1 may be connected via an SR-MPLS path [RFC8402].¶

The SR-MPLS path may be a Segment List 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, an L3 or L2 VPN service may be carried over the SR-MPLS path between nodes S1 and R1.¶

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

       STAMP Session-Sender          STAMP Session-Reflector

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

       STAMP Session-Sender          STAMP Session-Reflector

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

       STAMP Session-Sender          STAMP Session-Reflector
                                           (Loopback, Forward)

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

       STAMP Session-Sender          STAMP Session-Reflector
                                           (Loopback, TSF)

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

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

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

The base STAMP test packet payloads specified in [RFC8972] are transported using an IP/UDP header and a destination UDP port [RFC6335], selected as specified in Section 4.1 of [RFC8762]. The same destination port can be used for STAMP sessions for links, SR-MPLS paths, and L3 and L2 services carried over the SR-MPLS 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.¶

The Session-Sender and Session-Reflector IP addresses for a STAMP session are provisioned on both endpoints of the session.¶

Session-Reflector mode can be either Stateful or Stateless, as specified in Section 4 of [RFC8762]. Stateless Session-Reflector mode is applicable only in two-way measurement mode.¶

The SSID in the STAMP test packets [RFC8972] must be set to a non-zero value in both directions. The SSID in a STAMP test packet, along with the local configuration for the performance measurement mode, is used to identify STAMP sessions.¶

When authentication mode is enabled for STAMP sessions, the matching Authentication Type (e.g., HMAC-SHA-256) and Keychain must be configured on both the Session-Sender and Session-Reflector [RFC8762].¶

Examples of timestamp formats include 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 specified in [RFC8762]. This behavior depends on the Session-Reflector's capability.¶

Examples of delay metrics are one-way delay, two-way delay, near-end delay (forward direction), and far-end delay (backward direction), as specified in [RFC8762].¶

Examples of packet loss metric types are round-trip packet loss, near-end packet loss (forward direction), and far-end packet loss (backward direction), as specified in [RFC8762].¶

The IPv4 TTL, MPLS TTL, and IPv6 Hop Limit fields follow the specification in [I-D.ietf-mpls-stamp-pw].¶

The Flow Label field in the IPv6 header of the Session-Sender test packets is set to the value used by the data packets for the IPv6 traffic flow being measured by the Session-Sender. The Session-Reflector sets the Flow Label in its test packet to the value received in the Session-Sender test packet, subject to local policy.¶

A Software-Defined Networking (SDN) controller can be used for the configuration and management of STAMP sessions, as specified in [RFC8762]. The controller can also receive streaming telemetry of operational data. The YANG data model for STAMP, defined in [I-D.ietf-ippm-stamp-yang], can be used to configure Session-Senders and Session-Reflectors and to stream telemetry of operational data.¶

6. Encapsulations for Two-Way Measurement Mode

 +---------------------------------------------------------------+
 | IP Header                                                     |
 .  Source IP Address = Session-Sender IP Address                .
 .  Destination IP Address = Session-Reflector IP Address        .
 .  IPv4 Protocol or IPv6 Next-header = 17 (UDP)                 .
 .                                                               .
 +---------------------------------------------------------------+
 | UDP Header                                                    |
 .  Source Port = Selected by Session-Sender                     .
 .  Destination Port = User-configured Destination Port Or 862   .
 .                                                               .
 +---------------------------------------------------------------+
 | Payload = Test Packet as specified in Figure 1 and Figure 3   |
 .           in Section 3 of RFC 8972                            .
 .                                                               .
 +---------------------------------------------------------------+

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

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

 +---------------------------------------------------------------+
 | IP Header                                                     |
 .  Source IP Address                                            .
 .     = Session-Reflector IP Address                            .
 .  Destination IP Address                                       .
 .     = Source IP Address from Session-Sender Test Packet       .
 .  IPv4 Protocol or IPv6 Next-header = 17 (UDP)                 .
 .                                                               .
 +---------------------------------------------------------------+
 | UDP Header                                                    |
 .  Source Port = Selected by Session-Reflector                  .
 .  Destination Port                                             .
 .     = Source Port from Session-Sender Test Packet             .
 .                                                               .
 +---------------------------------------------------------------+
 | Payload = Test Packet as specified in Figure 2 and Figure 4   |
 .           in Section 3 of RFC 8972                            .
 .                                                               .
 +---------------------------------------------------------------+

7. Encapsulations for One-Way Measurement Mode

In one-way measurement mode, for links, SR-MPLS paths, and L3 and L2 services carried over the SR-MPLS paths, the Session-Sender test packets with encapsulations as defined in Section 6 for STAMP sessions, are transmitted. As no Session-Reflector test packets are transmitted, the encapsulation for them defined in Section 6 does not apply.¶

8. Encapsulations for Loopback Measurement Mode

In loopback measuement mode for SR-MPLS paths, and L3 and L2 services carried over the SR-MPLS paths, the Session-Sender test packets with encapsulations as defined Section 6 for STAMP sessions, are transmitted. An IP header is added for the return path in the Session-Sender test packets, setting the Destination Address equal to the Session-Sender address, as shown in Figure 11, to return the test packets to the Session-Sender.¶

 +---------------------------------------------------------------+
 | IP Header (Return Path)                                       |
 .  Source IP Address = Session-Sender IP Address                .
 .  Destination IP Address = Session-Sender IP Address           .
 .  IPv4 Protocol or IPv6 Next-header = 17 (UDP)                 .
 .                                                               .
 +---------------------------------------------------------------+
 | UDP Header                                                    |
 .  Source Port = Selected by Session-Sender                     .
 .  Destination Port = Source Port                               .
 .                                                               .
 +---------------------------------------------------------------+
 | Payload = Test Packet as specified in Figure 1 and Figure 3   |
 .           in Section 3 of RFC 8972                            .
 .                                                               .
 +---------------------------------------------------------------+

 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 11 (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 11 (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 11 (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 11 (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 11 (Return Path)    |
 .                                                               .
 +---------------------------------------------------------------+

              Encapsulation Using SR-MPLS Return Path

9. Encapsulations for Loopback Measurement Mode with TSF

The encapsulations for loopback measurement mode with TSF is defined for SR-MPLS paths and does not support L3 and L2 services carried over the SR-MPLS paths.¶

 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 TBA1 |  13-bit (value 0x0)     |R|IHS|S|  NASL |U| NAL |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Test Packet as shown in Figure 11 (Return Path)    |
 .                                                               .
 +---------------------------------------------------------------+

10. Packet Loss Measurement in SR-MPLS Networks

The procedure described for two-way measurement mode supports inferred measurements of round-trip, near-end (forward direction), and far-end (backward direction) packet loss. However, this provides only an approximate view of 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.¶

11. Direct Measurement in SR-MPLS Networks

The STAMP "Direct Measurement" TLV (Type 5), defined in [RFC8972], is used for data packet loss measurement. To collect direct-measurement counters for data packet flows, STAMP test packets containing this TLV are transmitted using the two-way measurement-mode procedure. The procedure collects Session-Sender transmit counters and Session-Reflector receive and transmit counters.¶

The receive data traffic can be measured as follows:¶

• 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 traffic (for the receive packet 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 traffic (for the receive packet counters) on the Session-Reflector.¶

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

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

• Use of a node SID [RFC8402].¶
• Use 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.¶

13. Implementation Status

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

14. Operational and Manageability Considerations

The operational considerations specified in Section 5 of [RFC8762] also apply to the procedures specified in this document. Further, the operation and management considerations for performance measurement based on STAMP specified in Section 3 of [RFC8762] also apply to the procedures specified in this document. The manageability considerations described in Section 9 of [RFC8402] apply to this specification.¶

When a destination UDP port number other than the default port 862 is used, the same network-impact study and agreement requirements specified in Section 4.1 of [RFC8762] apply.¶

The operational considerations specified in [RFC9994] are also applicable to the procedures described in this document.¶

Various statistics for one-way (near-end, far-end), two-way, 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 specified 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 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.¶

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 specified in Section 4.4 of [RFC8762], can be used with the procedures described in this document.¶

The source UDP port number should be selected using a randomized allocation method as specified in [RFC6056] to provide protection against off-path attacks, as recommended in [RFC8085].¶

Furthermore, SSIDs [RFC8972] should not be assigned predictably. To avoid predictability, implementations can use a cryptographically secure pseudorandom number generator [NIST-CSPRNG].¶

The procedures defined in this document are intended for deployment in a single network administrative domain. As such, the Session-Sender 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.¶

Implementations can mitigate attacks by performing basic validation checks on Session-Reflector test packets received at the Session-Sender, such as verifying that timestamp T2 is later than timestamp T1 (when the Session-Sender and Session-Reflector clocks are synchronized) in the STAMP Reference Topology shown in Figure 1. The minimal state associated with this protocol also limits the extent of measurement disruption that can be caused by a corrupt or invalid test packet to a single test cycle.¶

STAMP test packets received through a transport path or a service context must be processed only in that context. This document does not provide a mechanism for cross-service OAM interactions.¶

16. IANA Considerations

IANA is requested to assign code points from the Network Action Opcodes registry created in [RFC9994] as specified in Table 3.¶

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, Mike Koldychev, and Bruno Decraene 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