Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the MPLS Data Plane
draft-ietf-spring-stamp-srpm-mpls-07
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Rakesh Gandhi , Clarence Filsfils , Bart Janssens , Mach Chen , Richard "Footer" Foote | ||
| Last updated | 2026-09-12 (Latest revision 2026-08-18) | ||
| Replaces | draft-ietf-spring-stamp-srpm | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | Haoyu Song | ||
| Shepherd write-up | Show Last changed 2026-08-03 | ||
| 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-07
SPRING Working Group R. Gandhi, Ed.
Internet-Draft C. Filsfils
Intended status: Informational Cisco Systems, Inc.
Expires: 16 March 2027 B. Janssens
Colt
M. Chen
Individual
R. Foote
Nokia
12 September 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-07
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 further
augmented in RFC 9503. The described procedures are used for 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 the SR-MPLS 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 16 March 2027.
Gandhi, et al. Expires 16 March 2027 [Page 1]
Internet-Draft STAMP for Segment Routing over MPLS September 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 . . . . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. STAMP Reference Model . . . . . . . . . . . . . . . . . . 7
3.2. Measurement Mode Comparison . . . . . . . . . . . . . . . 9
4. Two-Way Measurement Mode . . . . . . . . . . . . . . . . . . 10
4.1. Session-Sender Test Packet . . . . . . . . . . . . . . . 11
4.2. Session-Sender Test Packet for SR-MPLS Data Plane . . . . 11
4.2.1. Session-Sender Test Packet for SR-MPLS Paths . . . . 11
4.2.2. Session-Sender Test Packet for Layer-3 Services over
SR-MPLS Path . . . . . . . . . . . . . . . . . . . . 13
4.2.3. Session-Sender Test Packet for Layer-2 Services over
SR-MPLS Path . . . . . . . . . . . . . . . . . . . . 14
4.3. Session-Reflector Test Packet . . . . . . . . . . . . . . 14
5. One-Way Measurement Mode . . . . . . . . . . . . . . . . . . 16
5.1. STAMP Reference Model Considerations for One-Way
Measurement Mode . . . . . . . . . . . . . . . . . . . . 16
6. Loopback Measurement Mode . . . . . . . . . . . . . . . . . . 17
6.1. STAMP Reference Model Considerations for Loopback
Measurement Mode . . . . . . . . . . . . . . . . . . . . 17
6.2. Loopback Measurement Mode for SR-MPLS Paths . . . . . . . 18
6.2.1. SR-MPLS Return Path . . . . . . . . . . . . . . . . . 20
6.2.2. IP Return Path . . . . . . . . . . . . . . . . . . . 20
6.3. Loopback Measurement Mode for Layer-3 Services over SR-MPLS
Path . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3.1. SR-MPLS Return Path . . . . . . . . . . . . . . . . . 22
6.3.2. IP Return Path . . . . . . . . . . . . . . . . . . . 22
6.4. Loopback Measurement Mode for Layer-2 Services over SR-MPLS
Path . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.4.1. SR-MPLS Return Path . . . . . . . . . . . . . . . . . 23
Gandhi, et al. Expires 16 March 2027 [Page 2]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
6.4.2. IP Return Path . . . . . . . . . . . . . . . . . . . 23
7. Loopback Measurement Mode with TSF . . . . . . . . . . . . . 24
7.1. Loopback Measurement Mode with TSF Network Action for
SR-MPLS Data Plane . . . . . . . . . . . . . . . . . . . 25
7.1.1. TSF Network Action Node Capability . . . . . . . . . 26
8. Packet Loss Measurement in SR-MPLS Networks . . . . . . . . . 27
9. Direct Measurement in SR-MPLS Networks . . . . . . . . . . . 27
10. ECMP Measurement in SR-MPLS Networks . . . . . . . . . . . . 27
11. STAMP Session State . . . . . . . . . . . . . . . . . . . . . 28
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 29
12.1. Cisco Implementation . . . . . . . . . . . . . . . . . . 29
13. Operational and Manageability Considerations . . . . . . . . 30
13.1. Operational Considerations for TSF . . . . . . . . . . . 30
14. Security Considerations . . . . . . . . . . . . . . . . . . . 31
14.1. Security Considerations for TSF . . . . . . . . . . . . 32
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
16.1. Normative References . . . . . . . . . . . . . . . . . . 33
16.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction
Segment Routing (SR) [RFC8402] can be used to steer packets through a
network employing source routing. SR can be applied to both MPLS
(SR-MPLS) and IPv6 (SRv6) data planes. SR can take advantage of
Equal-Cost Multipath (ECMP) between source and transit nodes, between
transit nodes, and between transit and destination nodes. SR
Policies, as defined in [RFC9256], are used to steer traffic through
specific user-defined paths using a list of segments.
A comprehensive SR performance measurement toolset is an essential
requirement for measuring network performance and providing Service
Level Agreements (SLAs).
The Simple Two-Way Active Measurement Protocol (STAMP), as specified
in [RFC8762], provides the capability to measure various performance
metrics in IP networks without the use of a control channel to pre-
signal session parameters. [RFC8972] specifies optional extensions
in the form of Type-Length-Value (TLV) objects for STAMP, and
[RFC9503] further augments that framework to define STAMP extensions
for SR networks.
This document describes the procedures for performance measurement in
SR-MPLS networks, using STAMP as specified in [RFC8762], along with
its optional extensions specified in [RFC8972] and augmented in
Gandhi, et al. Expires 16 March 2027 [Page 3]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
[RFC9503]. The described procedures are used for SR-MPLS paths
[RFC8402] (including Segment Lists of SR-MPLS Policies [RFC9256], SR-
MPLS IGP best paths, and SR-MPLS IGP Flexible Algorithm (Flex-Algo)
paths [RFC9350]), as well as Layer-3 (L3) and Layer-2 (L2) services
carried over the SR-MPLS paths.
STAMP requires protocol support on the Session-Reflector to process
the received test packets. As a result, the received test packets
need to be punted from the fast path in the data plane for control-
plane processing, and the return test packets need to be generated.
This limits the frequency of STAMP test packets and the ability to
provide shorter measurement intervals. This document adds 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 loopback with TSF
mode does not support the STAMP in authenticated mode defined in
[RFC8762].
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. 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] |
Gandhi, et al. Expires 16 March 2027 [Page 4]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
+--------------+--------------------------------------+-------------+
| MNA | MPLS Network Action | [RFC9994] |
+--------------+--------------------------------------+-------------+
| MPLS | Multiprotocol Label Switching | [RFC3032] |
+--------------+--------------------------------------+-------------+
| NTP | Network Time Protocol | [RFC5905] |
+--------------+--------------------------------------+-------------+
| PHP | Penultimate Hop Popping | [RFC3031] |
+--------------+--------------------------------------+-------------+
| PSID | Path Segment Identifier | [RFC9545] |
+--------------+--------------------------------------+-------------+
| 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 with 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
Gandhi, et al. Expires 16 March 2027 [Page 5]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
3. Overview
For performance measurement in SR-MPLS networks, the STAMP Session-
Sender and Session-Reflector use the STAMP test packets defined in
[RFC8762], along with optional extensions defined in [RFC8972]. The
STAMP test packets are encapsulated using an IP/UDP header, as
specified in [RFC8762]. In this document, the STAMP test packets
using the IP/UDP header are used for SR-MPLS networks, where the
STAMP test packets are further encapsulated with an MPLS header.
STAMP test packets are transmitted in one of the following
performance measurement modes in SR-MPLS networks where processing on
Session-Reflector varies:
1. Two-way measurement: Session-Reflector generates and transmits
Session-Reflector test packets (see Section 4).
2. One-way measurement: Session-Reflector does not generate and
transmit Session-Reflector test packets (see Section 5).
3. Loopback measurement: Session-Reflector does not perform STAMP
processing (see Section 6).
4. Loopback measurement with TSF: Session-Reflector writes the
receive timestamp in fast path but does not perform STAMP
processing (see Section 7).
Note that the two-way measurement mode is referenced in the STAMP
process in [RFC8762] and is further described for SR-MPLS networks in
this document. The other measurement modes are new, specific to SR-
MPLS networks, and not defined in [RFC8762].
STAMP test packets are transmitted on the same path as the data
traffic flow under measurement to measure the delay and packet loss
experienced by the data traffic flow, using the same SR-MPLS
encapsulation as the data traffic flow. Similarly, STAMP test
packets are transmitted on various transport data paths in the
network to measure the delay and packet loss experienced by the
traffic forwarded on those transport data paths. The STAMP test
packets are transmitted over L3 and L2 services in the network to
measure the delay and packet loss experienced by the traffic carried
by those services. Further, the STAMP test packets carry the same
MPLS headers as the data packets transmitted on the SR-MPLS path and
on the L3 and L2 services for the data traffic forwarded on those
services.
Gandhi, et al. Expires 16 March 2027 [Page 6]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
Typically, STAMP Session-Reflector test packets are transmitted along
an IP path between the Session-Reflector and Session-Sender.
Matching the forward direction path and the return path for STAMP
test packets, even for directly connected nodes, is not guaranteed.
In SR-MPLS networks, it may be desired that the same path (i.e., the
same set of links and nodes) between the Session-Sender and Session-
Reflector be used for the STAMP test packets in both directions, for
example, in an ECMP environment. This is achieved as follows:
* In two-way measurement mode, this is achieved by using the
optional STAMP extensions for SR-MPLS, as specified in [RFC9503].
The STAMP Session-Reflector uses the return path parameters for
the Session-Reflector test packet from the STAMP extensions in the
received Session-Sender test packet, as described in [RFC9503].
* In loopback measurement mode, this is achieved by adding both the
forward direction path and the return path in the SR-MPLS
encapsulation of the Session-Sender test packets.
The performance measurement procedures defined in this document are
used to measure both delay and packet loss in SR-MPLS networks based
on the transmission and reception of STAMP test packets. The
optional STAMP extensions, as defined in [RFC8972], are used for
direct measurement in SR-MPLS networks.
3.1. STAMP Reference Model
The STAMP Reference Model, along with some typical measurement
parameters, as defined in [RFC8972] for a STAMP session, is shown in
Figure 1.
Gandhi, et al. Expires 16 March 2027 [Page 7]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
+------------+
| 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 1: STAMP Reference Model
The procedure defined in [RFC8972] uses the two-way measurement mode.
The base STAMP test packet payloads [RFC8972] are transported using
an IP/UDP header and a destination UDP port [RFC6335], selected as
specified in Section 4.1 of [RFC8762]. The same destination port can
be selected for STAMP sessions for SR-MPLS paths, and for L3 and L2
services carried over the SR-MPLS paths.
The source UDP port is selected by the Session-Sender. The same or
different source UDP ports may be used for different STAMP sessions.
The STAMP Session-Sender and Session-Reflector IP addresses for a
STAMP session are provisioned on both endpoints of the STAMP session.
The SSID in the STAMP test packets [RFC8972] must be set to a non-
zero value in both directions. The SSID in a STAMP test packet,
along with the local configuration for the performance measurement
mode, is used to identify STAMP sessions.
Session-Reflector mode can be either Stateful or Stateless, as
described in Section 4 of [RFC8762]. Stateless Session-Reflector
mode is applicable only in two-way measurement mode.
Gandhi, et al. Expires 16 March 2027 [Page 8]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
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 the Timestamp Format include 64-bit truncated Precision
Time Protocol (PTPv2) [IEEE.1588] and 64-bit Network Time Protocol
(NTPv4) [RFC5905]. By default, the Session-Reflector replies using
the same timestamp format as received in the Session-Sender test
packet, as indicated by the "Z" flag in the Error Estimate field, as
described in [RFC8762]. This behavior depends on the Session-
Reflector's capability.
Examples of delay metrics include one-way delay, round-trip delay,
near-end delay (forward direction), and far-end delay (backward
direction), as defined in [RFC8762].
Examples of packet-loss metric types include round-trip packet loss,
near-end packet loss (forward direction) and far-end packet loss
(backward direction), as defined 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 described 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.
3.2. Measurement Mode Comparison
+========+=========+=========+=====+==========+======+====+=========+
|Mode |Reflector|Timestamp|Clock|Loss |Direct|Auth|Reference|
| | | |Sync |Metrics |Mode |Mode| |
+========+=========+=========+=====+==========+======+====+=========+
|Two-Way |Stateful |T1/T2/T3/|No |One-Way |Yes |Yes |[RFC8762]|
| |or |T4 | |and Round-| | | |
| |Stateless| | |trip | | | |
+--------+---------+---------+-----+----------+------+----+---------+
|One-Way |Stateful |T1/T2 |Yes |One-Way |Yes |Yes |This |
Gandhi, et al. Expires 16 March 2027 [Page 9]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
| | | | | | | |document |
+--------+---------+---------+-----+----------+------+----+---------+
|Loopback|N/A |T1/T4 |No |Round-trip|No |Yes |This |
| | | | | | | |document |
+--------+---------+---------+-----+----------+------+----+---------+
|Loopback|N/A |T1/T2/T4 |No |Round-trip|No |No |This |
|with TSF| | | | | | |document |
+--------+---------+---------+-----+----------+------+----+---------+
Table 2: Measurement Mode Comparison
4. Two-Way Measurement Mode
As shown in Figure 2, in the reference topology for two-way
measurement mode, the STAMP Session-Sender S1 initiates a Session-
Sender test packet, and the STAMP Session-Reflector R1 generates and
transmits a reply Session-Reflector test packet. The Session-
Reflector test packets are transmitted to the Session-Sender S1 on
the same path (i.e., the same set of links and nodes) or on a
different path in the reverse direction from the path taken towards
the Session-Reflector R1.
T1 is a transmit timestamp, and T4 is a receive timestamp added by
node S1. T2 is a receive timestamp, and T3 is a transmit timestamp
added by node R1. All four timestamps are used by the Session-Sender
to measure the round-trip delay metric as ((T4 - T1) - (T3 - T2)).
Timestamps T1 and T2 are used by the Session-Sender to measure the
one-way delay metric as (T2 - T1), also referred to as the near-end
(forward direction) delay metric. Note that the delay value (T4 -
T3), measured by the Session-Sender, is referred to as the far-end
(backward direction) one-way delay metric.
The computation of the one-way delay metric requires the clocks on
the Session-Sender and Session-Reflector to be synchronized using
either PTPv2 or NTPv4.
T1 T2
/ \
+-------+ Test Packet +-------+
| | - - - - - - - - - ->| |
| S1 |=====================| R1 |
| |<- - - - - - - - - - | |
+-------+ Reply Test Packet +-------+
\ /
T4 T3
STAMP Session-Sender STAMP Session-Reflector
Gandhi, et al. Expires 16 March 2027 [Page 10]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
Figure 2: Reference Topology for Two-Way Measurement Mode
The nodes S1 and R1 may be connected via an SR-MPLS path [RFC8402].
The SR-MPLS path may be a Segment List (i.e., a stack of MPLS labels)
of an SR-MPLS Policy [RFC9256] on node S1 (referred to as the "head-
end") with node R1 as the destination (referred to as the
"endpoint"), an SR-MPLS IGP best path, or an SR-MPLS IGP Flex-Algo
path [RFC9350]. Additionally, a L3 or L2 VPN service may be carried
over the SR-MPLS path between nodes S1 and R1.
4.1. Session-Sender Test Packet
The content of a Session-Sender test packet is shown in Figure 3.
The Session-Sender test packet payload, as defined in Section 3 of
[RFC8972], is transmitted with an IP and 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 Section 3 of RFC 8972 |
. in Figures 1 and 3 .
. .
+---------------------------------------------------------------+
Figure 3: Content of Session-Sender Test Packet
4.2. Session-Sender Test Packet for SR-MPLS Data Plane
4.2.1. Session-Sender Test Packet for SR-MPLS Paths
An SR-MPLS Policy Candidate-Path contains one or more Segment Lists
(i.e., a stack of MPLS labels) [RFC9256]. For delay measurement of
an SR-MPLS Policy, the Session-Sender test packets are transmitted
for every Segment List of the Candidate-Path of the SR-MPLS Policy,
by creating a separate STAMP session for each Segment List.
Gandhi, et al. Expires 16 March 2027 [Page 11]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
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].
The content of a Session-Sender test packet for an SR-MPLS path,
using the SR-MPLS encapsulation of the data traffic transmitted over
the path, is shown in Figure 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) (Top of Stack) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(n) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 3 |
. .
+---------------------------------------------------------------+
Figure 4: Content of Session-Sender Test Packet for SR-MPLS Path
The head-end node address of the SR-MPLS Policy is used as the Source
Address in the IP header of the Session-Sender test packet. There
are two cases for the SR Policy endpoints, as described below.
* The endpoint address of the SR-MPLS Policy is used as the
Destination Address in the IP header of the Session-Sender test
packet when it is specified and is not the null endpoint. In the
case of Penultimate Hop Popping (PHP), the MPLS header is removed
by the penultimate node. In this case, the specified Destination
Address in the IP header ensures that the test packets reach the
Session-Reflector at the SR-MPLS Policy endpoint.
* For an SR-MPLS Policy with Color-Only Destination Steering, where
the endpoint is an unspecified address (the null endpoint is
0.0.0.0 for IPv4, as defined in Section 8.8.1 of [RFC9256]), a
loopback address from the range 127/8 for IPv4 is used as the
Destination Address in the IPv4 header. For IPv6 traffic, the
IPv6 address of the Session-Sender is used as the Source 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 Address
in the IPv6 header. In this case, the SR-MPLS encapsulation
ensures that the Session-Sender test packets reach the SR-MPLS
Policy endpoint, for example, by adding the Prefix SID label of
Gandhi, et al. Expires 16 March 2027 [Page 12]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
the SR-MPLS Policy endpoint to the Segment List. In addition, the
Session-Sender test packets carry the "Destination Node IPv4 or
IPv6 Address" STAMP TLV as defined in [RFC9503] to identify the
intended Session-Reflector 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.
4.2.2. Session-Sender Test Packet for Layer-3 Services over SR-MPLS
Path
For delay measurement of the L3 service 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 5.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) (Top of Stack) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3VPN Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 3 |
. Destination IP Address in L3VPN table .
. Source IP Address in L3VPN table-reverse direction .
. .
+---------------------------------------------------------------+
Figure 5: Content of Session-Sender Test Packet for L3 Service
over SR-MPLS Path
An IP header, as shown in Figure 3, is added to the Session-Sender
test packets after the MPLS header. The Destination Address in the
IP header is reachable via the IP table lookup associated with the
Gandhi, et al. Expires 16 March 2027 [Page 13]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
L3VPN label added for the L3 service on the Session-Reflector. The
Source Address in the IP header of the Session-Sender test packets is
reachable via the IP table lookup associated with the L3 service in
the reverse direction.
4.2.3. Session-Sender Test Packet for Layer-2 Services over SR-MPLS
Path
For delay measurement of the L2 service 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 6.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) (Top of Stack) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2VPN Label | TC |1| TTL=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 3 |
. .
+---------------------------------------------------------------+
Figure 6: 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 punt the Session-
Sender STAMP test packet from the fast path in the data plane 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 3, is added to the Session-Sender
test packets after the MPLS header. This header contains the
Session-Sender Address as the Source Address and the Session-
Reflector Address as the Destination Address.
4.3. Session-Reflector Test Packet
In two-way measurement mode, the Session-Reflector test packets are
transmitted on the same SR-MPLS path (i.e., the same set of links and
nodes) in the reverse direction to the Session-Sender to perform
accurate two-way delay measurement.
Gandhi, et al. Expires 16 March 2027 [Page 14]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
The Session-Reflector decapsulates the MPLS header, if present, from
the received Session-Sender test packets. The Session-Reflector test
packet is generated using the information from the received IP/UDP
header of the Session-Sender test packet, as shown in Figure 7.
+---------------------------------------------------------------+
| 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 Section 3 of RFC 8972 |
. in Figures 2 and 4 .
. .
+---------------------------------------------------------------+
Figure 7: Content of Session-Reflector Test Packet
The payload contains the Session-Reflector test packet defined in
Section 3 of [RFC8972].
For SR-MPLS paths, the Session-Sender uses the Segment List sub-TLV
in the Return Path TLV defined in [RFC9503] to request that the
Session-Reflector transmit the Session-Reflector test packet on a
specific SR-MPLS return path.
Examples of specific SR-MPLS return paths include:
* The reverse SR-MPLS path associated with the forward direction SR-
MPLS path.
* The Binding SID label of the reverse SR-MPLS Policy.
* The Prefix SID of the Session-Sender.
For SR-MPLS IGP Flex-Algo paths, the Session-Sender uses the Segment
List sub-TLV in the Return Path TLV defined in [RFC9503] to request
that the Session-Reflector transmit the Session-Reflector test packet
on the same SR-MPLS IGP Flex-Algo path in the reverse direction.
Gandhi, et al. Expires 16 March 2027 [Page 15]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
5. One-Way Measurement Mode
As shown in Figure 8, in the reference topology for one-way
measurement mode, the STAMP Session-Sender S1 initiates a Session-
Sender test packet. The STAMP Session-Reflector does not transmit
Session-Reflector test packets upon receiving the Session-Sender test
packets.
T1 is a transmit timestamp added by node S1, and T2 is a receive
timestamp added by node R1. Timestamps T1 and T2 are used by the
Session-Reflector to measure the one-way delay metric as (T2 - T1).
The computation of the one-way delay metric requires the clocks on
the Session-Sender and Session-Reflector to be synchronized using
either PTPv2 or NTPv4.
T1 T2
/ \
+-------+ Test Packet +-------+
| | - - - - - - - - - ->| |
| S1 |=====================| R1 |
| | | |
+-------+ +-------+
STAMP Session-Sender STAMP Session-Reflector
Figure 8: Reference Topology for One-Way Measurement Mode
5.1. STAMP Reference Model Considerations for One-Way Measurement Mode
In one-way measurement mode, for SR-MPLS paths and for L3 and L2
services carried over the SR-MPLS paths, the Session-Sender test
packets, as specified in Section 4 for STAMP sessions, are
transmitted.
In one-way measurement mode, the Stateful mode of the Session-
Reflector is used. 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.
Typically, a different destination UDP port is selected for one-way
measurement mode than the one used by the Session-Reflector for two-
way measurement mode. When the same Session-Reflector UDP port is
selected for one-way measurement mode, the Session-Sender requests
that the Session-Reflector not transmit Session-Reflector test
packets by including the "No Reply Requested" flag in the Control
Code Sub-TLV within the Return Path TLV defined in [RFC9503].
Gandhi, et al. Expires 16 March 2027 [Page 16]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
6. Loopback Measurement Mode
As shown in Figure 9, in the reference topology for loopback
measurement mode, the STAMP Session-Sender S1 initiates a Session-
Sender test packet to measure the loopback delay of a bidirectional
path. At the STAMP Session-Reflector, the received Session-Sender
STAMP test packets remain in the fast path in the data plane and are
simply forwarded. In other words, the Session-Reflector does not
perform STAMP functions or generate Session-Reflector test packets.
T1
/
+-------+ Test Packet +-------+
| | - - - - - - - - - - | |
| S1 |====================|| R1 |
| |<- - - - - - - - - - | |
+-------+ Return Test Packet +-------+
\
T4
STAMP Session-Sender STAMP Session-Reflector
(Loopback,
Forward)
Figure 9: Reference Topology for Loopback Measurement Mode
The Session-Sender retrieves timestamp T1 from the received Session-
Sender test packet and records receive timestamp T4 locally. The
loopback delay is measured as (T4 - T1). This delay includes STAMP
test packet processing on the Session-Reflector. The processing
delay includes only the time required to forward the test packet from
the incoming interface to the outgoing interface in the data plane.
The Session-Reflector does not write a timestamp in the STAMP test
packets and therefore does not require timestamping capability.
6.1. STAMP Reference Model Considerations for Loopback Measurement Mode
The Session-Sender test packets are encapsulated with the forward
direction SR-MPLS path and transmitted to the Session-Reflector, as
specified in Section 4 for STAMP sessions. An IP header is added for
the return path in the Session-Sender test packets, setting the
Destination Address to the Session-Sender address, as shown in
Figure 10, to return the test packets to the Session-Sender.
Gandhi, et al. Expires 16 March 2027 [Page 17]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
+---------------------------------------------------------------+
| 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 Section 3 of RFC 8972 |
. in Figures 1 and 3 .
. .
+---------------------------------------------------------------+
Figure 10: Content of Session-Sender Return Test Packet in
Loopback Measurement Mode
The Session-Reflector does not perform the STAMP process. Instead,
its loopback function simply processes the IP and MPLS headers
(ignoring the UDP header) to forward the test packet back to the
Session-Sender without any STAMP modifications [RFC8762].
The SSID field in the Session-Sender test packets received by the
Session-Sender [RFC8972], along with the local configuration, is used
to identify the STAMP sessions that use loopback measurement mode.
The Session-Sender sets the destination UDP port to the UDP port it
uses to receive the return Session-Reflector test packets (other than
the destination UDP port 862, which is used by the Session-
Reflector). The same UDP port is used as both the destination and
source UDP port in the Session-Sender test packets, as shown in
Figure 10.
At the Session-Sender, the "Session-Sender Sequence Number", the
"Session-Sender Timestamp", the "Session-Sender Error Estimate", and
the "Session-Sender TTL" fields are all set to zero in the
transmitted Session-Sender test packets and are ignored in the
received test packets.
6.2. Loopback Measurement Mode for SR-MPLS Paths
In loopback measurement mode for SR-MPLS paths, the Session-Sender
test packet carries either the Segment List of the forward direction
path only or both the forward direction and return paths in the MPLS
header, as specified in [RFC8403], as shown in Figure 11.
Gandhi, et al. Expires 16 March 2027 [Page 18]
Internet-Draft STAMP for Segment Routing over MPLS September 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Return Path Label(n) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 10 (Return Path) |
. .
+---------------------------------------------------------------+
Example 1: Encapsulation Using SR-MPLS Return Path
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) (Top of Stack) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(n) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 10 (Return Path) |
. .
+---------------------------------------------------------------+
Example 2: Encapsulation Using IP Return Path
Figure 11: Content of Session-Sender Test Packet in Loopback
Measurement Mode for SR-MPLS Path
In the case of an SR-MPLS Policy using Penultimate Hop Popping (PHP),
the Session-Sender ensures 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.
Gandhi, et al. Expires 16 March 2027 [Page 19]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
The IP header for the return path is added to the Session-Sender test
packets, and the Destination Address is set to the Session-Sender
address in the IP header.
6.2.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 11. 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.
6.2.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 11.
The Session-Reflector decapsulates the MPLS header and forwards the
test packet using the IP header back to the Session-Sender.
6.3. Loopback Measurement Mode for Layer-3 Services over SR-MPLS Path
In loopback measurement mode for the L3 service 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 12.
Gandhi, et al. Expires 16 March 2027 [Page 20]
Internet-Draft STAMP for Segment Routing over MPLS September 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 10 (Return Path) |
. Source and Destination IP Address in L3VPN table .
. .
+---------------------------------------------------------------+
Example 1: Encapsulation Using SR-MPLS Return Path
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label(1) (Top of Stack) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L3VPN Label (Forward Path) | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 10 (Return Path) |
. Source and Destination IP Address in L3VPN table .
. .
+---------------------------------------------------------------+
Example 2: Encapsulation Using IP Return Path
Figure 12: Content of Session-Sender Test Packet in Loopback
Measurement Mode for L3 Service over SR-MPLS Path
Gandhi, et al. Expires 16 March 2027 [Page 21]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
The IP header for the return path of the Session-Sender test packets
is added, setting the Destination Address to the Session-Sender
address. The Destination 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.
6.3.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, is added to the Session-Sender
test packets.
6.3.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.
6.4. Loopback Measurement Mode for Layer-2 Services over SR-MPLS Path
In loopback measurement mode for the L2 service 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 13.
Gandhi, et al. Expires 16 March 2027 [Page 22]
Internet-Draft STAMP for Segment Routing over MPLS September 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 10 (Return Path) |
. .
+---------------------------------------------------------------+
Encapsulation Using SR-MPLS Return Path
Figure 13: Content of Session-Sender Test Packet in Loopback
Measurement Mode for L2 Service over SR-MPLS Path
The IP header for the return path is added to the Session-Sender test
packets, and the Destination Address is set to the Session-Sender
address.
6.4.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, is added to the Session-Sender
test packets with a TTL value of 1 to punt STAMP test packets from
the fast path in the data plane for control-plane processing on the
Session-Sender when using the Type 3 exception specified in
[I-D.ietf-mpls-stamp-pw].
6.4.2. IP Return Path
The STAMP test packets that do not use the SR-MPLS return path are
not supported.
Gandhi, et al. Expires 16 March 2027 [Page 23]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
7. Loopback Measurement Mode with TSF
As shown in Figure 14, in the reference topology for loopback
measurement mode with TSF, the STAMP Session-Sender S1 initiates a
test packet in loopback measurement mode. TSF optimizes punting the
test packet from the fast path in the data plane for control-plane
processing and generating the return test packet by writing the
timestamp in the data-plane fast path. This allows to support a
larger number of STAMP sessions and shorter measurement intervals.
T1 T2
/ \
+-------+ Test Packet +-------+
| | - - - - - - - - - - | |
| S1 |====================|| R1 |
| |<- - - - - - - - - - | |
+-------+ Return Test Packet +-------+
\
T4
STAMP Session-Sender STAMP Session-Reflector
(Loopback,
TSF)
Figure 14: Reference Topology for Loopback Measurement Mode with TSF
The Session-Sender retrieves the timestamps T1 and T2 from the
received Session-Sender test packet and collects the receive
timestamp T4 locally. Timestamps T1 and T2 are used by the Session-
Sender to measure the one-way delay metric as (T2 - T1). Timestamps
T1 and T4 are used by the Session-Sender to measure the loopback
delay metric as (T4 - T1).
The Session-Sender adds the transmit timestamp (T1) to the payload of
the Session-Sender test packet. The Session-Reflector 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 for control-plane STAMP processing.
The loopback measurement mode with TSF is only supported for the
unauthenticated mode Session-Reflector test packet defined in
Figure 2 of Section 3 of [RFC8972] and is not supported for the
authenticated mode Session-Reflector test packet defined in Figure 4
of Section 3 of [RFC8972].
Gandhi, et al. Expires 16 March 2027 [Page 24]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
7.1. Loopback Measurement Mode with TSF Network Action for SR-MPLS Data
Plane
The MPLS Network Action (MNA) Sub-Stack specified in [RFC9994] is
used for the STAMP test packets in the loopback measurement mode with
TSF. This document defines two MPLS Network Action opcodes for the
Timestamp and Forward (TSF) Network Action:
* 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] must be set to "I2E" when the return path is IP/
UDP (see Section 6.2.2) because the node that writes the timestamp
removes the MPLS header, and must be set to "Select" when the
return path is SR-MPLS (see Section 6.2.1) because the node that
writes the timestamp does not remove the MPLS header.
* Ancillary Data: 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) are set as defined in [RFC9994].
The TSF opcode enables the Session-Reflector to write the 64-bit
timestamp 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].
In the Session-Sender test packets for SR-MPLS paths, the MNA Sub-
Stack with either TSF opcode is added to the MPLS header, as shown in
Figure 15.
Gandhi, et al. Expires 16 March 2027 [Page 25]
Internet-Draft STAMP for Segment Routing over MPLS September 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MNA Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7-bit TBA1 | 13-bit (value 0x0) |R|IHS|S| NASL |U| NAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test Packet as shown in Figure 10 (Return Path) |
. .
+---------------------------------------------------------------+
Figure 15: Content of Session-Sender Test Packet in Loopback
Measurement Mode with TSF 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 in
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 in this
document.
7.1.1. TSF Network Action Node Capability
The Session-Sender needs to know if the Session-Reflector is capable
of processing opcode TBA1 or TBA2, as applicable, 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 16 March 2027 [Page 26]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
8. Packet Loss Measurement in SR-MPLS Networks
The procedure described for two-way measurement mode supports
inferred measurements of round-trip, near-end (forward direction),
and far-end (backward direction) packet loss. However, this provides
only an approximate view of data packet loss.
The loopback measurement mode and loopback measurement mode with TSF,
defined in this document, allow only round-trip packet loss
measurement.
Note that the packet loss measurement does not require the clocks on
the Session-Sender and Session-Reflector to be synchronized using
either PTPv2 or NTPv4.
9. Direct Measurement in SR-MPLS Networks
The STAMP "Direct Measurement" TLV (Type 5), defined in [RFC8972], is
used in SR-MPLS networks for data packet loss measurement. To
collect direct-measurement counters for data packet flows, STAMP test
packets containing this TLV are transmitted using the two-way
measurement-mode procedure. The procedure collects Session-Sender
transmit counters and Session-Reflector receive and transmit
counters.
The receive data traffic can be measured as follows:
* The Path Segment Identifier (PSID) [RFC9545] of an SR-MPLS Policy
(for the Segment List or for the Candidate-Path) may be carried in
the data packets to measure received data traffic (for the receive
packet counter) on the associated SR-MPLS path when the egress
node supports PSID processing.
* In the case of L3 and L2 services in SR-MPLS networks, the
associated SR-MPLS service labels are used to measure received
data traffic (for the receive packet counters) on the Session-
Reflector.
In loopback measurement mode and loopback measurement mode with TSF,
direct measurement is not applicable.
10. ECMP Measurement in SR-MPLS Networks
The Segment List of an SR-MPLS path can have ECMP paths between the
source and transit nodes, between transit nodes, and between transit
and destination nodes, due to, for example:
* Use of a node SID [RFC8402].
Gandhi, et al. Expires 16 March 2027 [Page 27]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
* Use of an Anycast SID [RFC8402], which can result in ECMP paths
via transit nodes that are part of that anycast group.
The STAMP test packets are transmitted to traverse different ECMP
paths to measure the delay of each ECMP path of a Segment List, and
can use the following mechanisms.
* Different entropy label values [RFC6790] are used in the Session-
Sender and Session-Reflector test packets to take advantage of the
hashing function in the forwarding plane and influence the ECMP
path taken by the packets.
* Different Destination Address values from the IPv4 range 127/8 are
used in the Session-Sender and Session-Reflector test packets to
traverse different IPv4 ECMP paths, as described in Section 2.1 of
[RFC8029]. In this case, the Session-Sender test packets may
carry the "Destination Node IPv4 or IPv6 Address" STAMP TLV, as
defined in [RFC9503], to identify the intended Session-Reflector
IP address.
The considerations for loss measurement for different ECMP paths of
an SR-MPLS path are outside the scope of this document.
11. STAMP Session State
The threshold-based notification for delay and packet loss metrics is
generated only when the metrics change significantly. For
unambiguous monitoring, the controller needs to distinguish whether
the STAMP session is active but delay and packet loss metrics did not
cross the thresholds, or whether the STAMP session has failed and is
not transmitting or receiving test packets.
The STAMP session state monitoring allows the node to determine
whether the performance measurement test is active, idle, or failed.
The failed state of the STAMP session also indicates the connectivity
failure of the SR-MPLS path or of the L3/L2 service over the SR-MPLS
path, where the STAMP session was active.
In all measurement modes, the STAMP session state is notified as idle
when the Session-Sender is not transmitting test packets.
In two-way measurement mode, loopback measurement mode, and loopback
measurement mode with TSF, STAMP session state is notified on
Session-Sender as follows:
Gandhi, et al. Expires 16 March 2027 [Page 28]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
* The STAMP session state is initially notified as active on the
Session-Sender when the Session-Sender is transmitting test
packets and at least one Session-Reflector test packet has been
received.
* The STAMP session state is notified as failed when N consecutive
Session-Reflector test packets are not received at the Session-
Sender after the STAMP session state is notified as active, where
N (the consecutive packet loss count) is a locally provisioned
value.
Similarly, in one-way measurement mode, STAMP session state is
notified on Session-Reflector as follows:
* The STAMP session state is initially notified as active on the
Session-Reflector once one or more Session-Sender test packets are
received.
* The STAMP session state is notified as failed when N consecutive
Session-Sender test packets are not received at the Session-
Reflector after the STAMP session state is notified as active,
where N (the consecutive packet loss count) is a locally
provisioned value.
12. Implementation Status
Editorial note: Please remove this section prior to publication.
12.1. Cisco Implementation
The following Cisco routing platforms running IOS XR 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 linecard and Tomahawk linecard
* Cisco NCS5500 (based on Broadcom Jericho1 ASIC)
* Cisco NCS5700 (based on Broadcom Jericho2 ASIC)
Gandhi, et al. Expires 16 March 2027 [Page 29]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
13. Operational and Manageability Considerations
The operational considerations specified in Section 5 of [RFC8762]
also apply to the procedure specified in this document. Further, the
operational and management considerations for performance measurement
based on STAMP specified in Section 3 of [RFC8762] also apply to the
procedures specified in this document. The manageability
considerations described in Section 9 of [RFC8402] apply to this
specification.
When a destination UDP port number other than the default port 862 is
used, the same network-impact study and agreement requirements
specified in Section 4.1 of [RFC8762] apply.
The operational considerations specified in [RFC9994] are also
applicable to the procedures described in this document.
Various statistics for one-way (near-end, far-end), round-trip, and
loopback delay metrics (such as average delay, minimum delay, maximum
delay, and delay variance) as well as for one-way (near-end, far-end)
or round-trip packet loss metrics (such as percentage loss and
consecutive packets lost) and the STAMP session state changes can be
computed using the performance measurement procedures described in
this document. Operator alerts are generated for anomaly detection
when delay or loss metrics cross user-configured thresholds or when
the STAMP session state changes.
When STAMP sessions are created for the Segment Lists of the SR-MPLS
Policies, the scalability regarding the number of STAMP sessions
needs to be carefully considered.
The operational considerations specified in [I-D.ietf-mpls-stamp-pw]
apply when selecting a routable or non-routable IP address as a
destination address.
13.1. Operational Considerations for TSF
The TSF network action processing depends on the TSF opcode and the
corresponding timestamp format capability. Operators should verify
Session-Reflector support for 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 with TSF Network Action invocations.
Gandhi, et al. Expires 16 March 2027 [Page 30]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
* Packets with TSF dropped because the action was unknown.
* Packets with TSF forwarded when the action was unknown.
* Packets with TSF dropped because of a malformed MNA Sub-Stack.
* Packets with 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.
14. Security Considerations
The security considerations specified in [RFC8762], [RFC8972], and
[RFC9503] also apply to the procedures described in this document.
The measures specified in Section 7 of [RFC8762] to mitigate attacks
also apply.
The source UDP port number should be selected using a randomized
allocation method as specified in [RFC6056] to provide protection
against off-path attacks, as recommended in [RFC8085].
Furthermore, SSIDs [RFC8972] should not be assigned predictably. To
avoid predictability, implementations can use a cryptographically
secure pseudorandom number generator [NIST-CSPRNG].
The use of HMAC-SHA-256 in authenticated mode protects the data
integrity of the STAMP test packets. The message integrity
protection using HMAC, as defined in Section 4.4 of [RFC8762], can be
used with the procedures described in this document.
The procedures defined in this document are intended for deployment
in a single network administrative domain. As such, the Session-
Sender address, Session-Reflector address, and the forward direction
and return paths are provisioned by the operator for the STAMP
session. It is assumed that the operator has verified the integrity
of the forward direction and return paths of the STAMP test packets.
The security considerations specified in [RFC9994] and
[I-D.ietf-mpls-stamp-pw] are also applicable to the procedures
described in this document.
Implementations can mitigate attacks by performing basic validation
checks on Session-Reflector test packets received at the Session-
Sender, such as verifying that timestamp T2 is later than timestamp
Gandhi, et al. Expires 16 March 2027 [Page 31]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
T1 (when the Session-Sender and Session-Reflector clocks are
synchronized) in the STAMP Reference Topology shown in Figure 2. 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.
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.
14.1. Security Considerations for TSF
The TSF network actions use the IANA-assigned opcodes for STAMP TSF
with PTPv2 and STAMP TSF with NTPv4. Their processing therefore
needs to be restricted to trusted nodes and trusted STAMP sessions.
An attacker that can inject packets with the TSF network action could
cause unauthorized data-plane timestamping or influence measured
paths. Network operators need to filter MPLS packets carrying the
TSF Network Action at administrative-domain boundaries and are
expected to restrict the action to Session-Reflector nodes that
support the applicable TSF opcode.
The Session-Reflector writes the timestamp specified by opcode TBA1
or TBA2 in the STAMP test packet payload. Implementations need to
validate the MNA Sub-Stack, opcode, timestamp format, begin offset,
and available payload length before writing the timestamp. Bounds
checking is required to prevent malformed packets from causing memory
corruption, packet corruption, or denial-of-service conditions. Any
malformed packet with the TSF network action needs to be dropped.
15. IANA Considerations
IANA is requested to assign code points from the Network Action
Opcodes registry created in [RFC9994] as specified in Table 3.
+========+=============+===============================+===========+
| Opcode | Description | In-Stack Only, Post-Stack | Reference |
| | | Only, In-Stack and Post-Stack | |
+========+=============+===============================+===========+
| TBA1 | STAMP TSF | In-Stack Only | This |
| | with PTPv2 | | document |
+--------+-------------+-------------------------------+-----------+
| TBA2 | STAMP TSF | In-Stack Only | This |
| | with NTPv4 | | document |
+--------+-------------+-------------------------------+-----------+
Table 3: Network Action Opcodes
Gandhi, et al. Expires 16 March 2027 [Page 32]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
16. References
16.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>.
[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>.
[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>.
[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>.
Gandhi, et al. Expires 16 March 2027 [Page 33]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
[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>.
16.2. Informative References
[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>.
[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>.
Gandhi, et al. Expires 16 March 2027 [Page 34]
Internet-Draft STAMP for Segment Routing over MPLS September 2026
[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>.
[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>.
[RFC9545] Cheng, W., Ed., Li, H., Li, C., Ed., Gandhi, R., and R.
Zigler, "Path Segment Identifier in MPLS-Based Segment
Routing Networks", RFC 9545, DOI 10.17487/RFC9545,
February 2024, <https://www.rfc-editor.org/info/rfc9545>.
[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>.
Gandhi, et al. Expires 16 March 2027 [Page 35]
Internet-Draft STAMP for Segment Routing over MPLS September 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
described in this document. The authors would also like to thank
Haoyu Song for the Shepherd's review and Alvaro Retana for the WG
chair's review, which helped improve this document.
Contributors
The following people have substantially contributed to this document:
Daniel Voyer
Cisco Systems, Inc.
Email: davoyer@cisco.com
Gandhi, et al. Expires 16 March 2027 [Page 36]
Internet-Draft STAMP for Segment Routing over MPLS September 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
Individual
Email: mach.chen@outlook.com
Richard Foote
Nokia
Email: footer.foote@nokia.com
Gandhi, et al. Expires 16 March 2027 [Page 37]