Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers

Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers Cisco Systems, Inc.

Canada rgandhi@cisco.com

Huawei

China zhoutianran@huawei.com

China Mobile

China lizhenqiang@chinamobile.com

University of Cincinnati

USA hawkinsw@obs.cr

IPPM Working Group 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 IP headers as well as IPv6 extension headers for HBH and E2E active measurements, for example, using 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. 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 . 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. IPv6 packets may carry IPv6 extension headers containing IPv6 options headers for Hop-By-Hop (HBH) and Destination types as defined in . The Hop-By-Hop options processing procedures are further specified in . defines option types for HBH and destination options headers to carry IOAM data fields for the IPv6 data plane. 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 using optional STAMP extensions defined in to reflect IP headers as well as IPv6 extension headers as specified in this document. The procedure defined in this document leverages the existing implementations on the midpoint nodes with IP data plane that supports the IPv6 extension headers used, 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.

ECMP: Equal Cost Multi-Path E2E: Edge-To-Edge HBH: Hop-By-Hop IOAM: In Situ Operations, Administration, and Maintenance MTU: Maximum Transmission Unit 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 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.

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. The Session-Reflector reflects all received STAMP TLVs from the Session-Sender test packets. As specified in , 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 defines a new TLV option for STAMP, called "Reflected IPv6 Extension Header Data" (value TBA1). When a STAMP Session-Sender adds an IPv6 extension header, such as an IPv6 Hop-By-Hop options header or a Destination options header in the IPv6 header , it also adds a "Reflected IPv6 Extension Header Data" STAMP TLV in the Session-Sender test packet with the length set to the IPv6 extension header length (starting from the Next Header field) and the value field in the STAMP TLV initialized to zeros, in order to receive a copy of that IPv6 extension header back in the STAMP TLV. When adding multiple IPv6 extension headers in the Session-Sender test packet, corresponding "Reflected IPv6 Extension Header Data" STAMP TLVs MUST be added, with the matching length of the IPv6 extension header and in the same order, in order to receive a copy of that IPv6 extension header. An example STAMP test packet for the IPv6 data plane carrying the IPv6 header and IPv6 extension headers and reflected IPv6 header data in STAMP TLVs, is shown in Figure 2. Examples of IPv6 extension headers include: IOAM data fields IPv6 options header defined in , Performance and Diagnostic Metrics (PDM) IPv6 options header defined in , Maximum Path MTU IPv6 options header defined in , Alternate Marking Method IPv6 options header defined in , Routing Header for IPv6 including Segment Routing Header defined in , and any new IPv6 extension header that is defined in the future. As the procedure defined in this document leverages the existing implementations on the midpoint nodes for the IPv6 extension headers, no additional requirements are specified when carrying these IPv6 extension headers in STAMP. The IPv6 extension header is processed by the nodes using the same procedures specified in the document that defined the IPv6 extension header.

Example STAMP Test Packet with Reflected IPv6 Extension Header Data STAMP TLV When the Session-Reflector receives a STAMP test packet with an IPv6 extension header and a STAMP TLV of "Reflected IPv6 Extension Header Data," the Session-Reflector that supports this STAMP TLV MUST copy the entire IPv6 extension header, into the STAMP "Reflected IPv6 Extension Header Data" TLV in the Session-Reflector payload. When there are multiple IPv6 extension headers in the received Session-Sender test packet, each IPv6 extension header MUST be processed in order, starting from the outer header, and copied into the corresponding STAMP "Reflected IPv6 Extension Header Data" TLV in the reply Session-Reflector test packet, if that STAMP TLV exists. When the Session-Reflector receives a STAMP test packet with an IPv6 extension header but without a "Reflected IPv6 Extension Header Data" STAMP TLV, the Session-Reflector does not copy the IPv6 extension header into the reply Session-Reflector test packet. When the Session-Sender test packets carry an IPv6 extension header that it does not require the Session-Reflector to reflect in the Session-Reflector test packet, it does not add the matching "Reflected IPv6 Extension Header Data" TLV in the Session-Sender test packet. If the Session-Reflector receives Session-Sender test packets with non-zero values in the first 4 bytes of the value field of the "Reflected IPv6 Extension Header Data" STAMP TLV, it MUST match the values in the corresponding IPv6 extension header (starting from the Next Header field) before copying data into the STAMP TLV. This mechanism is employed in cases of ambiguity when there are multiple IPv6 extension headers 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 IPv6 MTU after adding the Reflected Data STAMP TLVs. If necessary, Reflected Data STAMP TLVs can be removed to avoid violating the IPv6 MTU limit. If, for any reason, the Session-Reflector does not use the received "Reflected IPv6 Extension Header 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 . The Session-Reflector adds the matching IPv6 extension header in the IPv6 header of the Session-Reflector test packets in the same order for the reverse direction measurements, as described in Section 5.3. Note that the use case where the IPv6 extension header length changes in the Session-Sender test packets along the path is outside the scope of this document. Additionally, the use case where IPv6 extension headers are added or removed in the Session-Sender test packets along the path is outside the scope of this document.

