IPPM Working Group R. Gandhi, Ed. Internet-Draft Cisco Systems, Inc. Intended status: Standards Track T. Zhou Expires: 21 December 2026 Huawei Z. Li China Mobile F. Ihle University of Tuebingen 19 June 2026 Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet MPLS Extension Headers draft-gandhi-ippm-stamp-mpls-hdr-05 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 21 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Gandhi, et al. Expires 21 December 2026 [Page 1] Internet-Draft STAMP Reflecting MPLS Extension Headers June 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . 9 5. STAMP Extensions . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Reflected MPLS Header MNA Data TLV . . . . . . . . . . . 11 5.2. MNA Header Control Sub-TLV . . . . . . . . . . . . . . . 11 6. Operational Considerations . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 21 December 2026 [Page 2] Internet-Draft STAMP Reflecting MPLS Extension Headers June 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 [I-D.ietf-mpls-mna-hdr] and Post-Stack MPLS Header (PSMH) for MNA 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 data fields defined in [RFC9197] 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 for MNA, 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 for MNA, without any additional requirements. 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 IOAM: In Situ Operations, Administration, and Maintenance MNA: Multiprotocol Label Switching Network Action Gandhi, et al. Expires 21 December 2026 [Page 3] Internet-Draft STAMP Reflecting MPLS Extension Headers June 2026 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 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. Gandhi, et al. Expires 21 December 2026 [Page 4] Internet-Draft STAMP Reflecting MPLS Extension Headers June 2026 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. This document defines procedures and STAMP extensions for a Session-Reflector to reflect the received MPLS extension headers back to the Session-Sender, including 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 for MNA 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 for MNA. An example STAMP test packet for carrying NASes and a PSMH for MNA and reflected data in the "Reflected MPLS Header MNA Data" TLVs is shown in Figure 2. Gandhi, et al. Expires 21 December 2026 [Page 5] Internet-Draft STAMP Reflecting MPLS Extension Headers June 2026 +---------------------------------------------------------------+ | MPLS Header | ~ ~ +---------------------------------------------------------------+ | MNA Sub-Stack-1 I-D.ietf-mpls-mna-hdr | ~ ~ +---------------------------------------------------------------+ ~ ... ~ +---------------------------------------------------------------+ | MNA Sub-Stack-N I-D.ietf-mpls-mna-hdr | ~ ~ +---------------------------------------------------------------+ ~ ... ~ +---------------------------------------------------------------+ | 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 Gandhi, et al. Expires 21 December 2026 [Page 6] Internet-Draft STAMP Reflecting MPLS Extension Headers June 2026 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 for MNA that the Session-Sender does not require the Session-Reflector to reflect in Session-Reflector test packets, the Session-Sender MUST NOT add a corresponding "Reflected MPLS Header MNA Data" TLV in the Session- Sender test packets. 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 for MNA 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 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 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. Similarly, the Session-Reflector MUST process the PSMH for MNA and copy the entire PSMH for MNA and the Ancillary Data into the corresponding "Reflected MPLS Header MNA Data" TLV, if that STAMP TLV exists. When the Session-Reflector receives a STAMP test packet with a NAS or a PSMH for MNA but without a corresponding "Reflected MPLS Header MNA Data" TLV, the Session-Reflector does not copy that NAS or PSMH for MNA 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. 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) of the "Requested MPLS Header MNA Data" field (shown in Figure 4) of the "Reflected MPLS Header MNA Data" TLV, the Session- Reflector MUST match the values in the corresponding NAS or PSMH for MNA in the MPLS header before copying the data into the STAMP TLV. This mechanism is employed in cases of ambiguity when there are multiple NASes and PSMHs for MNA in the MPLS header of the same length present and not all need to be copied and reflected in the STAMP TLVs. This check is also used when not all NASes and PSMHs for MNA need to be reflected in STAMP TLVs and hence there are no corresponding "Reflected MPLS Header MNA Data" TLVs added for them. Gandhi, et al. Expires 21 December 2026 [Page 7] Internet-Draft STAMP Reflecting MPLS Extension Headers June 2026 As the procedure defined in this document leverages the existing implementations at the midpoint nodes for the NASes and PSMHs for MNA, no additional requirements are specified when carrying these NASes and PSMH for MNA in STAMP test packets. The NASes and PSMH for MNA 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 for MNA 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 for MNA 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. In the two-way measurement type, the Session-Reflector adds new matching NASes and PSMHs for MNA, 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 of the new NASes and PSMHs for MNA added in Session-Reflector test packets is a local decision at the Session-Reflector. The STAMP Session-Sender enables this by adding "MNA Header Control" Sub-TLV for the "Reflected Test Packet Control" TLV in the Session-Sender test packets. In the one-way measurement type, the Session-Reflector does not add the new matching NASes and the PSMHs for MNA, including Ancillary Data, in the MPLS header of the Session-Reflector test packets corresponding to the received MPLS extension headers in the Session- Sender test packets. The measurement type for a STAMP session is locally provisioned on the STAMP Session-Sender. Gandhi, et al. Expires 21 December 2026 [Page 8] Internet-Draft STAMP Reflecting MPLS Extension Headers June 2026 3.3. Receiving MPLS Header from the Data Plane on Egress Node 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 PSMHs for MNA 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 MNA 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 MNA 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 PSMH for MNA 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 for MNA from the Session-Reflector test packets to the Session-Sender on the node for the two-way measurement type. 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 for MNA to carry the IOAM option types defined in [RFC9197] for an MPLS data plane. The STAMP Session-Sender and Session-Reflector test Gandhi, et al. Expires 21 December 2026 [Page 9] Internet-Draft STAMP Reflecting MPLS Extension Headers June 2026 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) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 the 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 Gandhi, et al. Expires 21 December 2026 [Page 10] Internet-Draft STAMP Reflecting MPLS Extension Headers June 2026 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 for MNA. 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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reflected MPLS Header MNA Data | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 length of the Data in octets. If, due to some error, such as a mismatch in the length between a NAS or PSMH for MNA and the "Reflected MPLS Header MNA Data" TLV, the Session-Reflector does not use the received "Reflected MPLS Header MNA Data" TLV for reflecting the NAS or PSMH for MNA, the Session- Reflector MUST return the STAMP TLV with the U flag (Unrecognized TLV) set to 1 in the STAMP TLV Flags using the procedure defined in [RFC8972]. 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. Gandhi, et al. Expires 21 December 2026 [Page 11] Internet-Draft STAMP Reflecting MPLS Extension Headers June 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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]. Sub-TLV Length: A two-octet field equal to the length of the Data in octets. It is set to 0. When a Session-Sender test packet is received with the "MNA Header Control" Sub-TLV, the Session-Reflector MUST add the new matching NASes and PSMHs for MNA in the MPLS header of the Session-Reflector STAMP test packet in the same order corresponding to the received NASes and PSMHs for MNA in the Session-Sender test packet. In the absence of this Sub-TLV in the received Session-Sender test packet, the Session-Reflector MAY not add new matching NASes or PSMHs for MNA corresponding to the received NASes and PSMHs for MNA in the Session-Reflector test packet. This behaviour can be based on a local policy on the Session-Reflector. The NASes and PSMHs for MNA 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. If for any reason, the Session-Reflector cannot add a new matching NAS or PSMH for MNA in the Session-Reflector test packet, for example, if the Session-Reflector does not support the NAS or PSMH for MNA, the Session-Reflector MUST return the STAMP TLV with the C flag (Conformance) set to 1 in the Sub-TLV Flags of the Sub-TLV using the procedure defined in [I-D.ietf-ippm-asymmetrical-pkts]. STAMP test packets MUST NOT carry more than one "MNA Header Control" Sub-TLV in a "Reflected Test Packet Control" TLV. If a Session- Sender test packet contains more than one "MNA Header Control" Sub- TLV, the Session-Reflector MUST return the STAMP TLV with the U flag (Unrecognized TLV) set to 1 in the STAMP TLV Flags using the procedure defined in [RFC8972]. Gandhi, et al. Expires 21 December 2026 [Page 12] Internet-Draft STAMP Reflecting MPLS Extension Headers June 2026 6. Operational Considerations The operational considerations specified in [RFC8762] and [I-D.ietf-mpls-mna-hdr] 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. 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], [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 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 T2 is later than T1 in the STAMP Reference Topology shown in Figure 1) 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. Gandhi, et al. Expires 21 December 2026 [Page 13] Internet-Draft STAMP Reflecting MPLS Extension Headers June 2026 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: 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 Gandhi, et al. Expires 21 December 2026 [Page 14] Internet-Draft STAMP Reflecting MPLS Extension Headers June 2026 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, . [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, . [I-D.ietf-mpls-mna-hdr] Rajamanickam, J., Gandhi, R., Zigler, R., Song, H., and K. Kompella, "MPLS Network Action (MNA) Sub-Stack Specification including In-Stack Network Actions and Data", Work in Progress, Internet-Draft, draft-ietf-mpls- mna-hdr-21, 24 February 2026, . [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-08, 2 April 2026, . [I-D.ietf-mpls-mna-ioam] Gandhi, R., Mirsky, G., Li, T., Song, H., and B. Wen, "Supporting In Situ Operations, Administration and Maintenance Using MPLS Network Actions", Work in Progress, Internet-Draft, draft-ietf-mpls-mna-ioam-05, 19 May 2026, . Gandhi, et al. Expires 21 December 2026 [Page 15] Internet-Draft STAMP Reflecting MPLS Extension Headers June 2026 [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, . 10.2. Informative References [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, . [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, . [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 Gandhi, et al. Expires 21 December 2026 [Page 16] Internet-Draft STAMP Reflecting MPLS Extension Headers June 2026 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 21 December 2026 [Page 17]