| Internet-Draft | STAMP Reflecting MPLS MNA Headers | September 2026 |
| Gandhi, et al. | Expires 22 March 2027 | [Page] |
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 Network Action Sub-Stacks and Post-Stack MPLS Headers, for HBH and E2E active measurements, for example, by using the 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 22 March 2027.¶
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. STAMP test packets are transmitted along a path between a Session-Sender and a Session-Reflector to measure Edge-to-Edge performance metrics, such as delay, delay variation, 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]. 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 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 concerns only the PSMH for the MNA type [I-D.ietf-mpls-mna-ps-hdr].¶
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.¶
| Abbreviation | Meaning | Reference |
|---|---|---|
| DEX | Direct Export | [RFC9326] |
| E2E | Edge-to-Edge | [RFC9197] |
| HBH | Hop-by-Hop | [RFC9994] |
| IOAM | In Situ Operations, Administration, and Maintenance | [RFC9197] |
| MPLS | Multiprotocol Label Switching | [RFC9994] |
| MNA | MPLS Network Action | [RFC9994] |
| MTU | Maximum Transmission Unit | [RFC9994] |
| NAS | Network Action Sub-Stack | [RFC9994] |
| PSMH | Post-Stack MPLS Header | [I-D.ietf-mpls-mna-ps-hdr] |
| STAMP | Simple Two-Way Active Measurement Protocol | [RFC8762] |
| TLV | Type-Length-Value | [RFC8972] |
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], the Session-Sender and Session-Reflector test packets are symmetric in size when all optional TLVs are included (but excluding transport and network 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 MPLS headers containing NASes and PSMHs. This document defines procedures and STAMP extensions for a Session-Reflector to reflect the received MPLS NASes and PSMHs back to the Session-Sender for both one-way and two-way measurement types.¶
This document 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 to receive a copy of that NAS back in the STAMP TLV. The Length of the TLV is set to the total size of the NAS or PSMH to be reflected, in octets, and the Requested MPLS Header MNA Data field contains the first 8 octets of the target NAS or PSMH. The format of this TLV is specified in Section 5.1.¶
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 a matching length 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.¶
+---------------------------------------------------------------+ | 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
When adding multiple NASes or PSMHs in the Session-Sender test packet, the corresponding "Reflected MPLS Header MNA Data" TLVs MUST be added in the same order as those headers to receive copies of them. 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 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 and PSMHs (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.¶
The "Reflected MPLS Header MNA Data" field in the "Reflected MPLS Header MNA Data" TLV in Session-Sender test packets MUST be initialized to all zeros. When multiple NASes and PSMHs of the same length are present and not all need to be copied and reflected in the STAMP TLVs, the Session-Sender MUST populate the "Requested MPLS Header MNA Data" field (shown in Figure 4) with the first 8 octets of the target NAS or PSMH to disambiguate it.¶
When the Session-Reflector receives a STAMP test packet with a NAS or a PSMH and a corresponding "Reflected MPLS Header MNA Data" TLV and the Session-Reflector supports this TLV, the following rules apply:¶
If the Session-Reflector receives a Session-Sender test packet with a non-zero "Requested MPLS Header MNA Data" field in the "Reflected MPLS Header MNA Data" TLV, it MUST copy the corresponding NAS or PSMH only if the requested length matches the NAS or PSMH length and the first 8 octets match, excluding the mutable 13-bit Ancillary Data field in the NAS and the 16-bit Post-Stack Data field in the PSMH.¶
If the "Requested MPLS Header MNA Data" field is zero, the Session-Reflector MUST select the first NAS or PSMH with the matching length and copy its first 8 octets into the "Requested MPLS Header MNA Data" field of the "Reflected MPLS Header MNA Data" TLV.¶
If no NAS or PSMH matches the requested data and length, 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].¶
The Session-Reflector MUST copy the portion of the NAS or PSMH after the first 8 octets into the corresponding "Reflected MPLS Header MNA Data" field in the Session-Reflector test packet payload.¶
When multiple NASes or PSMHs are present, each MUST be processed in order from the top of the label stack and copied 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 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.¶
Because this procedure leverages 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 procedures specified in the documents that define them.¶
The Session-Sender and Session-Reflector MUST ensure that the complete resulting test packet, including all applicable MPLS, IP, UDP, STAMP, and reflected-header TLV fields, does not exceed the applicable path 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 path 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.¶
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 locally generated matching NASes and PSMHs, including Ancillary Data, in the MPLS header of the Session-Reflector test packets in the same order as the NASes and PSMHs received in the Session-Sender test packets for the reverse-direction measurement. These headers need not be byte-for-byte copies of the received headers; their length and content are local decisions 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 (Type 12) in the Session-Sender test packets.¶
In the one-way measurement type, the Session-Reflector MAY omit adding 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, based on its local policy. This does not preclude the Session-Reflector from adding MPLS headers independently. However, the Session-Reflector still copies received NASes and PSMHs into the corresponding "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.¶
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 are 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 and for HBH and E2E measurements, respectively, are 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 ingress 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.¶
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 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) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IOAM Direct Exporting (DEX) [RFC9326] is applicable with STAMP test packets for on-path telemetry use cases. 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 omit a corresponding "Reflected MPLS Header MNA Data" TLV in Session-Sender test packets for the IOAM DEX option type.¶
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 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) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 size of the NAS or PSMH to be reflected, in octets.¶
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.¶
For matching, the mutable 13-bit Ancillary Data field in the NAS and the 16-bit Post-Stack Data field in the PSMH are excluded from the first 8 octets.¶
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 portion of the reflected NAS or PSMH after the first 8 octets, 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 cannot use it to reflect any received NAS or PSMH, 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:¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Sub-TLV fields are defined as follows:¶
Type: Sub-TLV Type (value TBA2).¶
Sub-TLV Flags: The Sub-TLV Flags follow the procedures for STAMP TLV Flags described in [RFC8972].¶
Sub-TLV Length: A two-octet field equal to the length of the Data field in octets. It is set to 0.¶
When the Session-Reflector receives a STAMP test packet with the "MNA Header Control" Sub-TLV and the Session-Reflector supports this Sub-TLV, the following rules apply:¶
The Session-Reflector MUST add locally generated matching NASes and PSMHs, subject to the relevant MPLS data-plane specifications, in the same order as the NASes and PSMHs received in the Session-Sender test packet. The generated NASes and PSMHs need not be byte-for-byte copies of the received headers.¶
In the absence of the "MNA Header Control" Sub-TLV in the received Session-Sender test packet, the Session-Reflector MAY omit adding locally generated matching NASes or PSMHs in the Session-Reflector test packet corresponding to the received NASes and PSMHs, based on its local policy. This does not preclude the Session-Reflector from adding MPLS headers independently of the received MPLS headers.¶
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.¶
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" (Type 12) 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 the data plane.¶
STAMP test packets MUST NOT carry more than one "MNA Header Control" Sub-TLV in a "Reflected Test Packet Control" TLV (Type 12). If the "Reflected Test Packet Control" TLV (Type 12) 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 (Type 12) with the C flag (Conformance) set to 1 in the Sub-TLV Flags of each "MNA Header Control" Sub-TLV, using the procedure defined in [I-D.ietf-ippm-asymmetrical-pkts].¶
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.¶
An operator MAY provision a local policy on a Session-Reflector not to copy and reflect the received MPLS NASes and PSMHs in the Session-Reflector test packets to avoid exposing the collected network information to the Session-Sender.¶
The security considerations specified in [RFC8762], [RFC8972], and [I-D.ietf-ippm-asymmetrical-pkts] apply to the procedure and extensions defined in this document. The security considerations specified in [RFC9994] and [I-D.ietf-mpls-mna-ps-hdr] also 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 in received reply test packets at the Session-Sender. For example, verifying that T2 is later than T1 requires clock synchronization between the Session-Sender and Session-Reflector. In contrast, checking that T3 is greater than or equal to T2, or that T4 is later than T1, compares timestamps generated at the same node and does not require clock synchronization. The minimal state associated with this protocol also limits the extent of measurement disruption caused by a corrupt or invalid packet to a single test cycle.¶
Furthermore, implementations SHOULD NOT assign STAMP Session-IDs [RFC8972] in a predictable manner. To avoid predictability, implementations can leverage a Cryptographically Secure Pseudorandom Number Generator [NIST-CSPRNG].¶
Editorial note: Please remove this section prior to publication.¶
An open-source implementation of STAMP with optional TLVs defined in [RFC8972], MPLS Network Action (with In-Stack and Post-Stack Data), and the IOAM preallocated 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 for the Tofino2 platform.¶
- 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.¶