]> Cisco Systems, Inc.

Canada rgandhi@cisco.com

Huawei

China zhoutianran@huawei.com

China Mobile

China lizhenqiang@chinamobile.com

University of Tuebingen

Tuebingen Germany fabian.ihle@uni-tuebingen.de

IPPM Working Group 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.

The Simple Two-Way Active Measurement Protocol (STAMP) provides capabilities for the measurement of various performance metrics in IP networks without the use of a control channel to pre-signal session parameters. 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. 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 . 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 and Post-Stack MPLS Header (PSMH) for MNA as defined in . specifies Network Action Sub-Stacks (NASes) and PSMHs to carry the IOAM data fields defined in 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 , using optional STAMP extensions defined in , 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.

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 when, and only when, they appear in all capitals, as shown here.

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

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.

STAMP Reference Topology | | | S1 |=================| M1 |===================| R1 | | |<- - - - - - - - | | - - - - - - - - - | | +-------+ +-------+ Reply Test Packet +-------+ \ / T4 T3 STAMP Session-Sender STAMP Session-Reflector ]]>

defines optional extensions for STAMP. The optional extensions are added to the base STAMP test packet defined in in the form of TLVs. As specified in , 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. As specified in , 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.

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.

Example Session-Sender and Session-Reflector Test Packet with "Reflected MPLS Header MNA Data" TLVs

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

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.

As specified in Section 9.3, "Penultimate Node Responsibilities" of , and Section 6.3, "Penultimate Node Responsibilities" of , 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.

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 . 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. defines MNA extensions for NASes and PSMHs for MNA to carry the IOAM option types defined in 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 . Note that using the IOAM option type "Incremental Trace Option-Type" is not supported by .

Example STAMP Session-Sender and Session-Reflector Test Packet for IOAM with "Reflected MPLS Header MNA Data" TLV

IOAM Direct Exporting (DEX) 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.

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.

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

This document defines the "MNA Header Control" Sub-TLV (Type TBA2) for the "Reflected Test Packet Control" TLV (Type 12) introduced in . The format of "MNA Header Control" Sub-TLV is shown in 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 . 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 . 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 .

The operational considerations specified in and apply to the procedure and extensions defined in this document. In addition, the Management and Deployment Considerations specified in 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.

The security considerations specified in , , and apply to the procedure and extensions defined in this document. In addition, the security considerations specified in and 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 in a predictable manner. In order to avoid predictability, implementations can leverage a Cryptographically Secure Pseudorandom Number Generator .

Editorial note: Please remove this section prior to publication. An open-source implementation of STAMP with optional TLVs [RFC8972], MPLS Network Action (with In-Stack and Post-Stack Data), and the IOAM pre-allocated trace option for one-way and two-way measurement types for Hop-by-Hop delay measurement (for 4 transit nodes) using the extensions defined in this document is available in the Tofino2. https://github.com/uni-tue-kn/stamp-mpls-mna-poc Contact: Fabian Ihle University of Tuebingen Germany Email: fabian.ihle@uni-tuebingen.de

IANA has created the "STAMP TLV Types" registry for . 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. STAMP TLV Type

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 , from the "STAMP Sub-TLV Types" registry. Sub-TLV Type for Reflected Test Packet Control TLV

Value	Description	TLV Used	Reference
TBA2	MNA Header Control	Reflected Test Packet Control	This document

&RFC2119; &RFC8174; &RFC8762; &RFC8972; &I-D.ietf-mpls-mna-hdr; &I-D.ietf-mpls-mna-ps-hdr; &I-D.ietf-mpls-mna-ioam; &I-D.ietf-ippm-asymmetrical-pkts; &RFC9197; &RFC9326; NIST Special Publication 800-90A

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.