Internet-Draft STAMP for Segment Routing over MPLS October 2026
Gandhi, et al. Expires 11 April 2027 [Page]
Workgroup:
SPRING Working Group
Internet-Draft:
draft-ietf-spring-stamp-srpm-mpls-11
Published:
Intended Status:
Informational
Expires:
Authors:
R. Gandhi, Ed.
Cisco Systems, Inc.
C. Filsfils
Cisco Systems, Inc.
B. Janssens
Colt
M. Chen
Huawei
R. Foote
Nokia

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

Abstract

Segment Routing (SR) can be used to steer packets through a network employing source routing. SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for performance measurement in SR-MPLS networks using the Simple Two-Way Active Measurement Protocol (STAMP), as specified in RFC 8762, along with its optional extensions specified in RFC 8972 and the SR-specific extensions specified in RFC 9503. These procedures measure SR-MPLS paths (including Segment Lists of SR-MPLS Policies, SR-MPLS IGP best paths, and SR-MPLS IGP Flexible Algorithm (Flex-Algo) paths), as well as Layer-3 and Layer-2 services carried over those paths.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 11 April 2027.

▲

Table of Contents

1. Introduction

Segment Routing (SR) [RFC8402] can be used to steer packets through a network employing source routing. SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. SR 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 specified in [RFC9256], are used to steer traffic through specific user-defined paths using a list of segments.

A comprehensive SR performance measurement toolset is essential for measuring network performance and meeting 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 procedures for measuring performance in SR-MPLS networks using STAMP as specified in [RFC8762], along with the optional extensions specified in [RFC8972] and the SR-specific extensions specified in [RFC9503]. The procedures in this document measure 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 those paths.

STAMP requires protocol support as specified in [RFC8762] on the Session-Reflector to process the received STAMP-Test packets, including optional TLVs specified in [RFC8972], and to generate Session-Reflector test packets as well as reflect received TLVs. In addition, use of the UDP port in STAMP-Test packets exposes the Session-Reflector to security threats and requires rate limiting and operational considerations. These requirements necessitate that STAMP-Test packets follow an exception path (e.g., be punted from the IP- or MPLS-forwarding fast path). This results in limiting 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 and pseudowires using the measurement modes defined in this document is outside the scope of this document.

2. Conventions Used in This Document

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2.2. Terminology

This document uses terms defined in [RFC8762], specifically Session-Sender, Session-Reflector, and Session-Test packet.

This document uses terms defined in [RFC6374], specifically timestamps (T1, T2, T3 and T4), the one-way delay metric, defined as (T2 - T1); the two-way delay metric, defined as ((T4 - T1) - (T3 - T2)); and the round-trip delay metric, defined as (T4 - T1).

2.3. Abbreviations

Table 1: Abbreviations
Abbreviation Expansion Reference
BoS Bottom of Stack [RFC9994]
ECMP Equal-Cost Multipath [RFC6790]
HMAC Hashed Message Authentication Code [RFC6234]
L2VPN Layer-2 Virtual Private Network [RFC4026]
L3VPN Layer-3 Virtual Private Network [RFC4026]
LSE Label Stack Entry [RFC9994]
MBZ Must Be Zero [RFC8762]
MNA MPLS Network Action [RFC9994]
MPLS Multiprotocol Label Switching [RFC3032]
NTP Network Time Protocol [RFC5905]
PHP Penultimate Hop Popping [RFC3031]
PTP Precision Time Protocol [IEEE.1588]
S bit Bottom of Stack bit [RFC3032]
SHA Secure Hash Algorithms [RFC6234]
SID Segment Identifier [RFC8402]
SR Segment Routing [RFC8402]
SR-MPLS Segment Routing over the MPLS data plane [RFC8402]
SSID STAMP Session Identifier [RFC8972]
STAMP Simple Two-Way Active Measurement Protocol [RFC8762]
TC Traffic Class [RFC5462]
TLV Type-Length-Value [RFC8972]
TSF Timestamp and Forward This document
TTL Time to Live [RFC3032]
VPN Virtual Private Network [RFC4026]

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, STAMP-Test packets use an IP/UDP header and are further encapsulated with an MPLS header for use in SR-MPLS networks.

In SR-MPLS networks, STAMP-Test packets can use one of the following measurement modes, which differ in how the Session-Reflector processes the packets:

  1. Two-Way measurement mode:

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

  2. One-Way measurement mode:

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

  3. Loopback measurement mode:

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

  4. Loopback with TSF measurement mode:

    The Session-Reflector writes the receive timestamp in the 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 specified in [RFC8762].

STAMP-Test packets are transmitted on the same path as the data traffic flow being measured to measure the delay and packet loss experienced by the data traffic flow, using the same MPLS encapsulation.

Typically, STAMP Session-Reflector test packets are transmitted along an IP path between the Session-Reflector and Session-Sender. The forward-direction path and the return path of STAMP-Test packets are not guaranteed to match, even for directly connected nodes. 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:

The procedures in this document measure delay and packet loss in SR-MPLS networks by transmitting and receiving STAMP-Test packets. The optional STAMP extensions specified 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.

4.1. Two-Way Measurement Mode