This document defines a new TLV option for STAMP, called "Reflected Fixed Header Data" (value TBA2). The STAMP TLV can be used to reflect any fixed size header received in the Session-Sender test packet, including IPv4 and IPv6 headers. When a STAMP Session-Sender adds an IP header, it also adds a "Reflected Fixed Header Data" STAMP TLV in the Session-Sender test packet with the length set to the IP header length and the value field in the TLV initialized to zeros, in order to receive a copy of that IP header back in the STAMP TLV. When adding multiple IP headers in the Session-Sender test packet, multiple corresponding "Reflected Fixed Header Data" TLVs are added, each one with the matching length to the IP header and in the same order. An example STAMP test packet carrying the IP header and reflected IP header in STAMP TLVs is shown in Figure 3.

Example STAMP Test Packet with Reflected Fixed Header Data STAMP TLV When the Session-Reflector receives a STAMP test packet with a STAMP TLV of "Reflected Fixed Header Data," the Session-Reflector that supports this STAMP TLV MUST copy the IP header into the "Reflected Fixed Header Data" TLV in the Session-Reflector payload. When there are multiple IP headers in the received Session-Sender test packet, all IP headers MUST be copied into the "Reflected Fixed Header Data" TLVs in the reply Session-Reflector test packet in the same order. When the Session-Reflector receives a STAMP test packet with an IP header but without a "Reflected Fixed Header Data" STAMP TLV, the Session-Reflector does not copy the IP header into the reply Session-Reflector test packet. When the Session-Sender test packets carry an IP header that it does not require the Session-Reflector to reflect in the Session-Reflector test packet, it does not add the matching "Reflected Fixed Header Data" TLV in the Session-Sender test packet. If the Session-Reflector receives Session-Sender test packets with non-zero values in the first 4 bytes of the value field of the "Reflected Fixed Header Data" STAMP TLV, it MUST match the values in the corresponding IP header before copying data into the STAMP TLV. This mechanism is employed in case of ambiguity when there are multiple IP headers with the same length and not all need to be copied and reflected in the STAMP TLV. 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 IP MTU after adding the Reflected Data STAMP TLVs. If necessary, Reflected Data STAMP TLVs can be removed to avoid violating the IP MTU limit. If, for any reason, the Session-Reflector does not use the received "Reflected Fixed Header 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 .

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, 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. IOAM Direct Exporting (DEX) is applicable with STAMP test packets for on-path telemetry use cases . In this case, the Session-Reflector does not reflect IOAM data fields since no IOAM data is recorded in the STAMP test packets. Hence, the Session-Sender MUST NOT include a corresponding "Reflected IPv6 Extension Header Data" STAMP TLV in the Session-Sender test packets for the IOAM DEX option-type. defines types for HBH and destination options headers and is used to carry the IOAM option types defined in for the IPv6 data plane. The STAMP Session-Sender and Session-Reflector test packets carry the IPv6 options headers with IOAM option types for recording and collecting HBH and E2E operational and telemetry information for active measurement, as shown in Figure 4. The Session-Sender, midpoints, and Session-Reflector nodes 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 Test Packet with Reflected IPv6 Extension Header Data TLV

The "Reflected IPv6 Extension Header Data" STAMP TLV is carried by Session-Sender and Session-Reflector test packets. STAMP test packets may carry multiple TLVs of this type. The same "Reflected IPv6 Extension Header Data" STAMP TLV Type is used for reflecting various IPv6 extension headers, including HBH and Destination IPv6 options headers. The format of the Reflected IPv6 Extension Header Data TLV is shown in Figure 5.

