Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the MPLS Data Plane
draft-ietf-spring-stamp-srpm-mpls-11
| Document | Type | Active Internet-Draft (spring WG) | |
|---|---|---|---|
| Authors | Rakesh Gandhi , Clarence Filsfils , Bart Janssens , Mach Chen , Richard "Footer" Foote | ||
| Last updated | 2026-10-08 | ||
| Replaces | draft-ietf-spring-stamp-srpm | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | Haoyu Song | ||
| Shepherd write-up | Show Last changed 2026-10-06 | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | haoyu.song@futurewei.com |
draft-ietf-spring-stamp-srpm-mpls-11
SPRING Working Group R. Gandhi, Ed.
Internet-Draft C. Filsfils
Intended status: Informational Cisco Systems, Inc.
Expires: 11 April 2027 B. Janssens
Colt
M. Chen
Huawei
R. Foote
Nokia
8 October 2026
Performance Measurement Using Simple Two-Way Active Measurement Protocol
(STAMP) for Segment Routing over the MPLS Data Plane
draft-ietf-spring-stamp-srpm-mpls-11
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.
Gandhi, et al. Expires 11 April 2027 [Page 1]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Measurement Modes . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Two-Way Measurement Mode . . . . . . . . . . . . . . . . 8
4.2. One-Way Measurement Mode . . . . . . . . . . . . . . . . 9
4.3. Loopback Measurement Mode . . . . . . . . . . . . . . . . 10
4.4. Loopback with TSF Measurement Mode . . . . . . . . . . . 11
5. STAMP Reference Model . . . . . . . . . . . . . . . . . . . . 12
5.1. STAMP for One-Way Measurement Mode . . . . . . . . . . . 14
5.2. STAMP for Loopback and Loopback with TSF Measurement
Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Measurement Mode Comparison for STAMP . . . . . . . . . . 15
5.3.1. STAMP TLV Applicability . . . . . . . . . . . . . . . 16
6. Encapsulations for Two-Way Measurement Mode . . . . . . . . . 16
6.1. Session-Sender Test Packet . . . . . . . . . . . . . . . 16
6.2. Session-Sender Test Packet for SR-MPLS Data Plane . . . . 17
6.2.1. Session-Sender Test Packet for SR-MPLS Paths . . . . 17
6.2.2. Session-Sender Test Packet for Layer-3 Services over
SR-MPLS Path . . . . . . . . . . . . . . . . . . . . 19
6.2.3. Session-Sender Test Packet for Layer-2 Services over
SR-MPLS Path . . . . . . . . . . . . . . . . . . . . 20
6.3. Session-Reflector Test Packet . . . . . . . . . . . . . . 20
6.3.1. Session-Reflector Test Packet for SR-MPLS Path . . . 21
6.3.2. Session-Reflector Test Packet for an L3 Service Over
SR-MPLS Path . . . . . . . . . . . . . . . . . . . . 22
6.3.3. Session-Reflector Test Packet for an L2 Service Over
SR-MPLS Return Path . . . . . . . . . . . . . . . . . 22
7. Encapsulations for One-Way Measurement Mode . . . . . . . . . 23
Gandhi, et al. Expires 11 April 2027 [Page 2]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
8. Encapsulations for Loopback Measurement Mode . . . . . . . . 23
8.1. Loopback Measurement Mode for SR-MPLS Paths . . . . . . . 24
8.1.1. SR-MPLS Return Path . . . . . . . . . . . . . . . . . 25
8.1.2. IP Return Path . . . . . . . . . . . . . . . . . . . 25
8.2. Loopback Measurement Mode for Layer-3 Services over SR-MPLS
Path . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2.1. SR-MPLS Return Path . . . . . . . . . . . . . . . . . 27
8.2.2. IP Return Path . . . . . . . . . . . . . . . . . . . 27
8.3. Loopback Measurement Mode for Layer-2 Services over SR-MPLS
Path . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.3.1. SR-MPLS Return Path . . . . . . . . . . . . . . . . . 28
8.3.2. IP Return Path . . . . . . . . . . . . . . . . . . . 28
9. Encapsulations for Loopback with TSF Measurement Mode . . . . 29
9.1. STAMP TSF Network Actions . . . . . . . . . . . . . . . . 29
9.1.1. TSF Network Action Node Capability . . . . . . . . . 30
10. Packet Loss Measurement in SR-MPLS Networks . . . . . . . . . 31
11. Direct Measurement in SR-MPLS Networks . . . . . . . . . . . 31
12. ECMP Measurement in SR-MPLS Networks . . . . . . . . . . . . 31
13. Implementation Status . . . . . . . . . . . . . . . . . . . . 32
13.1. Cisco Implementation . . . . . . . . . . . . . . . . . . 32
14. Operational and Manageability Considerations . . . . . . . . 32
14.1. STAMP Session State Notification . . . . . . . . . . . . 33
14.2. Operational Considerations for TSF . . . . . . . . . . . 34
15. Security Considerations . . . . . . . . . . . . . . . . . . . 34
15.1. Security Considerations for TSF . . . . . . . . . . . . 35
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
17.1. Normative References . . . . . . . . . . . . . . . . . . 36
17.2. Informative References . . . . . . . . . . . . . . . . . 38
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
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).
Gandhi, et al. Expires 11 April 2027 [Page 3]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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
Gandhi, et al. Expires 11 April 2027 [Page 4]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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
+==============+====================================+=============+
| 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] |
Gandhi, et al. Expires 11 April 2027 [Page 5]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
+--------------+------------------------------------+-------------+
| SHA | Secure Hash Algorithms | [RFC6234] |
+--------------+------------------------------------+-------------+
| SID | Segment Identifier | [RFC8402] |
+--------------+------------------------------------+-------------+
| SR | Segment Routing | [RFC8402] |
+--------------+------------------------------------+-------------+
| SR-MPLS | Segment Routing over the MPLS data | [RFC8402] |
| | plane | |
+--------------+------------------------------------+-------------+
| SSID | STAMP Session Identifier | [RFC8972] |
+--------------+------------------------------------+-------------+
| STAMP | Simple Two-Way Active Measurement | [RFC8762] |
| | Protocol | |
+--------------+------------------------------------+-------------+
| 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] |
+--------------+------------------------------------+-------------+
Table 1: Abbreviations
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).
Gandhi, et al. Expires 11 April 2027 [Page 6]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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.
* STAMP-Test packets are transmitted on various transport data paths
in the network to measure the delay and packet loss experienced by
the traffic forwarded on those paths.
* STAMP-Test packets are transmitted over L3 and L2 services in the
network to measure the delay and packet loss experienced by the
traffic carried by those services.
Typically, STAMP Session-Reflector test packets are transmitted along
an IP path between the Session-Reflector and Session-Sender. 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:
* In two-way measurement mode:
Gandhi, et al. Expires 11 April 2027 [Page 7]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
The optional STAMP extensions for SR-MPLS networks, as specified
in [RFC9503], are used. The STAMP Session-Reflector uses the
return path parameters for the Session-Reflector test packet from
the STAMP extensions in the received Session-Sender test packet,
as specified in [RFC9503].
* In loopback and loopback with TSF measurement modes:
Both the forward path and the return path are included in the MPLS
encapsulation of the Session-Sender test packets using source
routing.
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.
Gandhi, et al. Expires 11 April 2027 [Page 8]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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.
Gandhi, et al. Expires 11 April 2027 [Page 9]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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
Gandhi, et al. Expires 11 April 2027 [Page 10]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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
Gandhi, et al. Expires 11 April 2027 [Page 11]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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.
Gandhi, et al. Expires 11 April 2027 [Page 12]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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.
Gandhi, et al. Expires 11 April 2027 [Page 13]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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.
Gandhi, et al. Expires 11 April 2027 [Page 14]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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
+========+=========+=========+=====+============+======+===========+
|Mode |Reflector|Timestamp|Clock| Loss |Direct| Reference |
| | | |Sync | Metrics | | |
| | | | | Applicable | | |
+========+=========+=========+=====+============+======+===========+
|Two-Way |Stateful |T1/T2/T3/|OW, | One-Way, |Yes | [RFC8762] |
| |or |T4 |TW | Round-trip | | |
| |Stateless| | | | | |
+--------+---------+---------+-----+------------+------+-----------+
|One-Way |Stateful |T1/T2 |OW | One-Way |Yes | This |
| | | | | | | document |
+--------+---------+---------+-----+------------+------+-----------+
|Loopback|N/A |T1/T4 |RT | Round-trip |No | This |
| | | | | | | document |
+--------+---------+---------+-----+------------+------+-----------+
|Loopback|N/A |T1/T2/T4 |OW, | Round-trip |No | This |
|with TSF| | |RT | | | document |
+--------+---------+---------+-----+------------+------+-----------+
Table 2: Measurement Mode Comparison for STAMP
OW: One-way delay metric (T2 - T1) computation requires clock
synchronization.
Gandhi, et al. Expires 11 April 2027 [Page 15]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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:
* Type 1 (Extra Padding) [RFC8972].
* Type 8 (HMAC) [RFC8972].
The following STAMP TLVs specified for two-way measurement mode are
not applicable in one-way, loopback, and loopback with TSF
measurement modes:
* Type 2 (Location) [RFC8972].
* Type 3 (Timestamp Information) [RFC8972].
* Type 4 (Class of Service) [RFC8972].
* Type 5 (Direct Measurement) [RFC8972].
* Type 6 (Access Report) [RFC8972].
* Type 7 (Follow-Up Telemetry) [RFC8972].
* Type 9 (Destination Node IPv4 or IPv6 Address) [RFC9503].
* Type 10 (Return Path) [RFC9503].
* Type 12 (Reflected Test Packet Control) [RFC10052].
* Reflected Fixed Header Data [I-D.ietf-ippm-stamp-ext-hdr].
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].
Gandhi, et al. Expires 11 April 2027 [Page 16]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
+---------------------------------------------------------------+
| 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.
Gandhi, et al. Expires 11 April 2027 [Page 17]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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).
Gandhi, et al. Expires 11 April 2027 [Page 18]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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-
Gandhi, et al. Expires 11 April 2027 [Page 19]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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.
Gandhi, et al. Expires 11 April 2027 [Page 20]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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.
Gandhi, et al. Expires 11 April 2027 [Page 21]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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.
Gandhi, et al. Expires 11 April 2027 [Page 22]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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
Gandhi, et al. Expires 11 April 2027 [Page 23]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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
Gandhi, et al. Expires 11 April 2027 [Page 24]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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.
Gandhi, et al. Expires 11 April 2027 [Page 25]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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
Gandhi, et al. Expires 11 April 2027 [Page 26]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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.
Gandhi, et al. Expires 11 April 2027 [Page 27]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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.
Gandhi, et al. Expires 11 April 2027 [Page 28]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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].
Gandhi, et al. Expires 11 April 2027 [Page 29]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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.
Gandhi, et al. Expires 11 April 2027 [Page 30]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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:
* Use of a Node Prefix SID label [RFC8402].
* Use of an Anycast SID label [RFC8402], which can result in ECMP
paths via transit nodes that are part of that anycast group.
To measure delay on different ECMP paths of a Segment List, the
Session-Sender transmits STAMP-Test packets using the following
mechanisms:
Gandhi, et al. Expires 11 April 2027 [Page 31]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
* Different entropy label values [RFC6790] are used in the Session-
Sender and Session-Reflector test packets to take advantage of the
hashing function in the forwarding plane and influence the ECMP
path taken by the packets.
* Different Destination IPv4 Address values from the 127/8 range are
used in the Session-Sender and Session-Reflector test packets to
traverse different IPv4 ECMP paths, as described in Section 2.1 of
[RFC8029]. In this case, the Session-Sender test packets may
carry the "Destination Node IPv4 or IPv6 Address" STAMP TLV, as
defined in [RFC9503], to identify the intended Session-Reflector
IP address.
The considerations for loss measurement for different ECMP paths of
an SR-MPLS path are outside the scope of this document.
13. Implementation Status
Editorial note: Please remove this section prior to publication.
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.
Gandhi, et al. Expires 11 April 2027 [Page 32]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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.
Gandhi, et al. Expires 11 April 2027 [Page 33]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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.
Gandhi, et al. Expires 11 April 2027 [Page 34]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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.
Gandhi, et al. Expires 11 April 2027 [Page 35]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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.
+========+======================+===============+===============+
| Opcode | Description | Applicability | Reference |
+========+======================+===============+===============+
| TBA1 | STAMP TSF with PTPv2 | In-Stack Only | This document |
+--------+----------------------+---------------+---------------+
| TBA2 | STAMP TSF with NTPv4 | In-Stack Only | This document |
+--------+----------------------+---------------+---------------+
Table 3: Network Action Opcodes
17. References
17.1. Normative References
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC768, August 1980,
<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, March 1997,
<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, August 2011,
<https://www.rfc-editor.org/info/rfc6335>.
Gandhi, et al. Expires 11 April 2027 [Page 36]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011,
<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,
May 2017, <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, March 2020,
<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, January 2021,
<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, October 2023,
<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, June 2026,
<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,
10 September 2026, <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, 7
October 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-ippm-stamp-ext-hdr-16>.
Gandhi, et al. Expires 11 April 2027 [Page 37]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
17.2. Informative References
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005,
<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, January 2001,
<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, January 2001,
<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,
September 1999, <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, February
2009, <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, June 2010,
<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, January 2011,
<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, May 2011,
<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, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
Gandhi, et al. Expires 11 April 2027 [Page 38]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
[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, March 2017,
<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,
March 2017, <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,
July 2018, <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, July
2018, <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, July 2022,
<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, February 2023,
<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, May 2025,
<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,
September 2026,
<https://www.rfc-editor.org/info/rfc10052>.
Gandhi, et al. Expires 11 April 2027 [Page 39]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
[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, 5 November 2023,
<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", March 2008.
[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, 2015,
<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
Gandhi, et al. Expires 11 April 2027 [Page 40]
Internet-Draft STAMP for Segment Routing over MPLS October 2026
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
Email: rgandhi@cisco.com
Clarence Filsfils
Cisco Systems, Inc.
Email: cfilsfil@cisco.com
Bart Janssens
Colt
Email: Bart.Janssens@colt.net
Mach(Guoyi) Chen
Huawei
Email: mach.chen@outlook.com
Richard Foote
Nokia
Email: footer.foote@nokia.com
Gandhi, et al. Expires 11 April 2027 [Page 41]