As shown in Figure 1, in the reference topology for two-way measurement mode, the STAMP Session-Sender S1 initiates a Session-Sender test packet, and the STAMP Session-Reflector R1 generates and transmits a Session-Reflector test packet. The Session-Reflector test packets are transmitted to the Session-Sender S1 on the same path (i.e., the same set of links and nodes) or on a different path in the reverse direction from the path taken toward the Session-Reflector R1.

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

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

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 two-way delay metric, defined as ((T4 - T1) - (T3 - T2)) in Section 2.4 of [RFC6374]. Timestamps T1 and T2 are used by the Session-Sender to measure the one-way delay metric, defined as (T2 - T1) in Section 2.4 of [RFC6374], 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 "two-way delay" is the sum of the one-way delays in each direction and reflects the delay of the bidirectional path, irrespective of processing delays within the Session-Reflector.

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.

4.2. One-Way Measurement Mode

As shown in Figure 2, 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                T2
                      /                   \
             +-------+     Test Packet     +-------+
             |       | - - - - - - - - - ->|       |
             |   S1  |=====================|   R1  |
             |       |                     |       |
             +-------+                     +-------+

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

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, defined as (T2 - T1) in Section 2.4 of [RFC6374].

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.

4.3. Loopback Measurement Mode

As shown in Figure 3, in the reference topology for loopback measurement mode, the STAMP Session-Sender S1 initiates a Session-Sender test packet to measure the round-trip delay using source routing. At the STAMP Session-Reflector, the received STAMP-Test packets remain in the fast path in the data plane and are forwarded. In other words, the Session-Reflector does not perform STAMP processing or generate Session-Reflector test packets.

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

       STAMP Session-Sender          STAMP Session-Reflector
                                           (Loopback, Forward)
Figure 3: Reference Topology for Loopback Measurement Mode

The Session-Sender retrieves timestamp T1 from the received Session-Sender test packet and collects the receive timestamp T4 locally to measure the round-trip delay metric, defined as (T4 - T1) in Section 2.4 of [RFC6374]. This delay includes STAMP-Test packet processing on the Session-Reflector in the data plane. 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 a timestamping capability. The round-trip delay is defined in [RFC2681].

4.4. Loopback with TSF Measurement Mode

As shown in Figure 4, in the reference topology for "loopback with TSF measurement mode", the STAMP Session-Sender S1 initiates a Session-Sender test packet in loopback measurement mode using source routing. The TSF mechanism is used to optimize the operation of punting the test packet from the fast path in the data plane for control-plane processing and generating the return test packet on the STAMP Session-Reflector, because timestamp writing is implemented in the fast path in the data plane. This helps achieve a higher number of STAMP sessions and faster measurement intervals.

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

       STAMP Session-Sender          STAMP Session-Reflector
                                           (Loopback, TSF)
Figure 4: Reference Topology for Loopback with TSF Measurement Mode

The Session-Sender adds the transmit timestamp (T1) to the payload of the Session-Sender test packet. The Session-Reflector writes the receive timestamp (T2) in the received STAMP-Test packet in the fast path in the data plane, without punting the test packet from the fast path in the data plane for control-plane STAMP processing.

The Session-Sender retrieves 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, defined as (T2 - T1) in Section 2.4 of [RFC6374]. Timestamps T1 and T4 are used by the Session-Sender to measure the round-trip delay metric, defined as (T4 - T1) in Section 2.4 of [RFC6374].

5. STAMP Reference Model

The STAMP Reference Model and typical measurement parameters for a STAMP session, as specified in [RFC8972], are 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
Figure 5: STAMP Reference Model

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

The STAMP-Test packet payloads specified in [RFC8972] are transported using an IP/UDP header and a destination UDP port number [RFC6335], selected as specified in Section 4.1 of [RFC8762]. The same destination UDP port number can be used for STAMP sessions for SR-MPLS paths and for L3 and L2 services carried over those paths.

The source UDP port number is selected by the Session-Sender. The same or different source UDP port numbers 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.

The 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 each STAMP-Test packet [RFC8972] must be set to a nonzero 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 a 64-bit truncated Precision Time Protocol (PTPv2) timestamp [IEEE.1588] and a 64-bit Network Time Protocol (NTPv4) timestamp [RFC5905]. By default, the Session-Reflector replies using the same timestamp format as the one 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.

STAMP can be used in two-way mode to collect timestamps T1, T2, T3 and T4 to compute one-way delay metric, defined as (T2 - T1) in Section 2.4 of [RFC6374], and two-way delay metric, defined as ((T4 - T1) - (T3 - T2)) in Section 2.4 of [RFC6374].

As defined in [RFC2681], round-trip delay measurement requires the destination to immediately send the packet back to the source. STAMP does not provide an accurate measurement of the round-trip delay, defined as (T4 - T1) in Section 2.4 of [RFC6374], because of the STAMP-Test packet processing time at the Session-Reflector. This processing includes handling the UDP header in the exception path, generating STAMP-Test packets, and reflecting optional TLVs.

5.1. STAMP for One-Way Measurement Mode

In one-way measurement mode, the Session-Reflector operates in Stateful mode.

The SSID field in the received Session-Sender test packets [RFC8972] at the Session-Reflector, along with the local configuration, is used to identify the STAMP sessions that use one-way measurement mode on the Stateful Session-Reflector.