Reflected IPv6 Extension Header 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 . 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 IPv6 extension header in the IPv6 header when processing in the same order.

The "Reflected Fixed Header 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 Fixed Header Data" TLV is shown in Figure 6.

Reflected Fixed Header Data STAMP TLV The TLV fields are defined as follows: Type: Type (value TBA2) 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. For an IPv4 header, the length is set to 20, and for an IPv6 header, the length is set to 40. 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 IP header when processing in the same order.

In the case of one-way HBH and E2E measurements for IPv6 data plane, the Session-Reflector does not need to add IPv6 extension headers in the reply Session-Reflector test packets matching the received IPv6 extension headers. In this document, the Sub-TLV "IPv6 Extension Header Control" (Type TBA3) is defined for the STAMP TLV Type "Reflected Test Packet Control TLV" (Type TBA-ASYM) introduced in . When a Session-Sender test packet is received with the "IPv6 Extension Header Control" Sub-TLV, the Session-Reflector does not add the received IPv6 extension headers in the IPv6 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 IPv6 extension headers matching all received IPv6 extension headers (except the routing extension headers specific to the Session-Sender test packets) in the IPv6 header of the reply Session-Reflector test packet. The IPv6 extension headers received in the Session-Sender test packets are still copied and reflected in STAMP TLVs 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 also apply when using the IPv6 options headers defined in that document.

Editorial note: Please remove this section prior to publication. An open-source implementation of the Simple Two-Way Active Measurement Protocol [RFC8762] is available in Teaparty. https://github.com/cerfcast/teaparty An implementation of the solution in this document is available at the following location: https://github.com/cerfcast/teaparty/commit/393abf9357a6c2439877d9bcf2dc426dd89c7158 The features implemented are: 1. Extraction of the extension headers from the IPv6 headers of the received STAMP test packet. 2. Reflection of the extension headers in the reflected STAMP TLV data (with checks for matching length). 3. Adding the extension headers in the IP header of the reflected STAMP test packet. 4. Support for multiple IPv6 extension headers. 5. Reflection of the fixed IPv6 header in the reflected STAMP TLV data. And there is also support for the reflected IPv6 extension header TLV data in the Wireshark dissector: https://github.com/cerfcast/teaparty/commit/fb74e2e02396e9bb3ead017e8d9a0c187e3573e2 And there is also support for tools for testing reflected IPv6 extension header TLV data: https://github.com/cerfcast/teaparty/tree/main/testing_data#testing-reflected-ipv6-extension-header-data Contact: William Hawkins University of Cincinnati Email: hawkinsw@obs.cr

IANA has created the "STAMP TLV Types" registry for . IANA is requested to allocate a value for the "Reflected IPv6 Extension Header Data" TLV Type and a value for the "Reflected Fixed Header Data" TLV Type from the IETF Review TLV range of the same registry. STAMP TLV Types

Value	Description	Reference
TBA1	Reflected IPv6 Extension Header Data	This document
TBA2	Reflected Fixed Header Data	This document

IANA is requested to allocate a value for the Sub-TLV Type "IPv6 Extension Header Control" (Type TBA3) for the STAMP TLV Type "Reflected Test Packet Control TLV" (Type TBA-ASYM) defined in , from the "STAMP Sub-TLV Types" registry. Sub-TLV Type for Reflected Test Packet Control STAMP TLV

Value	Description	TLV Used	Reference
TBA3	IPv6 Extension Header Control	Reflected Test Packet Control	This document

&RFC2119; &RFC8174; &RFC8200; &RFC8762; &RFC8972; &RFC9673; &I-D.ietf-ippm-asymmetrical-pkts; &RFC8250; &RFC8754; &RFC9197; &RFC9486; &RFC9268; &RFC9326; &RFC9343; &I-D.ietf-ippm-on-path-active-measurements;

The authors would like to thank Greg Mirsky, Xiao Min, Tal Mizrahi, Cheng Li, Giuseppe Fioccola, Richard "Footer" Foote, and Jie Dong for reviewing this document and providing many useful comments and suggestions. Thank you William Hawkins for implementing the solution defined in this document in Teaparty.