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

Copyright Notice

Copyright (c) 2025 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), as specified in [RFC8402], leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. SR takes advantage of Equal-Cost Multipaths (ECMPs) 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 TLVs 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 procedure is used for SR-MPLS paths [RFC8402] (including 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 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 for the number of STAMP sessions and the interval for measurement of SR-MPLS paths by defining new measurement modes: one-way, loopback, and loopback with "timestamp and forward."¶

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 SR-MPLS header.¶

STAMP test packets are transmitted in performance measurement modes, including two-way, one-way, loopback, and loopback with "timestamp and forward" in SR-MPLS networks. 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, which are new and specifically described for SR-MPLS networks in this document, are not defined by the STAMP process 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 carry the same SR-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 reply 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, 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 reply 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
  Metric Type              /              \
  SSID                    /                \
                         v                  v
                     +-------+          +-------+
                     |       |  STAMP   |       |
                     |   S1  |==========|   R1  |
                     |       |  Session |       |
                     +-------+          +-------+

               STAMP Session-Sender  STAMP Session-Reflector

4. Two-Way Measurement Mode

As shown in Figure 2, the reference topology for two-way measurement mode, the STAMP Session-Sender S1 initiates a STAMP Session-Sender test packet, and the STAMP Session-Reflector R1 generates and transmits a reply test packet. The reply test packets are transmitted to the STAMP 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 one-way delay metric as (T2 - T1), also referred to as near-end (forward direction) delay metric. Note that the delay value (T4 - T3), measured by the Session-Sender, is referred to as 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 a destination to node R1 (referred to as the "endpoint"), an SR-MPLS IGP best path, or an SR-MPLS IGP Flex-Algo path [RFC9350]. Additionally, a Layer-3 (L3) or Layer-2 (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 | 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      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            PSID (optional)            | 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, 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 reply 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, 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 the timestamp T1 from the received Session-Sender test packet and collects the receive timestamp T4 locally. Both timestamps, T1 and T4, are used to measure the loopback delay metric as (T4 - T1). The loopback delay includes the STAMP test packet processing delay on the Session-Reflector component. The Session-Reflector processing delay component includes only the time required to loop the STAMP 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      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            Return Path PSID (optional)| 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      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            PSID (optional)            | 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 Timestamp and Forward

As shown in Figure 14, the reference topology for "loopback measurement mode with timestamp and forward", the STAMP Session-Sender S1 initiates a Session-Sender test packet in loopback measurement mode. The "timestamp and forward" is used to optimize the "operations 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,
                                            Timestamp and Forward)

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 "timestamp and forward", 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 using STAMP test packets and collect the Session-Sender transmit counters and Session-Reflector receive and transmit counters of the data packet flows for direct measurement.¶

The PSID carried in the data packets is used to measure received data packets (for the receive traffic counter) on the associated SR-MPLS path on the Session-Reflector.¶

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 "timestamp and forward", 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. The usage of a node SID [RFC8402] by the Segment List of an SR-MPLS path can result in ECMP paths. In addition, the usage of an Anycast SID [RFC8402] by the Segment List of an SR-MPLS path 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.¶

For SR-MPLS path delay measurement, 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 to influence the ECMP path taken by them.¶

In the IPv4 header of the Session-Sender and Session-Reflector test packets, different values of the Destination Address from the range 127/8 are used to traverse different IPv4 ECMP paths as described in Section 2.1 of [RFC8029]. In this case, the Session-Sender test packets carry "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 the delay and packet loss metrics is not generated if the delay and packet loss metrics do not change significantly. For unambiguous monitoring, the controller needs to distinguish whether the STAMP session is active but delay and packet loss metrics are not significantly crossing 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 STAMP session state is notified as idle when the Session-Sender is not transmitting test packets. The STAMP session state is initially notified as active when the Session-Sender is transmitting test packets and as soon as one or more reply test packets are received at the Session-Sender.¶

The STAMP session state is notified as failed when N consecutive reply test packets are not received at the Session-Sender after the STAMP session state is notified as active, where N (consecutive packet loss count) is a locally provisioned value. In this case, the failed state of the STAMP session on the Session-Sender also indicates the connectivity failure of the SR-MPLS path, or L3/L2 service over the SR-MPLS path, where the STAMP session was active.¶

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

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) can be computed using the performance measurement procedures described in this document. Operator alert is generated for the anomaly detection when delay or loss metric cross user-configured thresholds.¶

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

15. Security Considerations

The security considerations specified in [RFC8762], [RFC8972], and [RFC9503] also apply 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 defined in Section 4.4 of [RFC8762], can be used with the procedures described in this document.¶

STAMP uses a well-known UDP port number that could become a target of denial of service (DoS) attacks or could be used to aid in on-path attacks. Thus, the security considerations and measures to mitigate the risk of such attacks, as documented in Section 6 of [RFC8545], equally apply to 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 [I-D.ietf-mpls-mna-hdr] are also applicable to the procedures for the SR-MPLS data plane defined in this document.¶

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 improving the mechanisms described in this document.¶

Authors' Addresses