A different destination UDP port number can be selected for one-way measurement mode instead of the UDP port number used by the Session-Reflector for two-way measurement mode. The UDP port number must be chosen from the Dynamic Ports range (49152-65535) [RFC6335] to avoid conflicts with well-known and registered service ports.

When the same Session-Reflector UDP port number is selected for one-way measurement mode as the UDP port number used by the Session-Reflector for two-way measurement mode, the Session-Sender requests, in the test packets, that the Session-Reflector not transmit Session-Reflector test packets. To achieve this, it must use the "No Reply Requested" flag in the Control Code Sub-TLV within the Return Path TLV defined in [RFC9503].

STAMP can be used in one-way mode to collect timestamps T1 and T2 to compute the one-way delay metric but it cannot compute the two-way and round-trip delay metrics.

5.2. STAMP for Loopback and Loopback with TSF Measurement Modes

The Session-Reflector does not perform STAMP processing. Instead, in loopback mode, it processes the MPLS header, ignores the UDP header, and forwards the STAMP-Test packet to the Session-Sender without modifying it.

The Session-Sender must set the destination UDP port number to the UDP port number it uses to receive return Session-Reflector test packets, except for UDP port number 862, which is used by the Session-Reflector. The same UDP port number may be used as both the destination and source UDP port numbers in the Session-Sender test packets.

At the Session-Sender, the "Session-Sender Sequence Number", the "Session-Sender Timestamp", the "Session-Sender Error Estimate", and the "Session-Sender TTL" fields [RFC8762] must all be set to zero in the transmitted Session-Sender test packets and must be ignored in the received test packets.

STAMP can be used in the loopback measurement mode to collect timestamps T1 and T4 to compute the round-trip delay metric but it cannot compute the one-way and two-way delay metrics.

STAMP can be used in the loopback with TSF measurement mode to collect timestamps T1, T2 and T4 to compute the one-way and round-trip delay metrics but it cannot compute the two-way delay metric.

5.3. Measurement Mode Comparison for STAMP

Table 2: Measurement Mode Comparison for STAMP
Mode Reflector Timestamp Clock Sync Loss Metrics Applicable Direct Reference
Two-Way Stateful or Stateless T1/T2/T3/T4 OW, TW One-Way, Round-trip Yes [RFC8762]
One-Way Stateful T1/T2 OW One-Way Yes This document
Loopback N/A T1/T4 RT Round-trip No This document
Loopback with TSF N/A T1/T2/T4 OW, RT Round-trip No This document

OW: One-way delay metric (T2 - T1) computation requires clock synchronization.

TW: Two-way delay metric ((T4 - T1) - (T3 - T2)) computation does not require clock synchronization.

RT: Round-trip delay metric (T4 - T1) computation does not require clock synchronization.

5.3.1. STAMP TLV Applicability

The following STAMP TLVs specified for two-way measurement mode are applicable in one-way, loopback, and loopback with TSF measurement modes:

The following STAMP TLVs specified for two-way measurement mode are not applicable in one-way, loopback, and loopback with TSF measurement modes:

6. Encapsulations for Two-Way Measurement Mode

6.1. Session-Sender Test Packet

The content of a Session-Sender test packet is shown in Figure 6. The Session-Sender test packet payload, as specified in Section 3 of [RFC8972], is transmitted with an IP header and a UDP header [RFC768].

 +---------------------------------------------------------------+
 | 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                            .
 .                                                               .
 +---------------------------------------------------------------+
Figure 6: Content of Session-Sender Test Packet

6.2. Session-Sender Test Packet for SR-MPLS Data Plane

6.2.1. Session-Sender Test Packet for SR-MPLS Paths

A Candidate-Path of an SR-MPLS Policy contains one or more Segment Lists (i.e., a stack of MPLS labels) [RFC9256]. To measure delay for an SR-MPLS Policy, the Session-Sender must transmit test packets for each Segment List in the Candidate-Path, using a separate STAMP session for each list.

Each SR-MPLS Segment List contains a list of 32-bit Label Stack Entries (LSEs), where each LSE includes a 20-bit label value, an 8-bit Time to Live (TTL) field, a 3-bit Traffic Class (TC) field, and a 1-bit Bottom of Stack (BoS) field [RFC3032].

A Session-Sender test packet using the same SR-MPLS encapsulation as the data traffic on the path is shown in Figure 7.

 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                   |
 .                                                               .
 +---------------------------------------------------------------+
Figure 7: Content of Session-Sender Test Packet for SR-MPLS Path

The IP header's Source IP Address field must contain the IP address of the SR-MPLS Policy's head-end node. There are two cases for the SR-MPLS Policy endpoints, as described below.

  1. If the SR-MPLS Policy's endpoint is specified and is not the null endpoint, its IP address must be used as the Destination IP Address in the IP header.

    In the case of Penultimate Hop Popping (PHP), the MPLS header is removed by the penultimate node. In this case, the Session-Sender must ensure that the specified Destination IP Address in the IP header causes the test packets to reach the Session-Reflector at the SR-MPLS Policy endpoint.

  2. For an SR-MPLS Policy with Color-Only Destination Steering, where the endpoint is an unspecified IPv4 address (the null endpoint is 0.0.0.0, as specified in Section 8.8.1 of [RFC9256]), an IPv4 loopback address from the 127/8 range is used as the Destination IP Address in the IPv4 header.

    For IPv6 traffic, the Session-Sender's IPv6 address is used as the Source IP Address, and an IPv6 address from the Dummy IPv6 Prefix 100:0:0:1::/64 block [RFC9780] [IANA-IPv6-REG] is used as the Destination IP Address in the IPv6 header.

    In this case, the Session-Sender must ensure that the Session-Sender test packets using the Segment List reach the Session-Reflector at the SR-MPLS Policy endpoint (for example, by adding the Prefix SID label of the SR-MPLS Policy endpoint to the Segment List).

    In addition, 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.

