



IPPM Working Group                                        R. Gandhi, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                                 T. Zhou
Expires: 11 May 2026                                              Huawei
                                                                   Z. Li
                                                            China Mobile
                                                         7 November 2025


   Simple Two-Way Active Measurement Protocol (STAMP) Extensions for
             Reflecting STAMP Packet MPLS Extension Headers
                  draft-gandhi-ippm-stamp-mpls-hdr-02

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 11 May 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.






Gandhi, et al.             Expires 11 May 2026                  [Page 1]

Internet-Draft      STAMP for Reflecting MPLS Headers      November 2025


   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.  Receiving MPLS Header on the Session-Reflector  . . . . .   8
   4.  Use Case of Reflecting IOAM Data Fields . . . . . . . . . . .   8
   5.  STAMP Extensions  . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Reflected MPLS Header MNA Data STAMP TLV  . . . . . . . .   9
     5.2.  One-Way Measurement Using Reflected Data STAMP TLVs . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

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.  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.




Gandhi, et al.             Expires 11 May 2026                  [Page 2]

Internet-Draft      STAMP for Reflecting MPLS Headers      November 2025


   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 MNA Sub-Stacks and Post-Stack Header, as
   specified in this document.  The procedure defined in this document
   leverages the existing implementations on the midpoint nodes with
   MPLS data plane, that supports the MNA Sub-Stacks and Post-Stack
   Header used, 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

   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

   PSH: Post-Stack Header

   STAMP: Simple Two-way Active Measurement Protocol

   TLV: Type-Length-Value








Gandhi, et al.             Expires 11 May 2026                  [Page 3]

Internet-Draft      STAMP for Reflecting MPLS Headers      November 2025


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 does not perform any STAMP
   processing.

   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.

              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.  The Session-Reflector
   reflects all received STAMP TLVs from the Session-Sender test
   packets.

   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 MNA Sub-Stack 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 MNA Sub-Stack back in the STAMP TLV.  When adding



Gandhi, et al.             Expires 11 May 2026                  [Page 4]

Internet-Draft      STAMP for Reflecting MPLS Headers      November 2025


   multiple MNA Sub-Stacks in the Session-Sender test packet,
   corresponding "Reflected MPLS Header MNA Data" STAMP TLVs MUST be
   added, with the matching length to the MNA Sub-Stack and Ancillary
   Data and in the same order, in order to receive a copy of that MNA
   Sub-Stack.

   Similarly, when a STAMP Session-Sender adds MNA Post-Stack Header 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 Post-Stack Header.

   As the procedure defined in this document leverages the existing
   implementations on the midpoint nodes for the MNA Sub-Stacks and
   Post-Stack Header, no additional requirements are specified when
   carrying MNA Sub-Stacks and Post-Stack Header in STAMP.  An MNA Sub-
   Stacks and Post-Stack Header are processed by the nodes using the
   same procedures specified in the document that defined them.

   An example STAMP test packet for the MPLS data plane, carrying MNA
   Sub-Stacks and Post-Stack Header and reflected MNA header data in
   STAMP TLVs, is shown in Figure 2.






























Gandhi, et al.             Expires 11 May 2026                  [Page 5]

Internet-Draft      STAMP for Reflecting MPLS Headers      November 2025


    +---------------------------------------------------------------+
    | 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)           |
    ~                                                               ~
    +---------------------------------------------------------------+

       Figure 2: Example STAMP Test Packet with Reflected MPLS Header
                             MNA Data STAMP TLV

   When the Session-Reflector receives a STAMP test packet with an MNA
   and a STAMP TLV "Reflected MPLS Header MNA Data," the Session-
   Reflector that supports this STAMP TLV MUST copy the entire MNA Sub-
   Stack, including the Ancillary Data and header, into the "Reflected
   MPLS Header MNA Data" TLV in the Session-Reflector payload.  When
   there are multiple MNA Sub-Stacks in the Session-Sender test packet,
   each MNA Sub-Stack, including Ancillary Data MUST be processed, in
   order from the top of the label stack, and copied into the
   corresponding STAMP TLV, if that STAMP TLV exists.  Similarly, the



