| Internet-Draft | STAMP Reflecting MPLS MNA Headers | October 2026 |
| Gandhi, et al. | Expires 19 April 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, 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 19 April 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) [RFC8762] provides capabilities for the measurement of various performance metrics in IP networks 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 (E2E) 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 a packet traverses a path between two points in the network. The information from the collected IOAM data fields [RFC9197] can be used to support Hop-by-Hop (HBH) and E2E measurement use cases.¶
MPLS packets may carry MPLS Network Action (MNA) Sub-Stacks (NASes), as specified in [RFC9994], and Post-Stack MPLS Headers (PSMHs) for the MNA type, as specified in [I-D.ietf-mpls-mna-ps-hdr].¶
[I-D.ietf-mpls-mna-ioam] specifies MNA Sub-Stacks and PSMHs to carry the IOAM option types specified in [RFC9197] and [RFC9326] for an MPLS data plane.¶
It may be desirable in some contexts (e.g., diagnostics) 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 using optional STAMP extensions to reflect MPLS NASes and PSMHs, as specified in this document. The procedure specified in this document uses existing implementations on midpoint nodes that support the NASes and PSMHs in the MPLS data plane; it imposes no additional requirements on those nodes.¶
This document does not cover use cases in which NAS or PSMH lengths change along the path, or in which NASes or PSMHs are added to or removed from the MPLS header of a Session-Sender test packet along the path. A PSMH can be defined for types other than MNA. This document concerns only PSMHs 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.¶
This document uses terms defined in [RFC8762], specifically Session-Sender, Session-Reflector, Session-Test packet, and symmetric.¶
This document uses terms defined in [RFC8972], specifically STAMP TLV Flags and Sub-TLVs.¶
| Abbreviation | Meaning | Reference |
|---|---|---|
| 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. The Session-Reflector test packets are transmitted to the Session-Sender S1 on the same path (i.e., the same set of links and nodes as shown in Figure 1) or on a different path in the reverse direction from the path taken towards the Session-Reflector R1. Node M1 is a midpoint node that does not perform any STAMP processing. A STAMP-Test packet is not required to transit through the same midpoint node M1 in both directions.¶
T1 T2
/ \
+-------+ Test Packet +-------+ +-------+
| | - - - - - - - - | | - - - - - - - - ->| |
| S1 |=================| M1 |===================| R1 |
| |<- - - - - - - - | | - - - - - - - - - | |
+-------+ +-------+ Reply Test Packet +-------+
\ /
T4 T3
STAMP Session-Sender STAMP Session-Reflector
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.¶
All four timestamps are used by the Session-Sender to measure the two-way delay metric as ((T4 - T1) - (T3 - T2)). The "two-way delay" is the sum of the one-way delays in each direction and reflects the delay of the bidirectional path, irrespective of processing delays within the Session-Reflector.¶
Timestamps T1 and T2 are used by the Session-Sender to measure the one-way delay metric as (T2 - T1), also referred to as the near-end (forward direction) delay metric. Note that the delay value (T4 - T3), measured by the Session-Sender, is referred to as the far-end (backward direction) one-way delay metric. The computation of the one-way delay metric requires the clocks on the Session-Sender and Session-Reflector to be synchronized using either PTPv2 or NTPv4.¶
As specified in [RFC8972], the Session-Sender test packets and the Session-Reflector test packets are symmetric in size when including all optional TLVs (but excluding transport and network headers). A 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.¶
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 unidirectional and bidirectional measurement types (see Section 5).¶
The IPv4/IPv6 and UDP headers follow the procedure specified in Section 3.1 of [I-D.ietf-ippm-stamp-ext-hdr], and IPv4/IPv6 UDP checksum handling for STAMP-Test packets follow the procedure specified in Section 8 of [I-D.ietf-ippm-stamp-ext-hdr].¶
This document defines the "Reflected MPLS Header MNA Data" TLV for STAMP (Type TBA1). A Session-Sender uses this TLV to request reflection of a Network Action Sub-Stack (NAS) or Post-Stack MPLS Header (PSMH) received in its test packet. The TLV is carried in Session-Sender and Session-Reflector test packets, and a STAMP-Test packet MAY carry one or more TLVs of this type. The same TLV type is used for NASes and PSMHs. The format of the TLV is shown in Figure 2.¶
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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Received MPLS Header MNA Data | ~ (Length - 8 octets) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "Reflected MPLS Header MNA Data" TLV fields are defined as follows:¶
STAMP TLV Flags: The STAMP TLV Flags follow the procedures specified in Section 4 of [RFC8972].¶
Type: MUST be set to TBA1.¶
Length: A two-octet field containing the total length, in octets, of the NAS or PSMH to be reflected. It includes the lengths of the Requested MPLS Header MNA Data field and the Received MPLS Header MNA Data field.¶
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 disambiguates which NAS or PSMH in the received MPLS header the Session-Reflector MUST copy into the "Reflected MPLS Header MNA Data" TLV when multiple NASes or PSMHs of the same length are present.¶
For matching, the mutable 13-bit Ancillary Data field in a NAS and the 16-bit Post-Stack Data field in a PSMH are excluded from the first 8 octets.¶
If all octets in this field are zero, the Session-Reflector MUST match the first NAS or PSMH in the MPLS header with the matching length.¶
Received MPLS Header MNA Data: A variable-length field containing the remaining (Length - 8) octets of the NAS or PSMH after its first 8 octets, copied from the received MPLS header by the Session-Reflector.¶
In Session-Sender test packets, this field MUST be initialized to all zeros.¶
When a Session-Reflector recognizes the received "Reflected MPLS Header MNA Data" TLV but cannot use it to reflect a received NAS or PSMH, it MUST return the "Reflected MPLS Header MNA Data" TLV with the Conformant Reflected Packet STAMP TLV flag set to 1 in the STAMP TLV Flags, following the procedure specified in [RFC10052]. This can occur, for example, if:¶
The requested length does not match the length of the received NAS or PSMH.¶
The Session-Reflector cannot access the received NASes or PSMHs from the data plane, or the data plane does not support NASes or PSMHs.¶
No NAS or PSMH matches the requested data and length, or the NAS or PSMH is invalid.¶
More than one NAS or PSMH of the requested length matches a non-zero Requested MPLS Header MNA Data field, excluding the mutable fields specified above.¶
For each NAS or PSMH in a Session-Sender test packet that the Session-Sender requires the Session-Reflector to reflect, the Session-Sender MUST add a corresponding "Reflected MPLS Header MNA Data" TLV to the test packet. The Session-Sender requests a copy of that NAS or PSMH in the corresponding TLV in the Session-Reflector test packet.¶
An example of a STAMP-Test packet carrying NASes, a PSMH, and their corresponding "Reflected MPLS Header MNA Data" TLVs is shown in Figure 3.¶
+---------------------------------------------------------------+ | MPLS Header | ~ ~ +---------------------------------------------------------------+ | MNA Sub-Stack-1 [RFC9994] | ~ ~ +---------------------------------------------------------------+ ~ ... ~ +---------------------------------------------------------------+ | MNA Sub-Stack-N [RFC9994] | ~ ~ +---------------------------------------------------------------+ ~ ... ~ +---------------------------------------------------------------+ | Post-Stack MPLS Header-1 [I-D.ietf-mpls-mna-ps-hdr] | ~ ~ +---------------------------------------------------------------+ | IP Header | +---------------------------------------------------------------+ | UDP Header | +---------------------------------------------------------------+ | STAMP Packet [RFC8972] | ~ ~ +---------------------------------------------------------------+ | Reflected MPLS Header MNA Data-1 TLV (TBA1) | | MNA Sub-Stack | ~ ~ +---------------------------------------------------------------+ ~ ... ~ +---------------------------------------------------------------+ | Reflected MPLS Header MNA Data-M TLV (TBA1) | | MNA Sub-Stack | ~ ~ +---------------------------------------------------------------+ | Reflected MPLS Header MNA Data-1 TLV (TBA1) | | Post-Stack MPLS Header | ~ ~ +---------------------------------------------------------------+ Note: Value of M <= N
When a Session-Sender test packet contains multiple NASes or PSMHs that the Session-Sender requires the Session-Reflector to reflect, the corresponding "Reflected MPLS Header MNA Data" TLVs MUST appear in the same order as those headers in the test packet. When the Session-Sender does not require the Session-Reflector to reflect a NAS or PSMH in the Session-Reflector test packet, the Session-Sender MUST NOT add a corresponding "Reflected MPLS Header MNA Data" TLV to its test packet. In this case, the number of TLVs (M in Figure 3) is less than the number of NASes and PSMHs (N in Figure 3).¶
The number of "Reflected MPLS Header MNA Data" TLVs MUST NOT exceed the total number of NASes and PSMHs in the Session-Sender test packet.¶
In Session-Sender test packets, the Received MPLS Header MNA Data field MUST be initialized to all zeros. If multiple NASes or PSMHs of the same length are present and the Session-Sender requires the Session-Reflector to reflect only some of them, the Session-Sender MUST populate the Requested MPLS Header MNA Data field (see Figure 2) with the first 8 octets of the NAS or PSMH to be reflected. For matching, the mutable 13-bit Ancillary Data field in a NAS and the 16-bit Post-Stack Data field in a PSMH are excluded from those octets. For each requested NAS or PSMH, the non-zero Requested MPLS Header MNA Data value MUST match exactly one NAS or PSMH of the requested length, excluding those mutable fields. An all-zero value continues to select the first NAS or PSMH of the matching length. If the requested NAS or PSMH cannot be uniquely selected under these rules, the Session-Sender MUST NOT request selective reflection of that header.¶
When a Session-Reflector supports the "Reflected MPLS Header MNA Data" TLV and receives a Session-Sender test packet containing a valid NAS or PSMH and a corresponding TLV, the following rules apply:¶
If the Requested MPLS Header MNA Data field in the received TLV is non-zero and exactly one NAS or PSMH of the requested length matches the field, the Session-Reflector MUST select that NAS or PSMH. For matching, the mutable 13-bit Ancillary Data field in a NAS and the 16-bit Post-Stack Data field in a PSMH are excluded.¶
If a non-zero Requested MPLS Header MNA Data field matches more than one NAS or PSMH of the requested length, excluding those mutable fields, the Session-Reflector MUST return the "Reflected MPLS Header MNA Data" TLV with the Conformant Reflected Packet STAMP TLV flag set to 1 in the STAMP TLV Flags, following the procedure specified in [RFC10052], and MUST NOT copy data from any of the matching headers.¶
If the Requested MPLS Header MNA Data field is all zeros, 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 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 Conformant Reflected Packet STAMP TLV flag set to 1 in the STAMP TLV Flags, following the procedure specified in [RFC10052].¶
The Session-Reflector MUST copy the portion of the NAS or PSMH after its first 8 octets into the Received MPLS Header MNA Data field in the Session-Reflector test packet.¶
When multiple NASes or PSMHs are present, the Session-Reflector MUST process them in their order in the received test packet, beginning with the top of the label stack, and copy each into its corresponding "Reflected MPLS Header MNA Data" TLV in the Session-Reflector test packet, if such a TLV is present.¶
When a Session-Reflector receives a Session-Sender test packet containing a NAS or PSMH without a corresponding "Reflected MPLS Header MNA Data" TLV, it cannot copy that header into the Session-Reflector test packet.¶
Because this procedure leverages existing implementations at midpoint nodes, it imposes no additional requirements when NASes and PSMHs are carried in STAMP-Test packets. Midpoint nodes process these headers using the procedures specified in their defining documents.¶
Each Session-Sender and Session-Reflector MUST determine the applicable path MTU for the direction in which it transmits STAMP-Test packets. This information may be provisioned, collected through management protocols, learned through a mechanism such as MTU signaling for Label Distribution Protocol [RFC3988] or Path MTU Discovery for IPv6 [RFC8201], or distributed by a control protocol. The mechanisms for obtaining this information are outside the scope of this document.¶
The transmitting node MUST ensure that the complete STAMP-Test packet, including all applicable MPLS, IP, UDP, STAMP, and "Reflected MPLS Header MNA Data" TLV fields, does not exceed the applicable path MTU. If the packet exceeds this limit, the node MUST remove complete "Reflected MPLS Header MNA Data" TLVs one at a time, starting with the last TLV in the packet, until the packet fits. The remaining TLVs MUST retain their relative order. If removing all such TLVs does not bring the packet within the path MTU, the node MUST NOT transmit it.¶
The Session-Reflector MUST return requested TLVs that it can process in the order received. The Session-Sender can identify MTU-driven removal by comparing the ordered TLV sequence it sent with the sequence returned by the Session-Reflector; an intentionally unrequested header has no corresponding TLV in the Session-Sender packet. The Conformant Reflected Packet STAMP TLV flag does not indicate MTU-driven removal.¶
For the HBH and Ingress-to-Egress (I2E) scopes, the penultimate node MUST NOT remove the last copy of the NASes and PSMHs. As a result, the egress node receives them, as specified in Section 9.3 of [RFC9994] ("Penultimate Node Responsibilities") and Section 6.3 of [I-D.ietf-mpls-mna-ps-hdr] ("Penultimate Node Responsibilities").¶
For the "Select" scope, the NAS and its corresponding PSMH are removed from a packet at the transit node that processes the NAS. Therefore, they are not received by the egress node.¶
STAMP-Test packets carrying MPLS headers with NASes for the HBH and I2E scopes and PSMHs for HBH and E2E measurements are received by the egress node that hosts the Session-Reflector. When the egress data plane processes these packets, it MUST provide the MPLS headers containing the NASes and PSMHs from the Session-Sender test packets to the Session-Reflector for both unidirectional and bidirectional measurement types (see Section 5).¶
Similarly, when the ingress data plane processes the received STAMP-Test packets in the reverse direction, it MUST provide the MPLS headers containing the NASes and PSMHs from the Session-Reflector test packets to the Session-Sender for the bidirectional measurement type (see Section 5).¶
This document defines the "MNA Header Control" Sub-TLV (Type TBA2) for the "Reflected Test Packet Control" TLV (Type 12) specified in [RFC10052]. The format of the "MNA Header Control" Sub-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Flags | Type = TBA2 | Sub-TLV Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MNA Header Control Sub-TLV fields are defined as follows:¶
Sub-TLV Flags: An eight-bit field. The format, values, and interpretation of flags are as defined for STAMP TLV Flags [RFC8972]. Flag values are taken from the "STAMP TLV Flags" registry [IANA-STAMP].¶
Type: MUST be set to TBA2.¶
Sub-TLV Length: A two-octet field equal to the length of the Data field in octets. It MUST be set to 0.¶
When a Session-Reflector receives a Session-Sender 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 headers 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, a Session-Reflector omits adding locally generated matching NASes and 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 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 to the Session-Reflector test packet, the Session-Reflector MUST return the "Reflected Test Packet Control" TLV (Type 12) [RFC10052] with the Conformant Reflected Packet STAMP TLV flag set to 1 in the Sub-TLV Flags of the "MNA Header Control" Sub-TLV, following the procedure specified in [RFC10052]. This can occur, for example, when the Session-Reflector does not support the NAS or PSMH, or 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) [RFC10052]. 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 Conformant Reflected Packet STAMP TLV flag set to 1 in the Sub-TLV Flags of each "MNA Header Control" Sub-TLV, using the procedure specified in [RFC10052].¶
This document defines two measurement types: unidirectional and bidirectional measurements. These types relate only to whether the Session-Reflector adds new matching NASes and PSMHs for the reverse path. The Session-Reflector still copies and reflects the received NASes and PSMHs into the corresponding "Reflected MPLS Header MNA Data" TLVs (see Section 4.1) in both measurement types.¶
The measurement type for a STAMP session is locally provisioned on the STAMP Session-Sender.¶
In the bidirectional measurement type:¶
A Session-Reflector adds locally generated matching NASes and PSMHs, including Ancillary Data, to 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 (see Section 5.1) for the "Reflected Test Packet Control" TLV (Type 12) [RFC10052] to the Session-Sender test packets.¶
In the unidirectional measurement type:¶
A Session-Reflector omits adding new matching NASes and PSMHs to the MPLS header of its test packets in response to the NASes and PSMHs received in the Session-Sender test packets, based on its local policy. This does not preclude the Session-Reflector from adding MPLS headers independently.¶
This type is the default if the "MNA Header Control" Sub-TLV is absent from the Session-Sender test packet.¶
IOAM is used for recording and collecting operational and telemetry information while a packet traverses a path between two points in the network. The IOAM data fields are specified in [RFC9197]. Examples of data recorded by IOAM Trace Options include per-hop information, such as node ID, timestamp, queue depth, interface identifier, 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 procedures and STAMP extensions specified 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 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 specified in [RFC9197] for an MPLS data plane. The STAMP Session-Sender and Session-Reflector test packets carry IOAM option types in NASes and PSMHs for recording and collecting HBH and E2E operational and telemetry information for active measurements, as shown in Figure 5.¶
+---------------------------------------------------------------+ | MPLS Header | +---------------------------------------------------------------+ | IOAM MNA Sub-Stack [I-D.ietf-mpls-mna-ioam] | ~ ~ +---------------------------------------------------------------+ | IOAM Post-Stack MPLS Header [I-D.ietf-mpls-mna-ioam] | ~ ~ +---------------------------------------------------------------+ | IP Header | +---------------------------------------------------------------+ | UDP Header | +---------------------------------------------------------------+ | STAMP Packet [RFC8972] | +---------------------------------------------------------------+ | Reflected MPLS Header MNA Data TLV (TBA1) | | IOAM MNA Sub-Stack | ~ ~ +---------------------------------------------------------------+ | Reflected MPLS Header MNA Data TLV (TBA1) | | IOAM Post-Stack MPLS Header | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session-Sender, midpoint nodes, and the Session-Reflector process the IOAM data fields, as specified in [RFC9197]. Note that using the IOAM option type "Incremental Trace Option-Type" is not supported by [I-D.ietf-mpls-mna-ioam].¶
IOAM Direct Exporting [RFC9326] is applicable to 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 fields would be recorded in the STAMP-Test packets. Hence, the Session-Sender omits a corresponding "Reflected MPLS Header MNA Data" TLV in Session-Sender test packets for the IOAM Direct Exporting option type.¶
The operational considerations specified in [RFC8762], [RFC10052], [RFC9994], and [I-D.ietf-mpls-mna-ps-hdr] apply to the procedures and extensions specified in this document.¶
In addition, the management and deployment considerations specified in [RFC9197] apply when using the IOAM data fields specified in that document.¶
An implementation must provide the ability to provision the measurement type as unidirectional or bidirectional, as specified in Section 5.¶
Additionally, an operator may provision a local policy on a Session-Reflector not to copy and reflect the received MPLS NASes and PSMHs in Session-Reflector test packets to avoid exposing the collected network information to Session-Senders.¶
The operational cosniderations related to the STAMP Session State notification specified in Section 9.2 of [I-D.ietf-ippm-stamp-ext-hdr] and Rate Limiting specified in Section 9.3 of [I-D.ietf-ippm-stamp-ext-hdr] also apply to the procedure specified in this document.¶
The procedure in Section 4.2 uses the first 8 octets of each NAS or PSMH to disambiguate the target header when multiple NASes or PSMHs of the same length are present. The mutable 13-bit Ancillary Data field in a NAS and the 16-bit Post-Stack Data field in a PSMH are excluded from matching, as specified in Section 4.1 and Section 4.2. An operator should verify that the non-mutable bits in the first 8 octets used for matching remain unchanged in transit when only some headers are to be copied and reflected in STAMP TLVs.¶
Additionally, the procedure in Section 4.4 requires the data plane on the ingress and egress nodes to provide the received MPLS headers to the Session-Sender and the Session-Reflector, respectively.¶
For the reasons mentioned above, an operator should verify that the NASes and PSMHs are received correctly at the Session-Reflector and the Session-Sender.¶
The security considerations specified in [RFC8762], [RFC8972], [RFC9994], [RFC10052], and [I-D.ietf-mpls-mna-ps-hdr] apply to the procedures and extensions specified 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 specified 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 reverse direction paths used to transmit STAMP-Test packets so that collected network information is not exposed to 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 in the STAMP Reference Topology shown in Figure 1 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 test packet to a single test cycle.¶
Furthermore, implementations MUST NOT assign STAMP Session-IDs [RFC8972] in a predictable manner to protect against off-path attacks. 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 specified in [RFC8972], MPLS Network Action (with In-Stack and Post-Stack Data), and the IOAM preallocated trace option [RFC9197] is available for the Tofino2 platform. It supports unidirectional and bidirectional measurement types for Hop-by-Hop delay measurements across four transit nodes using the extensions specified in this document.¶
- https://github.com/uni-tue-kn/stamp-mpls-mna-poc¶
Contact:¶
Fabian Ihle¶
University of Tuebingen¶
Germany¶
Email: fabian.ihle@uni-tuebingen.de¶
IANA is requested to allocate the following TLV from the IETF Review range of the "STAMP TLV Types" registry under the Simple Two-way Active Measurement Protocol (STAMP) TLV Types registry group:¶
| Value | Description | Reference |
|---|---|---|
| TBA1 | Reflected MPLS Header MNA Data | This document |
IANA is requested to allocate the following sub-TLV from the IETF Review range of the "STAMP Sub-TLV Types" registry under the Simple Two-way Active Measurement Protocol (STAMP) TLV Types registry group:¶
| Value | Description | TLV Used | Reference |
|---|---|---|---|
| TBA2 | MNA Header Control | Reflected Test Packet Control | This document |
Note to the RFC Editor: Please replace all occurrences of TBA1 and TBA2 with the values assigned by IANA.¶
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.¶