Each IGP Flex-Algo path in SR-MPLS networks [RFC9350] has Prefix SID labels advertised by the nodes. For delay measurement of SR-MPLS IGP Flex-Algo paths, the Session-Sender test packets carry the Flex-Algo Prefix SID labels of the Session-Sender and Session-Reflector in the MPLS header for that IGP Flex-Algo path under measurement.

Similarly, each IGP best path in SR-MPLS networks [RFC9350] has Prefix SID labels advertised by the nodes. For delay measurement of SR-MPLS IGP best paths, the Session-Sender test packets carry the IGP Prefix SID labels of the Session-Sender and Session-Reflector in the MPLS header for that IGP best path under measurement.

6.2.2. Session-Sender Test Packet for Layer-3 Services over SR-MPLS Path

To measure delay for an L3 service carried over an SR-MPLS path, the SR-MPLS label stack of the data packets transmitted over the L3 service, including the L3 Virtual Private Network (L3VPN) label (advertised by the Session-Reflector), is used to encapsulate the Session-Sender test packets, as shown in Figure 8.

 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 .
 .                                                               .
 +---------------------------------------------------------------+
Figure 8: Content of Session-Sender Test Packet for L3 Service over SR-MPLS Path

An IP header, as shown in Figure 6, is added to the Session-Sender test packets after the MPLS header. The Destination IP Address in the IP header must be reachable via the IP table lookup associated with the L3VPN label added for the L3 service on the Session-Reflector. The Source IP Address in the IP header of the Session-Sender test packets must be reachable via the IP table lookup associated with the L3 service in the reverse direction.

6.2.3. Session-Sender Test Packet for Layer-2 Services over SR-MPLS Path

To measure delay for an L2 service carried over an SR-MPLS path, the SR-MPLS label stack of the data packets transmitted over the L2 service, including the L2 Virtual Private Network (L2VPN) label (advertised by the Session-Reflector), is used to encapsulate the Session-Sender test packets, as shown in Figure 9.

 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                   |
 .                                                               .
 +---------------------------------------------------------------+
Figure 9: Content of Session-Sender Test Packet for L2 Service over SR-MPLS Path

The L2VPN label is added with a TTL value of 1 to terminate the Session-Sender test packet for control-plane processing on the Session-Reflector when using the Type 3 exception specified in [I-D.ietf-mpls-stamp-pw].

An IP header, as shown in Figure 6, is added to the Session-Sender test packets after the MPLS header. This header contains the Session-Sender IP address as the Source IP Address and the Session-Reflector IP address as the Destination IP Address.

6.3. Session-Reflector Test Packet

In two-way measurement mode, the Session-Reflector transmits the Session-Reflector test packets over SR-MPLS paths, L3 services, or L2 services carried over SR-MPLS paths in the reverse direction toward the Session-Sender.

The Session-Reflector decapsulates the MPLS header, if present, from the received Session-Sender test packet.

The Session-Reflector generates the Session-Reflector test packet using the source and destination IP addresses and UDP port numbers extracted from the received Session-Sender test packet, as shown in Figure 10.

 +---------------------------------------------------------------+
 | 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                            .
 .                                                               .
 +---------------------------------------------------------------+
Figure 10: Content of Session-Reflector Test Packet

The payload contains the Session-Reflector test packet specified in Section 3 of [RFC8972]. The source UDP port number in the received UDP header is used as the destination UDP port number, and the destination UDP port number in the received UDP header is used as the source UDP port number. The source IP address in the received IP header must be used as the destination IP address, and the Session-Reflector IP address must be used as the source IP address.

The Session-Reflector encapsulates the Session-Reflector test packets for transmission over SR-MPLS paths, L3 services, or L2 services carried over SR-MPLS paths in the reverse direction.

6.3.1. Session-Reflector Test Packet for SR-MPLS Path

When the Session-Reflector receives a Segment List sub-TLV in the Return Path TLV defined in [RFC9503], it uses that Segment List as the reverse-direction SR-MPLS path and encapsulates the Session-Reflector test packet with the corresponding MPLS label stack.

Examples of specific SR-MPLS return paths include:

  • The SR-MPLS label stack of the associated reverse Candidate-Path.
  • The Binding SID label of the reverse SR-MPLS Policy.
  • The SR-MPLS Prefix SID label of the Session-Sender.

For an SR-MPLS IGP Flex-Algo path, the Segment List sub-TLV in the Return Path TLV carries the SR-MPLS Prefix SID label of the Session-Sender for the same SR-MPLS IGP Flex-Algo path and requests that the Session-Reflector transmit the Session-Reflector test packet over that path in the reverse direction.