Gandhi, et al.             Expires 11 May 2026                  [Page 6]

Internet-Draft      STAMP for Reflecting MPLS Headers      November 2025


   Session-Reflector MUST process MNA Post-Stack Header and copy the
   entire header 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 MNA
   Sub-Stack or PSH but without corresponding "Reflected MPLS Header MNA
   Data" STAMP TLV, the Session-Reflector does not copy that MNA Sub-
   Stack or PSH into the Session-Reflector test packet.

   When the Session-Sender test packets carry an MNA Sub-Stack or PSH
   that it does not require the Session-Reflector to reflect in the
   Session-Reflector test packet, it does not add the matching
   "Reflected MPLS Header MNA Data" STAMP TLV in the Session-Sender test
   packet.

   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 MNA Sub-Stack and PSH in the MPLS header before copying
   data into the STAMP TLV.  This mechanism is employed in case of
   ambiguity when there are multiple MNA Sub-Stacks and PSH in the MPLS
   header with the same length present and not all need to be copied and
   reflected in the STAMP TLVs.

   The Session-Sender and Session-Reflector test packets are symmetric
   in size, and hence the Session-Sender and Session-Reflector MUST
   ensure that the resulting test packets do not exceed the MPLS MTU
   after adding the Reflected Data STAMP TLVs.  If necessary, Reflected
   Data STAMP TLVs can be removed to avoid violating the MPLS MTU limit.

   If, for any reason, the Session-Reflector does not use the received
   "Reflected MPLS Header MNA Data" STAMP TLV for reflecting data, it
   MUST return the STAMP TLV as unrecognized, i.e., with the U flag
   (Unrecognized) set in the STAMP TLV Flags using the procedure defined
   in [RFC8972].

   The Session-Reflector adds the matching MNA Sub-Stacks and PSH,
   including Ancillary Data, in the Session-Reflector test packet in the
   same order for the reverse direction measurements as described in
   Section 5.2.

   Note that the use case where the MNA Sub-Stack and PSH length changes
   in the Session-Sender test packets along the path is outside the
   scope of this document.  Also, the use case where MNA Sub-Stacks and
   PSH are added or removed in the Session-Sender test packets along the
   path is outside the scope of this document.




Gandhi, et al.             Expires 11 May 2026                  [Page 7]

Internet-Draft      STAMP for Reflecting MPLS Headers      November 2025


3.1.  Receiving MPLS Header on the Session-Reflector

   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 "I2E"
   scopes, the MNA Sub-Stacks and the MNA Post-Stack Header MUST NOT be
   removed by the penultimate node and hence they will be received by
   the egress node of the MPLS LSP.  Note that the MNA Sub-Stack and the
   corresponding MNA Post-Stack Header for the "Select" scope are
   removed from the packets on the transit node where the MNA Sub-Stack
   is processed, and hence they will not be received by the egress node
   of the MPLS LSP.

   The STAMP test packets, carrying the MPLS header with the MNA Sub-
   Stacks and the MNA Post-Stack Headers for "HBH" and "I2E" scopes for
   HBH and E2E performance measurement, respectively, will be received
   by the egress node of the MPLS LSP that has the Session-Reflector.
   When the received STAMP test packets are processed by the data plane
   on the egress node of the MPLS LSP that has the Session-Reflector,
   the data plane MUST provide the received MNA data from the test
   packets to the Session-Reflector on the node.

   Note that the procedure defined in this document for HBH and E2E
   performance measurement is not applicable when using the MNA Sub-
   Stack and MNA Post-Stack Header with the "Select" scope.

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, 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.










Gandhi, et al.             Expires 11 May 2026                  [Page 8]

Internet-Draft      STAMP for Reflecting MPLS Headers      November 2025


   [I-D.ietf-mpls-mna-ioam] defines extensions using MNA to carry IOAM
   data that may be carried in MNA Sub-Stack [I-D.ietf-mpls-mna-hdr] or
   in MNA Post-Stack Header [I-D.ietf-mpls-mna-ps-hdr].  The STAMP
   Session-Sender and Session-Reflector test packets can carry an MNA
   Sub-Stack 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)           |
    ~                                                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 3: Example STAMP Test Packet for IOAM with Reflected MPLS
                            Header MNA Data TLV

