Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet MPLS Extension Headers
draft-gandhi-ippm-stamp-mpls-hdr-07
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Rakesh Gandhi , Tianran Zhou , Zhenqiang Li , Fabian Ihle | ||
| Last updated | 2026-07-05 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gandhi-ippm-stamp-mpls-hdr-07
IPPM Working Group R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track T. Zhou
Expires: 6 January 2027 Huawei
Z. Li
China Mobile
F. Ihle
University of Tuebingen
5 July 2026
Simple Two-Way Active Measurement Protocol (STAMP) Extensions for
Reflecting STAMP Packet MPLS Extension Headers
draft-gandhi-ippm-stamp-mpls-hdr-07
Abstract
The Simple Two-Way Active Measurement Protocol (STAMP) and its
optional extensions can be used for Edge-to-Edge (E2E) active
measurements. In Situ Operations, Administration, and Maintenance
(IOAM) data fields can be used for recording and collecting Hop-by-
Hop (HBH) and E2E operational and telemetry information. This
document extends STAMP to reflect MPLS extension headers, including
MPLS Network Action Sub-Stacks and Post-Stack MPLS Headers, for HBH
and E2E active measurements, for example, using the IOAM data fields.
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 6 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gandhi, et al. Expires 6 January 2027 [Page 1]
Internet-Draft STAMP Reflecting MPLS Extension Headers July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2.3. STAMP Reference Topology . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Procedure for Reflecting MPLS Extension Headers . . . . . 5
3.2. One-Way and Two-Way Measurement Types . . . . . . . . . . 8
3.3. Receiving MPLS Header from the Data Plane on Egress
Node . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Use Case of Reflecting IOAM Data Fields . . . . . . . . . . . 10
5. STAMP Extensions . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Reflected MPLS Header MNA Data TLV . . . . . . . . . . . 11
5.2. MNA Header Control Sub-TLV . . . . . . . . . . . . . . . 12
6. Operational Considerations . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The Simple Two-Way Active Measurement Protocol (STAMP) provides
capabilities for the measurement of various performance metrics in IP
networks [RFC8762] without the use of a control channel to pre-signal
session parameters. [RFC8972] defines optional extensions in the
form of TLVs for STAMP. STAMP test packets are transmitted along a
path between a Session-Sender and a Session-Reflector to measure
Edge-to-Edge performance metrics, like delay, delay variation, and
packet loss along that path.
Gandhi, et al. Expires 6 January 2027 [Page 2]
Internet-Draft STAMP Reflecting MPLS Extension Headers July 2026
In Situ Operations, Administration, and Maintenance (IOAM) is used
for recording and collecting operational and telemetry information
while the packet traverses a path between two points in the network.
The IOAM data fields are defined in [RFC9197]. The information from
the collected IOAM data fields can be used to support Hop-by-Hop
(HBH) and Edge-to-Edge (E2E) measurement use cases.
MPLS packets may carry MPLS Network Action (MNA) Sub-Stacks as
defined in [RFC9994] and Post-Stack MPLS Header (PSMH) for the MNA
type as defined in [I-D.ietf-mpls-mna-ps-hdr].
[I-D.ietf-mpls-mna-ioam] specifies Network Action Sub-Stacks (NASes)
and PSMHs to carry the IOAM Option-Types defined in [RFC9197] and
[RFC9326] for an MPLS data plane.
It may be desirable to record and collect HBH and E2E operational and
telemetry information using active measurement packets between two
nodes in a network. This is achieved by augmenting STAMP [RFC8762],
using optional STAMP extensions defined in [RFC8972], to reflect MPLS
extension headers, including NASes and PSMHs, as specified in this
document. The procedure defined in this document leverages existing
implementations at the midpoint nodes with an MPLS data plane that
support NASes and PSMHs, without any additional requirements.
A PSMH can be defined for types other than the MNA. This document
only concerns with the PSMH for the MNA type
[I-D.ietf-mpls-mna-ps-hdr].
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
DEX: Direct Export
ECMP: Equal Cost Multi-Path
E2E: Edge-to-Edge
HBH: Hop-by-Hop
Gandhi, et al. Expires 6 January 2027 [Page 3]
Internet-Draft STAMP Reflecting MPLS Extension Headers July 2026
IOAM: In Situ Operations, Administration, and Maintenance
MNA: Multiprotocol Label Switching Network Action
MTU: Maximum Transmission Unit
NAS: Network Action Sub-Stack
PSMH: Post-Stack MPLS Header
STAMP: Simple Two-Way Active Measurement Protocol
TLV: Type-Length-Value
2.3. STAMP Reference Topology
In the "STAMP Reference Topology" shown in Figure 1, the STAMP
Session-Sender S1 initiates a Session-Sender test packet, and the
STAMP Session-Reflector R1 transmits a reply Session-Reflector test
packet. Node M1 is a midpoint node that performs an MPLS network
action but does not perform any STAMP protocol processing.
T1 is a transmit timestamp, and T4 is a receive timestamp added by
node S1 in a STAMP test packet payload. T2 is a receive timestamp,
and T3 is a transmit timestamp added by node R1 in a STAMP test
packet payload.
T1 T2
/ \
+-------+ Test Packet +-------+ +-------+
| | - - - - - - - - | | - - - - - - - - ->| |
| S1 |=================| M1 |===================| R1 |
| |<- - - - - - - - | | - - - - - - - - - | |
+-------+ +-------+ Reply Test Packet +-------+
\ /
T4 T3
STAMP Session-Sender STAMP Session-Reflector
Figure 1: STAMP Reference Topology
Gandhi, et al. Expires 6 January 2027 [Page 4]
Internet-Draft STAMP Reflecting MPLS Extension Headers July 2026
3. Overview
[RFC8972] defines optional extensions for STAMP. The optional
extensions are added to the base STAMP test packet defined in
[RFC8762] in the form of TLVs. As specified in [RFC8972], both
Session-Sender and Session-Reflector test packets are symmetric in
size when including all optional TLVs (but excluding headers). The
Session-Reflector reflects all received STAMP TLVs from the Session-
Sender test packet.
As specified in [RFC8762], STAMP test packets are transmitted with
IP/UDP headers. Since the midpoint nodes do not process the UDP
headers in the packets, they are agnostic to the STAMP test packets
in the payload.
STAMP test packets may carry an MPLS header with MPLS extension
headers, including NASes and PSMHs. This document defines procedures
and STAMP extensions for a Session-Reflector to reflect the received
MPLS extension headers back to the Session-Sender for both one-way
and two-way measurement types.
3.1. Procedure for Reflecting MPLS Extension Headers
This document also defines a new TLV option for STAMP, called
"Reflected MPLS Header MNA Data" (value TBA1). When a STAMP Session-
Sender adds a NAS in the test packet, the Session-Sender MUST add a
corresponding "Reflected MPLS Header MNA Data" TLV in the Session-
Sender test packet with the length set to the MNA Sub-Stack length
(NASL) to receive a copy of that NAS back in the STAMP TLV.
Similarly, when a STAMP Session-Sender adds a PSMH in the test
packet, the Session-Sender MUST add a corresponding "Reflected MPLS
Header MNA Data" TLV, with the matching length, in order to receive a
copy of that PSMH.
An example STAMP test packet for carrying NASes and a PSMH and
reflected data in the "Reflected MPLS Header MNA Data" TLVs is shown
in Figure 2.
Gandhi, et al. Expires 6 January 2027 [Page 5]
Internet-Draft STAMP Reflecting MPLS Extension Headers July 2026
+---------------------------------------------------------------+
| MPLS Header |
~ ~
+---------------------------------------------------------------+
| MNA Sub-Stack-1 RFC 9994 |
~ ~
+---------------------------------------------------------------+
~ ... ~
+---------------------------------------------------------------+
| MNA Sub-Stack-N RFC 9994 |
~ ~
+---------------------------------------------------------------+
~ ... ~
+---------------------------------------------------------------+
| Post-Stack MPLS Header-1 I-D.ietf-mpls-mna-ps-hdr |
~ ~
+---------------------------------------------------------------+
| IP Header |
+---------------------------------------------------------------+
| UDP Header |
+---------------------------------------------------------------+
| STAMP Packet RFC 8972 |
~ ~
+---------------------------------------------------------------+
| Reflected MPLS Header MNA Data-1 STAMP TLV (TBA1) |
~ ~
+---------------------------------------------------------------+
~ ... ~
+---------------------------------------------------------------+
| Reflected MPLS Header MNA Data-M STAMP TLV (TBA1) |
~ ~
+---------------------------------------------------------------+
| Reflected MPLS Header MNA Data-1 STAMP TLV PSMH (TBA1) |
~ ~
+---------------------------------------------------------------+
Note: Value of M <= N
Figure 2: Example Session-Sender and Session-Reflector Test
Packet with "Reflected MPLS Header MNA Data" TLVs
When adding multiple NASes in the Session-Sender test packet, the
corresponding "Reflected MPLS Header MNA Data" TLVs MUST also be
added, with lengths matching those of the NAS and Ancillary Data and
in the same order, to receive a copy of those NASes. When the
Session-Sender test packets carry a NAS or a PSMH that the Session-
Sender does not require the Session-Reflector to reflect in Session-
Reflector test packets, the Session-Sender MUST NOT add a
Gandhi, et al. Expires 6 January 2027 [Page 6]
Internet-Draft STAMP Reflecting MPLS Extension Headers July 2026
corresponding "Reflected MPLS Header MNA Data" TLV in the Session-
Sender test packets. In this case, the number of "Reflected MPLS
Header MNA Data" TLVs (value of M in Figure 2) in the Session-Sender
test packet would be less than the number of NASes (value of N in
Figure 2).
The number of "Reflected MPLS Header MNA Data" TLVs MUST be less than
or equal to the number of NASes plus the number of PSMHs in a
Session-Sender test packet.
When the Session-Reflector receives a STAMP test packet with a NAS
and a "Reflected MPLS Header MNA Data" TLV, the following rules
apply:
1. The Session-Reflector that supports this STAMP TLV MUST copy the
entire NAS, including the Ancillary Data and header, into the
"Reflected MPLS Header MNA Data" TLV in the Session-Reflector test
packet payload.
2. When there are multiple NASes in the received Session-Sender test
packet, each NAS (including Ancillary Data) MUST be processed in the
order from the top of the label stack and copied into the
corresponding "Reflected MPLS Header MNA Data" TLV, if that STAMP TLV
exists.
3. The Session-Reflector MUST process the PSMH and copy the entire
PSMH and the Ancillary Data into the corresponding "Reflected MPLS
Header MNA Data" TLV, if that STAMP TLV exists.
4. When the Session-Reflector receives a STAMP test packet with a
NAS or a PSMH but without a corresponding "Reflected MPLS Header MNA
Data" TLV, the Session-Reflector does not copy that NAS or PSMH into
the Session-Reflector test packet.
The value field in the "Reflected MPLS Header MNA Data" TLV in
Session-Sender test packets can be initialized to zeros. The
Session-Sender MUST copy the "Requested MPLS Header MNA Data" field
(shown in Figure 4) using the first 8 octets (excluding the mutable
13-bit Ancillary Data field in the NAS and the 16-bit Post-Stack Data
field in the PSMH) of the NAS and PSMH in the MPLS header if there is
an ambiguity when there are multiple NASes and PSMHs with the same
length present and not all need to be copied and reflected in the
STAMP TLVs. This method assumes that the first 8 octets (excluding
the mutable 13-bit Ancillary Data field in the NAS and the 16-bit
Post-Stack Data field in the PSMH) of the NASes and PSMHs do not
change before being received at the Session-Reflector. If the
Session-Reflector receives Session-Sender test packets with non-zero
values in the "Requested MPLS Header MNA Data" field of the
Gandhi, et al. Expires 6 January 2027 [Page 7]
Internet-Draft STAMP Reflecting MPLS Extension Headers July 2026
"Reflected MPLS Header MNA Data" TLV, the Session-Reflector MUST
match the first 8 octets (excluding the mutable 13-bit Ancillary Data
field in the NAS and the 16-bit Post-Stack Data field in the PSMH) in
the corresponding NAS and PSMH in the MPLS header before copying data
into the STAMP TLV.
As the procedure defined in this document leverages the existing
implementations at the midpoint nodes for the NASes and PSMHs, no
additional requirements are specified when carrying these NASes and
PSMHs in STAMP test packets. The NASes and PSMHs are processed by
the nodes using the same procedures specified in the document that
defined them.
The Session-Sender and Session-Reflector MUST ensure that the
resulting STAMP test packets do not exceed the MPLS MTU after adding
"Reflected MPLS Header MNA Data" TLVs. If necessary, one or more
"Reflected MPLS Header MNA Data" TLVs MUST be removed to avoid
violating the MPLS MTU limit.
Note that the use case where the NAS and PSMH lengths change in the
STAMP test packets along the path is outside the scope of this
document. Also, the use case where the NASes and the PSMHs are added
or removed in the MPLS header of the Session-Sender test packets
along the path is outside the scope of this document.
3.2. One-Way and Two-Way Measurement Types
This document defines two measurement types: one-way and two-way
measurements. These types relate only to whether the Session-
Reflector adds new matching NASes and PSMHs for the reverse path.
In the two-way measurement type, the Session-Reflector adds new
matching NASes and PSMHs, including Ancillary Data, in the MPLS
header of the Session-Reflector test packets in the same order as
received in the Session-Sender test packets for the reverse direction
measurement. The length and content of the new NASes and PSMHs added
in Session-Reflector test packets is a local decision at the Session-
Reflector. The STAMP Session-Sender enables this type by adding the
"MNA Header Control" Sub-TLV for the "Reflected Test Packet Control"
TLV in the Session-Sender test packets.
Gandhi, et al. Expires 6 January 2027 [Page 8]
Internet-Draft STAMP Reflecting MPLS Extension Headers July 2026
In the one-way measurement type, the Session-Reflector does not add
the new matching NASes and PSMHs in the MPLS header of the Session-
Reflector test packets corresponding to the received NASes and PSMHs
in the Session-Sender test packets. However, the Session-Reflector
still copies received NASes and PSMHs into the "Reflected MPLS Header
MNA Data" TLVs as specified in Section 3.1. This type is the default
if the "MNA Header Control" Sub-TLV is absent in the Session-Sender
test packet.
The measurement type for a STAMP session is locally provisioned on
the STAMP Session-Sender.
3.3. Receiving MPLS Header from the Data Plane on Egress Node
As specified in Section 9.3, "Penultimate Node Responsibilities" of
[RFC9994], and Section 6.3, "Penultimate Node Responsibilities" of
[I-D.ietf-mpls-mna-ps-hdr], for HBH and Ingress-to-Egress (I2E)
scopes, the last copy of the NASes and the PSMHs MUST NOT be removed
by the penultimate node, and hence they will be received by the
egress node.
Note that the NAS and the corresponding PSMH for the "Select" scope
are removed from the packets on the transit node where the NAS is
processed, and hence they will not be received by the egress node.
The STAMP test packets, carrying the MPLS header with the NASes and
the PSMHs for HBH and I2E scopes for HBH and E2E measurements,
respectively, will be received by the egress node hosting the
Session-Reflector. When the received STAMP test packets are
processed by the data plane on the egress node that has the Session-
Reflector, the data plane MUST provide the received MPLS header
containing the NASes and the PSMHs from the Session-Sender test
packets to the Session-Reflector on the node.
Similarly, when the received STAMP test packets are processed by the
data plane on the egress node in the reverse direction that has the
Session-Sender, the data plane MUST provide the received MPLS header
containing the NASes and the PSMHs from the Session-Reflector test
packets to the Session-Sender on the node for the two-way measurement
type.
Gandhi, et al. Expires 6 January 2027 [Page 9]
Internet-Draft STAMP Reflecting MPLS Extension Headers July 2026
4. Use Case of Reflecting IOAM Data Fields
In Situ Operations, Administration, and Maintenance (IOAM) is used
for recording and collecting operational and telemetry information
while the packet traverses a path between two points in the network.
The IOAM data fields are defined in [RFC9197]. Examples of data
recorded by IOAM Trace Options include per-hop information, such as
node ID, timestamp, queue depth, interface ID, and interface load.
The information collected can be used for monitoring ECMP paths,
proof-of-transit, and troubleshooting failures in the network. IOAM
can be used with STAMP test packets for active measurements. The
procedure and STAMP extensions defined in this document can be used
to reflect the collected IOAM data fields back to the Session-Sender,
where the Session-Sender can use this information to support the HBH
and E2E measurement use cases.
[I-D.ietf-mpls-mna-ioam] defines MNA extensions for NASes and PSMHs
to carry the IOAM option types defined in [RFC9197] for an MPLS data
plane. The STAMP Session-Sender and Session-Reflector test packets
carry the IOAM option types for recording and collecting HBH and E2E
operational and telemetry information for active measurements, as
shown in Figure 3. The Session-Sender node, midpoint nodes, and the
Session-Reflector node process the IOAM data fields, as defined in
[RFC9197]. Note that using the IOAM option type "Incremental Trace
Option-Type" is not supported by [I-D.ietf-mpls-mna-ioam].
+---------------------------------------------------------------+
| MPLS Header |
+---------------------------------------------------------------+
| IOAM MNA Sub-Stack I-D.ietf-mpls-mna-ioam |
~ ~
+---------------------------------------------------------------+
| IOAM MNA PSMH I-D.ietf-mpls-mna-ioam |
~ ~
+---------------------------------------------------------------+
| IP Header |
+---------------------------------------------------------------+
| UDP Header |
+---------------------------------------------------------------+
| STAMP Packet RFC 8972 |
+---------------------------------------------------------------+
| Reflected MPLS Header MNA Data STAMP TLV (TBA1) |
~ ~
+---------------------------------------------------------------+
| Reflected MPLS Header MNA Data STAMP TLV PSMH (TBA1) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gandhi, et al. Expires 6 January 2027 [Page 10]
Internet-Draft STAMP Reflecting MPLS Extension Headers July 2026
Figure 3: Example STAMP Session-Sender and Session-Reflector Test
Packet for IOAM with "Reflected MPLS Header MNA Data" TLV
IOAM Direct Exporting (DEX) [RFC9326] is applicable with STAMP test
packets for on-path telemetry use case. In this case, the Session-
Reflector is not required to reflect the IOAM option type, since no
IOAM data would be recorded in the STAMP test packets. Hence, the
Session-Sender MAY not include a corresponding "Reflected MPLS Header
MNA Data" TLV in Session-Sender test packets for the IOAM DEX option
type.
5. STAMP Extensions
5.1. Reflected MPLS Header MNA Data TLV
The "Reflected MPLS Header MNA Data" TLV is carried by Session-Sender
and Session-Reflector test packets. STAMP test packets MAY carry one
or more STAMP TLVs of this type. The same "Reflected MPLS Header MNA
Data" TLV Type is used for reflecting different MPLS extension
headers, including NASes and PSMHs. The format of the "Reflected
MPLS Header MNA Data" TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=TBA1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested MPLS Header MNA Data (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reflected MPLS Header MNA Data |
~ (Length - 8 octets) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Reflected MPLS Header MNA Data TLV
The STAMP TLV fields are defined as follows:
Type: STAMP TLV Type (value TBA1).
STAMP TLV Flags: The STAMP TLV Flags follow the procedures described
in [RFC8972].
Length: A two-octet field equal to the total length of the Requested
and Reflected MPLS Header MNA Data fields combined, in octets.
Gandhi, et al. Expires 6 January 2027 [Page 11]
Internet-Draft STAMP Reflecting MPLS Extension Headers July 2026
Requested MPLS Header MNA Data: A fixed 8-octet field containing the
first 8 octets of the target NAS or PSMH to be reflected. This field
is used to disambiguate which NAS or PSMH in the received MPLS header
MUST be copied into the Reflected field when multiple NASes and PSMHs
of the same length are present. The 13-bit Ancillary Data field in
the NAS and 16-bit Post-Stack Data field in the PSMH MUST be set to
zero in this field for matching purposes. When this field is set to
all zeros, the Session-Reflector MUST match the first NAS or PSMH in
the MPLS header with the matching length.
Reflected MPLS Header MNA Data: A variable-length field of (Length -
8) octets containing the reflected NAS or PSMH copied from the
received MPLS header by the Session-Reflector. In Session-Sender
test packets, this field MUST be initialized to zero.
When the Session-Reflector recognizes the received "Reflected MPLS
Header MNA Data" TLV but could not use it for reflecting any NAS or
PSMH received, the Session-Reflector MUST return the "Reflected MPLS
Header MNA Data" TLV with the C flag (Conformance) set to 1 in the
STAMP TLV Flags using the procedure defined in
[I-D.ietf-ippm-asymmetrical-pkts]. This can occur, for example if:
(a) there is a mismatch between the expected length in "Reflected
MPLS Header MNA Data" TLVs and the received NASes and PSMHs, (b) the
Session-Reflector cannot access the received NASes and PSMHs from the
data plane, (c) no NAS or PSMH matches the "Requested MPLS Header MNA
Data" field, etc.
5.2. MNA Header Control Sub-TLV
This document defines the "MNA Header Control" Sub-TLV (Type TBA2)
for the "Reflected Test Packet Control" TLV (Type 12) introduced in
[I-D.ietf-ippm-asymmetrical-pkts]. The format of "MNA Header
Control" Sub-TLV is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Flags | Type = TBA2 | Sub-TLV Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: MNA Header Control Sub-TLV
The Sub-TLV fields are defined as follows:
Type: Sub-TLV Type (value TBA2).
Sub-TLV Flags: The Sub-TLV Flags follow the procedure for STAMP TLV
Flags described in [RFC8972].
Gandhi, et al. Expires 6 January 2027 [Page 12]
Internet-Draft STAMP Reflecting MPLS Extension Headers July 2026
Sub-TLV Length: A two-octet field equal to the length of the Data in
octets. It is set to 0.
When the Session-Reflector receives a STAMP test packet with the "MNA
Header Control" Sub-TLV, the following rules apply:
1. The Session-Reflector MUST add new matching NASes and PSMHs in
the MPLS header of the Session-Reflector test packet in the same
order corresponding to the received NASes and PSMHs in the Session-
Sender test packet.
2. In the absence of the "MNA Header Control" Sub-TLV in the
received Session-Sender test packet, the Session-Reflector MAY not
add new matching NASes or PSMHs corresponding to the received NASes
and PSMHs in the Session-Reflector test packet. This behaviour can
be based on a local policy on the Session-Reflector.
3. The NASes and PSMHs received in the Session-Sender test packets
MUST be copied and reflected in the corresponding "Reflected MPLS
Header MNA Data" TLVs to the Session-Sender regardless of whether the
"MNA Header Control" Sub-TLV is present or not.
4. If the Session-Reflector cannot add a new matching NAS or PSMH in
the Session-Reflector test packet, the Session-Reflector MUST return
the "Reflected Test Packet Control" TLV with the C flag (Conformance)
set to 1 in the Sub-TLV Flags of the "MNA Header Control" Sub-TLV
using the procedure defined in [I-D.ietf-ippm-asymmetrical-pkts].
This can occur, for example, when the Session-Reflector does not
support the NAS or PSMH, or when the Session-Reflector cannot access
the received NASes and PSMHs from data plane.
STAMP test packets MUST NOT carry more than one "MNA Header Control"
Sub-TLV in a "Reflected Test Packet Control" TLV. If the "Reflected
Test Packet Control" TLV in the Session-Sender test packet contains
more than one "MNA Header Control" Sub-TLV, the Session-Reflector
MUST return the "Reflected Test Packet Control" TLV with the C flag
(Conformance) set to 1 in the Sub-TLV Flags of all "MNA Header
Control" Sub-TLVs, using the procedure defined in
[I-D.ietf-ippm-asymmetrical-pkts].
6. Operational Considerations
The operational considerations specified in [RFC8762] and [RFC9994]
apply to the procedure and extensions defined in this document.
In addition, the Management and Deployment Considerations specified
in [RFC9197] also apply when using the IOAM data fields defined in
that document.
Gandhi, et al. Expires 6 January 2027 [Page 13]
Internet-Draft STAMP Reflecting MPLS Extension Headers July 2026
An operator MAY provision a local policy on a Session-Reflector to
not copy and reflect the received MPLS extension headers in the
Session-Reflector test packets to avoid exposing the collected
network information to the Session-Sender.
7. Security Considerations
The security considerations specified in [RFC8762], [RFC8972],
[RFC9994], and [I-D.ietf-mpls-mna-ps-hdr] apply to the procedure and
extensions defined in this document. In addition, the security
considerations specified in [RFC9197] and [I-D.ietf-mpls-mna-ioam]
also apply when using IOAM data fields.
The procedures defined in this document are intended for deployment
in a single network administrative domain. It is assumed that the
operator has verified the integrity of the forward and return paths
used to transmit STAMP test packets so that collected network
information is not exposed on an undesired node.
If desired, attacks can be mitigated by performing basic validation
checks of the timestamp fields (such as verifying that timestamp T2
is later than timestamp T1 in the STAMP Reference Topology shown in
Figure 1, when Session-Sender and Session-Reflector clocks are
synchronized) in received reply test packets at the Session-Sender.
The minimal state associated with these protocols also limits the
extent of measurement disruption that can be caused by a corrupt or
invalid test packet to a single test cycle.
Furthermore, implementations SHOULD NOT assign STAMP Session-IDs
[RFC8972] in a predictable manner. In order to avoid predictability,
implementations can leverage a Cryptographically Secure Pseudorandom
Number Generator [NIST-CSPRNG].
8. Implementation Status
Editorial note: Please remove this section prior to publication.
An open-source implementation of STAMP with optional TLVs [RFC8972],
MPLS Network Action (with In-Stack and Post-Stack Data), and the IOAM
pre-allocated trace option [RFC9197] for one-way and two-way
measurement types for Hop-by-Hop delay measurement (for 4 transit
nodes) using the extensions defined in this document is available in
the Tofino2.
- https://github.com/uni-tue-kn/stamp-mpls-mna-poc
Contact:
Gandhi, et al. Expires 6 January 2027 [Page 14]
Internet-Draft STAMP Reflecting MPLS Extension Headers July 2026
Fabian Ihle
University of Tuebingen
Germany
Email: fabian.ihle@uni-tuebingen.de
9. IANA Considerations
IANA has created the "STAMP TLV Types" registry for [RFC8972]. IANA
is requested to allocate a value for the "Reflected MPLS Header MNA
Data" TLV Type from the IETF Review TLV range of the same registry.
+=======+================================+===============+
| Value | Description | Reference |
+=======+================================+===============+
| TBA1 | Reflected MPLS Header MNA Data | This document |
+-------+--------------------------------+---------------+
Table 1: STAMP TLV Type
IANA is requested to allocate a value for the Sub-TLV Type "MNA
Header Control" (Type TBA2) for the STAMP TLV Type "Reflected Test
Packet Control" (Type 12) defined in
[I-D.ietf-ippm-asymmetrical-pkts], from the "STAMP Sub-TLV Types"
registry.
+=======+====================+================+===========+
| Value | Description | TLV Used | Reference |
+=======+====================+================+===========+
| TBA2 | MNA Header Control | Reflected Test | This |
| | | Packet Control | document |
+-------+--------------------+----------------+-----------+
Table 2: Sub-TLV Type for Reflected Test Packet Control TLV
10. References
10.1. Normative References
[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>.
Gandhi, et al. Expires 6 January 2027 [Page 15]
Internet-Draft STAMP Reflecting MPLS Extension Headers July 2026
[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>.
[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-mna-ps-hdr]
Rajamanickam, J., Gandhi, R., Zigler, R., Dong, J., and J.
Bhattacharya, "Post-Stack MPLS Network Action (MNA) Header
Specification", Work in Progress, Internet-Draft, draft-
ietf-mpls-mna-ps-hdr-09, 23 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-ps-hdr-09>.
[I-D.ietf-mpls-mna-ioam]
Gandhi, R., Mirsky, G., Song, H., Wen, B., and V. Kozak,
"Supporting In Situ Operations, Administration, and
Maintenance Using MPLS Network Actions", Work in Progress,
Internet-Draft, draft-ietf-mpls-mna-ioam-06, 5 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
mna-ioam-06>.
[I-D.ietf-ippm-asymmetrical-pkts]
Mirsky, G., Ruffini, E., Nydell, H., Foote, R. F., and W.
Hawkins, "Performance Measurement with Asymmetrical
Traffic Using Simple Two-Way Active Measurement Protocol
(STAMP)", Work in Progress, Internet-Draft, draft-ietf-
ippm-asymmetrical-pkts-14, 16 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
asymmetrical-pkts-14>.
10.2. Informative References
Gandhi, et al. Expires 6 January 2027 [Page 16]
Internet-Draft STAMP Reflecting MPLS Extension Headers July 2026
[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
Ed., "Data Fields for In Situ Operations, Administration,
and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
May 2022, <https://www.rfc-editor.org/info/rfc9197>.
[RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
Mizrahi, "In Situ Operations, Administration, and
Maintenance (IOAM) Direct Exporting", RFC 9326,
DOI 10.17487/RFC9326, November 2022,
<https://www.rfc-editor.org/info/rfc9326>.
[NIST-CSPRNG]
NIST Special Publication 800-90A, "Recommendation for
Random Number Generation Using Deterministic Random Bit
Generators", January 2012.
Acknowledgments
The authors of this document would like to thank Greg Mirsky for
reviewing this document and providing review comments. The authors
would also like to thank Fabian Ihle for implementing the solution
defined in this document in Tofino2.
Authors' Addresses
Rakesh Gandhi (editor)
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
Tianran Zhou
Huawei
China
Email: zhoutianran@huawei.com
Zhenqiang Li
China Mobile
China
Email: lizhenqiang@chinamobile.com
Fabian Ihle
University of Tuebingen
Tuebingen
Germany
Email: fabian.ihle@uni-tuebingen.de
Gandhi, et al. Expires 6 January 2027 [Page 17]