If a Return Path TLV containing a Segment List sub-TLV is not received, the Session-Reflector transmits the Session-Reflector test packet over the locally selected reverse SR-MPLS path.

If no reverse SR-MPLS path can be selected, the Session-Reflector transmits the test packet shown in Figure 10 using IP forwarding.

6.3.2. Session-Reflector Test Packet for an L3 Service Over SR-MPLS Path

The Session-Reflector transmits the Session-Reflector test packet using the reverse-direction L3 service label stack associated with the L3VPN label received for the forward-direction L3 service.

The Session-Reflector adds the MPLS header using reachability information for the Source IP Address in the IP header of the received test packet. This address must be reachable through the IPv4 or IPv6 table lookup associated with the L3VPN label for the forward-direction L3 service instantiated on the Session-Reflector.

The IP header shown in Figure 10 uses the source and destination IP addresses from the received IP header as its destination and source addresses, respectively.

If the Session-Reflector cannot find the corresponding reverse-direction L3 service, it must drop the test packet and must not transmit a reply test packet.

6.3.3. Session-Reflector Test Packet for an L2 Service Over SR-MPLS Return Path

The Session-Reflector transmits the Session-Reflector test packet using the reverse-direction L2 service label stack associated with the L2VPN label received for the forward-direction L2 service.

The L2VPN label is added with a TTL value of 1 when the Type 3 exception specified in [I-D.ietf-mpls-stamp-pw] is used to terminate STAMP-Test packets for control-plane processing.

If the Session-Reflector cannot find the corresponding reverse-direction L2 service, it must drop the test packet and must not transmit a reply test packet.

7. Encapsulations for One-Way Measurement Mode

In one-way measurement mode for SR-MPLS paths and for L3 and L2 services carried over those paths, the Session-Sender transmits STAMP-Test packets using the encapsulations defined in Section 6.2. Because no Session-Reflector test packets are transmitted, the encapsulation defined in Section 6.3 does not apply.

8. Encapsulations for Loopback Measurement Mode

In loopback measurement mode for SR-MPLS paths and L3 and L2 services carried over SR-MPLS paths, the Session-Sender transmits the STAMP-Test packets defined in Section 6.1. An IP header is added for the return path in the Session-Sender test packets, and its Destination IP Address must be set to the Session-Sender IP 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                            .
 .                                                               .
 +---------------------------------------------------------------+
Figure 11: Content of Session-Sender Return Test Packet in Loopback Measurement Mode

8.1. Loopback Measurement Mode for SR-MPLS Paths

In loopback measurement mode for SR-MPLS paths, the Session-Sender test packet carries either only the Segment List for the forward path or Segment Lists for both the forward and return paths in the MPLS header, as specified in [RFC8403] and shown in Figure 12.

 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
Figure 12: Content of Session-Sender Test Packet in Loopback Measurement Mode for SR-MPLS Path

In the case of an SR-MPLS Policy using PHP, the Session-Sender must ensure that the STAMP-Test packets reach the SR-MPLS Policy endpoint, for example, by adding the Prefix SID label of the SR-MPLS Policy endpoint to the Segment List of the forward direction path.

The IP header for the return path is added to the Session-Sender test packets, and the Destination IP Address must be set to the Session-Sender IP address in the IP header.

8.1.1. SR-MPLS Return Path

The Session-Sender test packets, in the SR-MPLS label stack, carry the return path in addition to the forward direction path, as shown in Example 1 of Figure 12. Examples of specific SR-MPLS return paths include:

  • The SR-MPLS label stack of the Segment List of the associated reverse Candidate-Path.
  • The Binding SID label of the reverse SR-MPLS Policy.
  • The SR-MPLS Prefix SID label of the Session-Sender.

For SR-MPLS IGP Flex-Algo paths, the Session-Sender test packets carry the SR-MPLS Prefix SID label of the Session-Sender on the same SR-MPLS IGP Flex-Algo path in the reverse direction.

The Binding SID label of the reverse SR-MPLS Policy can be configured on the Session-Sender using, for example, an SDN controller.

8.1.2. IP Return Path

The Session-Sender test packets, in the MPLS header, carry only the SR-MPLS label stack of the forward direction path, as shown in Example 2 of Figure 12.

The Session-Reflector decapsulates the MPLS header and forwards the test packet using the IP header back to the Session-Sender.

8.2. Loopback Measurement Mode for Layer-3 Services over SR-MPLS Path

In loopback measurement mode for the L3 service carried over an SR-MPLS path, the SR-MPLS label stack of the data packets transmitted over the L3 service is used to encapsulate the Session-Sender test packets, as shown in Figure 13.

 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
Figure 13: Content of Session-Sender Test Packet in Loopback Measurement Mode for L3 Service over SR-MPLS Path

The IP header for the return path of the Session-Sender test packets is added, and the Destination IP Address must be set to the Session-Sender IP address. The Destination IP Address added in the IP header for the return path must be reachable via the IP table lookup associated with the L3VPN label added to the test packets.

8.2.1. SR-MPLS Return Path

The SR-MPLS label stack for the forward direction L3 service, excluding the L3VPN label advertised by the Session-Reflector, is added to the Session-Sender test packets.

In addition, the SR-MPLS label stack for the reverse direction L3 service, including its L3VPN label advertised by the Session-Sender, is added to the Session-Sender test packets.

