| Internet-Draft | STAMP Reflecting MPLS Extension Headers | June 2026 |
| Gandhi, et al. | Expires 5 December 2026 | [Page] |
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-to-Edge (E2E) active measurement. 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 Header, for HBH and E2E active measurements, for example, using IOAM data fields.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 December 2026.¶
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.¶
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. The STAMP test packets are transmitted along a path between a Session-Sender and a Session-Reflector to measure Edge-to-Edge (E2E) performance delay and packet loss along that path.¶
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]. Currently, there is no adopted method defined to reflect the collected IOAM data fields back to the Sender, where the Sender can use that information to support the hop-by-hop and edge-to-edge measurement use cases.¶
MPLS packets may carry MPLS Network Action (MNA) Sub-Stacks as defined in [I-D.ietf-mpls-mna-hdr] and Post-Stack Header (PSH) as defined in [I-D.ietf-mpls-mna-ps-hdr].¶
It may be desired 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 Network Action Sub-Stacks (NASes) and PSH, as specified in this document. The procedure defined in this document leverages the existing implementations on the midpoint nodes with an MPLS data plane that support the NAS and PSH used, without any additional requirements.¶
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.¶
ECMP: Equal Cost Multi-Path¶
E2E: Edge-to-Edge¶
HBH: Hop-by-Hop¶
IOAM: In Situ Operations, Administration, and Maintenance¶
MNA: Multiprotocol Label Switching Network Action¶
MTU: Maximum Transmission Unit¶
NAS: Network Action Sub-Stack¶
PSH: Post-Stack Header¶
STAMP: Simple Two-Way Active Measurement Protocol¶
TLV: Type-Length-Value¶
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
[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 (and 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 midpoint nodes do not process the UDP headers in the packets, they are agnostic to the STAMP test packets in the payload.¶
This document also defines a new TLV option for STAMP, called "Reflected MPLS Header MNA Data" (value TBA1). When a STAMP Session-Sender adds an NAS in the test packet, it also adds a "Reflected MPLS Header MNA Data" STAMP TLV in the Session-Sender test packet with the length set to the MNA Sub-Stack length (NASL) and the value field in the TLV initialized to zeros, in order to receive a copy of that NAS back in the STAMP TLV. When adding multiple NASes in the Session-Sender test packet, corresponding "Reflected MPLS Header MNA Data" STAMP TLVs MUST be added, matching the length of the NAS and Ancillary Data and in the same order, in order to receive a copy of that NAS.¶
Similarly, when a STAMP Session-Sender adds MNA PSH in the test packet, it also adds corresponding "Reflected MPLS Header MNA Data" STAMP TLV, with the matching length, in order to receive a copy of that MNA PSH.¶
An example STAMP test packet for the MPLS data plane, carrying NASes and PSH and reflected MNA header data in STAMP TLVs, is shown in Figure 2.¶
+---------------------------------------------------------------+ | MPLS Header | ~ ~ +---------------------------------------------------------------+ | MNA Sub-Stack-1 I-D.ietf-mpls-mna-hdr | ~ ~ +---------------------------------------------------------------+ ~ ... ~ +---------------------------------------------------------------+ | MNA Sub-Stack-N I-D.ietf-mpls-mna-hdr | ~ ~ +---------------------------------------------------------------+ ~ ... ~ +---------------------------------------------------------------+ | MNA Post-Stack Header 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 STAMP TLV PSH (TBA1) | ~ ~ +---------------------------------------------------------------+
When the Session-Reflector receives a STAMP test packet with an NAS and a STAMP TLV "Reflected MPLS Header MNA Data," 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. When there are multiple NASes in the 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 STAMP TLV, if that STAMP TLV exists. Similarly, the Session-Reflector MUST process the PSH and copy the entire PSH and the Ancillary Data into the corresponding STAMP TLV, if that STAMP TLV exists.¶
When the Session-Reflector receives a STAMP test packet with an NAS or PSH but without a corresponding "Reflected MPLS Header MNA Data" STAMP TLV, the Session-Reflector does not copy that NAS or PSH into the Session-Reflector test packet.¶
When the Session-Sender test packets carry an NAS or PSH in the MPLS header that it does not require the Session-Reflector to reflect in the Session-Reflector test packets, it does not add the corresponding "Reflected MPLS Header MNA Data" STAMP TLV in the Session-Sender test packets.¶
If the Session-Reflector receives Session-Sender test packets with non-zero values in the first 8 bytes (excluding the Ancillary Data field that may change) in the value field of the "Reflected MPLS Header MNA Data" STAMP TLV, it MUST match the values in the corresponding NASes and the PSH in the MPLS header before copying the data into the STAMP TLV. This mechanism is employed in case of ambiguity when there are multiple NASes and PSH in the MPLS header of the same length present and not all need to be copied and reflected in the STAMP TLVs.¶
As the procedure defined in this document leverages the existing implementations on the midpoint nodes for the NASes and PSH, no additional requirements are specified when carrying NASes and PSH in STAMP. The NASes and PSH 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 the "Reflected MPLS Header MNA Data" STAMP TLVs. If necessary, "Reflected MPLS Header MNA Data" STAMP TLVs can be removed to avoid violating the MPLS MTU limit.¶
Note that the use case where the NAS and PSH 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 PSH are added or removed in the MPLS header of the Session-Sender test packets along the path is outside the scope of this document.¶
This document defines two measurement types: one-way and two-way measurements.¶
In the two-way measurement type, the Session-Reflector adds the matching NASes and the PSH, including Ancillary Data, in the MPLS header of the Session-Reflector test packets in the same order for the reverse direction measurements as received in the Session-Sender test packets. Whereas in the one-way measurement type, the Session-Reflector does not add the matching NASes and the PSH, including Ancillary Data, in the MPLS header of the Session-Reflector test packets.¶
As specified in Section 9.3, "Penultimate Node Responsibilities" of [I-D.ietf-mpls-mna-hdr], 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 PSH 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 PSH 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 PSH 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 PSH 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 PSH from the Session-Reflector test packets to the Session-Sender on the node for the two-way measurement type.¶
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, interface load, etc. 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 measurement. The procedure and STAMP extensions defined in this document can be used to reflect the collected IOAM data fields back to the Sender, where the Sender can use that information to support the hop-by-hop and edge-to-edge measurement use cases.¶
[I-D.ietf-mpls-mna-ioam] defines extensions using MNA to carry IOAM data that may be carried in NAS [I-D.ietf-mpls-mna-hdr] or in PSH [I-D.ietf-mpls-mna-ps-hdr]. The STAMP Session-Sender and Session-Reflector test packets can carry an NAS and PSH for HBH and E2E operational and telemetry information for active measurement, as shown in Figure 3, as an example.¶
+---------------------------------------------------------------+ | MPLS Header | +---------------------------------------------------------------+ | IOAM MNA Sub-Stack I-D.ietf-mpls-mna-ioam | ~ ~ +---------------------------------------------------------------+ | IOAM MNA PSH 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 PSH (TBA1) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "Reflected MPLS Header MNA Data" STAMP TLV is carried by Session-Sender and Session-Reflector test packets. STAMP test packets may carry multiple TLVs of this type. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reflected MPLS Header MNA Data | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TLV fields are defined as follows:¶
Type: Type (value TBA1)¶
STAMP TLV Flags: The STAMP TLV Flags follow the procedures described in [RFC8972].¶
Length: A two-octet field equal to the length of the Data in octets.¶
If, due to some error, such as a mismatch in the length between the NAS or PSH and the Reflected MPLS header MNA data TLV, and the Session-Reflector does not use the received "Reflected MPLS Header MNA Data" STAMP TLV for reflecting MPLS header, it MUST return the STAMP TLV with the U flag (Unrecognized) set to 1 in the STAMP TLV Flags using the procedure defined in [RFC8972].¶
In this document, the Sub-TLV "MNA Header Control" (Type TBA2) is defined for the STAMP TLV Type "Reflected Test Packet Control" (Type 12) introduced in [I-D.ietf-ippm-asymmetrical-pkts].¶
When a Session-Sender test packet is received with the "MNA Header Control" Sub-TLV, the Session-Reflector does not add the NASes and the PSH in the MPLS header of the reply Session-Reflector STAMP test packet that match the received NASes and the PSH.¶
In the absence of this Sub-TLV in the received Session-Sender test packet, the Session-Reflector adds the new NASes and the PSH that match all received NASes and the PSH in the MPLS header of the reply Session-Reflector test packet.¶
The NASes and the PSH received in the Session-Sender test packets are still copied and reflected in STAMP TLVs to the Session-Sender irrespective of this Sub-TLV present or not.¶
The operational considerations specified in [RFC8762] and [I-D.ietf-mpls-mna-hdr] apply to the procedure and extensions defined in this document.¶
The security considerations specified in [RFC8762], [RFC8972], [I-D.ietf-mpls-mna-hdr] 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 them.¶
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 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:¶
Fabian Ihle¶
University of Tuebingen¶
Germany¶
Email: fabian.ihle@uni-tuebingen.de¶
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 |
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 Packet Control | This document |
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.¶