5.  STAMP Extensions

5.1.  Reflected MPLS Header MNA Data STAMP TLV

   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.










Gandhi, et al.             Expires 11 May 2026                  [Page 9]

Internet-Draft      STAMP for Reflecting MPLS Headers      November 2025


     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               |
    ~                                                               ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 4: Reflected MPLS Header MNA Data STAMP TLV

   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.

   The Session-Reflector MUST return an error as unrecognized (U flag)
   in the STAMP TLV Flags when it determines that the length of the TLV
   does not match the length of the corresponding MNA Sub-Stack or PSH
   when processing in the same order as the MNA Sub-Stacks and PSH in
   the MPLS header.

5.2.  One-Way Measurement Using Reflected Data STAMP TLVs

   Similarly, in the case of one-way HBH and E2E measurements for MPLS
   data plane, the Session-Reflector does not need to add MNA Sub-Stacks
   and PSH in the reply Session-Reflector test packets matching the
   received MNA Sub-Stacks and PSH.

   In this document, the Sub-TLV "MNA Header Control" (Type TBA2) is
   defined for the STAMP TLV Type "Reflected Test Packet Control TLV"
   (Type TBA-ASYM) 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 received MNA
   Sub-Stacks and PSH in the MPLS header of the reply Session-Reflector
   STAMP test packet.

   In the absence of this Sub-TLV in the received Session-Sender test
   packet, the Session-Reflector adds new MNA Sub-Stacks and PSH
   matching all received MNA Sub-Stacks and PSH in the MPLS header of
   the reply Session-Reflector test packet.




Gandhi, et al.             Expires 11 May 2026                 [Page 10]

Internet-Draft      STAMP for Reflecting MPLS Headers      November 2025


   The MNA Sub-Stacks and PSH received in the Session-Sender test
   packets are still copied and reflected in STAMP TLVs to the Session-
   Sender.

6.  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 the IOAM.

7.  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 TLV" (Type TBA-ASYM) 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
                                 STAMP TLV

8.  References

8.1.  Normative References






Gandhi, et al.             Expires 11 May 2026                 [Page 11]

Internet-Draft      STAMP for Reflecting MPLS Headers      November 2025


   [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>.

   [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>.

   [I-D.ietf-mpls-mna-hdr]
              Rajamanickam, J., Gandhi, R., Zigler, R., Song, H., and K.
              Kompella, "MPLS Network Action (MNA) Sub-Stack Solution",
              Work in Progress, Internet-Draft, draft-ietf-mpls-mna-hdr-
              16, 3 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
              mna-hdr-16>.

   [I-D.ietf-mpls-mna-ps-hdr]
              Rajamanickam, J., Gandhi, R., Zigler, R., Li, T., and J.
              Dong, "Post-Stack MPLS Network Action (MNA) Solution",
              Work in Progress, Internet-Draft, draft-ietf-mpls-mna-ps-
              hdr-03, 1 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
              mna-ps-hdr-03>.

   [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-03, 30 May 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
              mna-ioam-03>.

   [I-D.ietf-ippm-asymmetrical-pkts]
              Mirsky, G., Ruffini, E., Nydell, H., Foote, R. F., and W.
              Hawkins, "Performance Measurement with Asymmetrical
              Traffic Using STAMP", Work in Progress, Internet-Draft,



Gandhi, et al.             Expires 11 May 2026                 [Page 12]

Internet-Draft      STAMP for Reflecting MPLS Headers      November 2025


              draft-ietf-ippm-asymmetrical-pkts-08, 28 June 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
              asymmetrical-pkts-08>.

8.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, <https://www.rfc-editor.org/info/rfc9197>.

Acknowledgments

   The authors of this document would like to thank Greg Mirsky for
   reviewing this document and providing review comments.

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

















Gandhi, et al.             Expires 11 May 2026                 [Page 13]