8.2.2. IP Return Path

The SR-MPLS label stack, including the L3VPN label (advertised by the Session-Reflector) for the forward direction L3 service, is added to the Session-Sender test packets.

The Session-Reflector decapsulates the MPLS header and forwards the Session-Sender test packet back to the Session-Sender using the IP header, after adding SR-MPLS encapsulation for the reverse direction L3 service.

8.3. Loopback Measurement Mode for Layer-2 Services over SR-MPLS Path

In loopback measurement mode for the L2 service carried over an SR-MPLS path, the SR-MPLS label stack of the data packets transmitted over the L2 service is used to encapsulate the Session-Sender test packets, as shown in Figure 14.

 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
Figure 14: Content of Session-Sender Test Packet in Loopback Measurement Mode for L2 Service over SR-MPLS Path

The IP header for the return path must be added to the Session-Sender test packets, and the Destination IP Address must be set to the Session-Sender IP address.

8.3.1. SR-MPLS Return Path

The SR-MPLS label stack for the forward direction L2 service, excluding the L2VPN label advertised by the Session-Reflector, is added to the Session-Sender test packets.

In addition, the SR-MPLS label stack for the reverse direction L2 service, including its L2VPN label advertised by the Session-Sender, is added to the Session-Sender test packets with a TTL value of 1 to terminate STAMP-Test packets for control-plane processing on the Session-Sender when using the Type 3 exception specified in [I-D.ietf-mpls-stamp-pw].

8.3.2. IP Return Path

The STAMP-Test packets that do not use the SR-MPLS return path are not supported.

9. Encapsulations for Loopback with TSF Measurement Mode

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

9.1. STAMP TSF Network Actions

The MPLS Network Action (MNA) Sub-Stack is specified in [RFC9994]. This document defines two MPLS Network Action opcodes for TSF:

  • STAMP TSF with PTPv2 (opcode TBA1): A 64-bit PTPv2 timestamp written at a begin offset of 16 bytes from the start of the STAMP-Test packet payload.
  • STAMP TSF with NTPv4 (opcode TBA2): A 64-bit NTPv4 timestamp written at a begin offset of 16 bytes from the start of the STAMP-Test packet payload.
  • Format: The LSE Format B or the LSE Format C [RFC9994] can carry either TSF opcode.

  • Scope: The Ingress-to-Egress (I2E), Hop-by-Hop, and Select (IHS) field [RFC9994].

    Set the scope to "Select" when the return path is SR-MPLS (see Section 8.1.1) because the node that writes the timestamp pops the top label but does not remove the MPLS header.

    Set the scope to "I2E" when the return path is IP/UDP (see Section 8.1.2) because the node that writes the timestamp removes the MPLS header and forwards the packet using the IP header.

  • Ancillary Data: The Ancillary Data field must be set to 0.
  • Interactions: The TSF opcodes do not interact with other network action opcodes.
  • The U bit, Network Action Sub-Stack Length (NASL), and Network Action Length (NAL) must be set as specified in [RFC9994].

The timestamp is written in the "Receive Timestamp" field [RFC8972], located at a begin offset of 16 bytes from the start of the STAMP-Test packet payload, as shown in the Session-Reflector test packet in Figure 2 of Section 3 of [RFC8972].

For SR-MPLS paths in loopback with TSF measurement mode, the Session-Sender test packets carry the MNA Sub-Stack with the applicable TSF opcode in the MPLS header, as shown in Figure 15.

 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)    |
 .                                                               .
 +---------------------------------------------------------------+
Figure 15: Content of Session-Sender Test Packet in Loopback with TSF Measurement Mode Network Action in Format-B LSE for SR-MPLS Paths

The SR-MPLS label stack of the return path can be added after the MNA Sub-Stack to receive the return test packet on a specific path, as described in the loopback measurement mode for SR-MPLS paths in this document.

When a Session-Reflector receives a STAMP-Test packet with an MNA Sub-Stack containing opcode TBA1 or TBA2, it writes the timestamp to the STAMP-Test packet payload, pops the MNA Sub-Stack (after completing any other network actions), and forwards the test packet as defined in the loopback measurement mode for SR-MPLS paths.

9.1.1. TSF Network Action Node Capability

The Session-Sender must determine whether the Session-Reflector can process the applicable opcode TBA1 or TBA2 to avoid dropping the test packets. This capability can be locally configured on the Session-Sender or signaled. Signaling extensions for this capability exchange are outside the scope of this document.

10. Packet Loss Measurement in SR-MPLS Networks

The two-way measurement mode supports inferred measurements of round-trip packet loss, near-end packet loss (forward direction), and far-end packet loss (backward direction). However, these measurements provide only an approximate view of data packet loss.

The loopback measurement mode and the loopback with TSF measurement mode, 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 to measure data-packet loss. 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 procedure for measuring transmitted and received data-packet counters for SR-MPLS paths and L3 and L2 services over the SR-MPLS paths is outside the scope of this document.

In loopback measurement mode and in loopback with TSF measurement mode, 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, for example, due to:

To measure delay on different ECMP paths of a Segment List, the Session-Sender transmits STAMP-Test packets using the following mechanisms:

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.

13.1. Cisco Implementation

The following Cisco routing platforms running the IOS XR operating system have participated in interoperability testing for one-way, two-way, and loopback measurement modes for SR-MPLS:

* Cisco 8000 (based on Cisco Silicon One ASIC)

* Cisco ASR9904 with Lightspeed line card and Tomahawk line card

* Cisco NCS5500 (based on Broadcom Jericho1 ASIC)

* Cisco NCS5700 (based on Broadcom Jericho2 ASIC)

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 UDP port number 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 specified in this document.

The procedures can compute delay statistics, such as the average, minimum, maximum, and variance, as well as packet-loss statistics, such as the percentage of packets lost and the number of consecutive packets lost. They can also track STAMP session-state changes. Operator alerts are generated when metrics cross user-configured thresholds or when the session state changes.

When STAMP sessions are created for the Segment Lists of SR-MPLS Policies, the scalability of the resulting 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 IP address.

14.1. STAMP Session State Notification

The system generates a threshold-based notification for delay and packet-loss metrics only when the metrics change significantly. To support unambiguous monitoring, the controller needs to distinguish between an active STAMP session whose delay and packet-loss metrics have not crossed their thresholds and a failed session that is not transmitting or receiving test packets.

Monitoring of the STAMP session state allows the Session-Sender to determine whether the STAMP session is idle, active, or failed and to generate state-change notifications, as specified in [I-D.ietf-ippm-stamp-ext-hdr], in two-way, loopback, and loopback with TSF measurement modes.

Similarly, in one-way measurement mode, the Session-Reflector reports the STAMP session state as follows:

  • The Session-Reflector initially reports the STAMP session state as active when it receives one or more Session-Sender test packets.
  • The Session-Reflector reports the STAMP session state as failed if it does not receive N consecutive Session-Sender test packets after reporting the session as active, where N is a locally provisioned consecutive-packet-loss count.
  • The Session-Reflector changes the STAMP session state from failed to active when it again receives one or more Session-Sender test packets.

A failed STAMP session can be related to a connectivity failure of the SR-MPLS path or the L3 and L2 service carried over that path.

14.2. Operational Considerations for TSF

Processing of the TSF network action depends on the applicable TSF opcode and the corresponding timestamp format capability. Operators should verify that the Session-Reflector supports the applicable TSF opcode before enabling STAMP sessions with the TSF network action.

Implementations should maintain per-network-action counters for the following TSF Network Action events:

  • Packets with TSF Network Action received.
  • Packets in which TSF Network Action was invoked.
  • Packets with TSF Network Action dropped because the action was unknown.
  • Packets with TSF Network Action forwarded when the action was unknown.
  • Packets with TSF Network Action dropped because of a malformed packet.
  • Packets with TSF Network Action timestamp write failures.

Successful and failed TSF network action invocations should be distinguishable. Notifications for sustained failures, malformed packets, or excessive packets with the TSF network action should be rate-limited.

15. Security Considerations

The security considerations specified in [RFC8762], [RFC8972], and [RFC9503] also apply to the procedures specified 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 specified in this document.

The use of HMAC-SHA-256 in the 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 specified 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, implementations must not assign STAMP Session-IDs [RFC8972] in a predictable manner to protect against off-path attacks. To avoid predictability, implementations can leverage a Cryptographically Secure Pseudorandom Number Generator [NIST-CSPRNG].

The procedures specified in this document are intended for deployment in a single network administrative domain. As such, the Session-Sender and Session-Reflector IP addresses and the forward 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 and return paths taken by the STAMP-Test packets.

If desired, attacks can be mitigated by performing basic validation checks on the timestamp fields of reply test packets received by the Session-Sender. For example, verifying that T2 is later than T1 in the STAMP Reference Topology shown in Figure 1 requires clock synchronization between the Session-Sender and Session-Reflector. In contrast, checking that T3 is greater than or equal to T2, or that T4 is later than T1, compares timestamps generated at the same node and does not require clock synchronization. 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.

15.1. Security Considerations for TSF

The TSF network action uses the IANA-assigned opcodes TBA1 and TBA2 with timestamp formats and begin offsets. Processing of these opcodes must therefore be restricted to trusted nodes and trusted STAMP sessions. An attacker who can inject packets carrying the TSF Network Action could cause unauthorized data-plane timestamping or influence measured paths. Network operators must filter MPLS packets carrying the TSF Network Action at administrative-domain boundaries and must restrict the action to Session-Reflector nodes that support the applicable TSF opcode.

The Session-Reflector writes the timestamp defined by the TBA1 or TBA2 opcode in the STAMP-Test packet payload. Implementations must validate the MNA Sub-Stack, the opcode, the timestamp format, and the available payload length before writing the timestamp. Implementations must perform bounds checking to prevent malformed packets from causing memory corruption, packet corruption, or denial-of-service conditions. Any malformed packet carrying the TSF Network Action must be dropped.

16. IANA Considerations

IANA is requested to assign code points in the IETF Review range from the "Network Action Opcodes" registry in the "MPLS Network Actions" group as shown in Table 3.

Table 3: Network Action Opcodes
Opcode Description Applicability Reference
TBA1 STAMP TSF with PTPv2 In-Stack Only This document
TBA2 STAMP TSF with NTPv4 In-Stack Only This document

17. References

17.1. Normative References

[RFC768]
Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC768, , <https://www.rfc-editor.org/info/rfc768>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC6335]
Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, , <https://www.rfc-editor.org/info/rfc6335>.
[RFC6374]
Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, , <https://www.rfc-editor.org/info/rfc6374>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8762]
Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, , <https://www.rfc-editor.org/info/rfc8762>.
[RFC8972]
Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, "Simple Two-Way Active Measurement Protocol Optional Extensions", RFC 8972, DOI 10.17487/RFC8972, , <https://www.rfc-editor.org/info/rfc8972>.
[RFC9503]
Gandhi, R., Ed., Filsfils, C., Chen, M., Janssens, B., and R. Foote, "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks", RFC 9503, DOI 10.17487/RFC9503, , <https://www.rfc-editor.org/info/rfc9503>.
[RFC9994]
Rajamanickam, J., Ed., Gandhi, R., Ed., Zigler, R., Song, H., and K. Kompella, "MPLS Network Action (MNA) Sub-Stack Specification Including In-Stack Network Actions and Data", RFC 9994, DOI 10.17487/RFC9994, , <https://www.rfc-editor.org/info/rfc9994>.
[I-D.ietf-mpls-stamp-pw]
Gandhi, R., Brissette, P., Leyton, E., and X. Min, "Encapsulation of Simple Two-Way Active Measurement Protocol for LSPs and Pseudowires in MPLS Networks", Work in Progress, Internet-Draft, draft-ietf-mpls-stamp-pw-21, , <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-stamp-pw-21>.
[I-D.ietf-ippm-stamp-ext-hdr]
Gandhi, R., Zhou, T., Li, Z., and W. Hawkins, "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers", Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-ext-hdr-16, , <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-ext-hdr-16>.

17.2. Informative References

[RFC4026]
Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, , <https://www.rfc-editor.org/info/rfc4026>.
[RFC3031]
Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, , <https://www.rfc-editor.org/info/rfc3031>.
[RFC3032]
Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, , <https://www.rfc-editor.org/info/rfc3032>.
[RFC2681]
Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, , <https://www.rfc-editor.org/info/rfc2681>.
[RFC5462]
Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, , <https://www.rfc-editor.org/info/rfc5462>.
[RFC5905]
Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, , <https://www.rfc-editor.org/info/rfc5905>.
[RFC6056]
Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, , <https://www.rfc-editor.org/info/rfc6056>.
[RFC6234]
Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, , <https://www.rfc-editor.org/info/rfc6234>.
[RFC6790]
Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, , <https://www.rfc-editor.org/info/rfc6790>.
[RFC8029]
Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, , <https://www.rfc-editor.org/info/rfc8029>.
[RFC8085]
Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, , <https://www.rfc-editor.org/info/rfc8085>.
[RFC8402]
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <https://www.rfc-editor.org/info/rfc8402>.
[RFC8403]
Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. Kumar, "A Scalable and Topology-Aware MPLS Data-Plane Monitoring System", RFC 8403, DOI 10.17487/RFC8403, , <https://www.rfc-editor.org/info/rfc8403>.
[RFC9256]
Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, , <https://www.rfc-editor.org/info/rfc9256>.
[RFC9350]
Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, , <https://www.rfc-editor.org/info/rfc9350>.
[RFC9780]
Mirsky, G., Mishra, G., and D. Eastlake 3rd, "Bidirectional Forwarding Detection (BFD) for Multipoint Networks over Point-to-Multipoint MPLS Label Switched Paths (LSPs)", RFC 9780, DOI 10.17487/RFC9780, , <https://www.rfc-editor.org/info/rfc9780>.
[RFC10052]
Mirsky, G., Ruffini, E., Nydell, H., Foote, R., and W. Hawkins, "Performance Measurement with Asymmetrical Traffic Using the Simple Two-Way Active Measurement Protocol (STAMP)", RFC 10052, DOI 10.17487/RFC10052, , <https://www.rfc-editor.org/info/rfc10052>.
[I-D.ietf-ippm-stamp-yang]
Mirsky, G., Min, X., Luo, W. S., and R. Gandhi, "Simple Two-way Active Measurement Protocol (STAMP) Data Model", Work in Progress, Internet-Draft, draft-ietf-ippm-stamp-yang-12, , <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-yang-12>.
[IEEE.1588]
IEEE, "1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", .
[NIST-CSPRNG]
National Institute of Standards and Technology, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators, Revision 1", NIST Special Publication 800-90A Revision 1, , <https://csrc.nist.gov/pubs/sp/800/90/a/r1/final>.
[IANA-IPv6-REG]
IANA, "IANA IPv6 Special-Purpose Address Registry", <https://www.iana.org/assignments/iana-ipv6-special-registry>.

Acknowledgments

The authors would like to thank Ianik Semco and Thierry Couture for their discussions on the use cases for Performance Measurement in Segment Routing. The authors would also like to thank Greg Mirsky, Gyan Mishra, Xie Jingrong, Zafar Ali, Boris Hassanov, Ruediger Geib, Liyan Gong, Zhenqiang Li, Maria Matejka, William Hawkins, 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 specified 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

Rakesh Gandhi (editor)
Cisco Systems, Inc.
Canada
Clarence Filsfils
Cisco Systems, Inc.
Bart Janssens
Colt
Mach(Guoyi) Chen
Huawei
Richard Foote
Nokia