IPPM Working Group R. Gandhi, Ed. Internet-Draft Cisco Systems, Inc. Intended status: Standards Track T. Zhou Expires: 4 December 2025 Huawei Z. Li China Mobile 2 June 2025 Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet MPLS Sub-Stacks draft-gandhi-ippm-stamp-mpls-hdr-00 Abstract The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-To-Edge (E2E) active measurement. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-By- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect MPLS Network Action Sub-Stacks for HBH and E2E active measurements, for example, using IOAM data fields. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 December 2025. Copyright Notice Copyright (c) 2025 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. Gandhi, et al. Expires 4 December 2025 [Page 1] Internet-Draft STAMP for Reflecting MPLS Sub-Stacks June 2025 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.3. STAMP Reference Topology . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Use Case of Reflecting IOAM Data Fields . . . . . . . . . . . 7 5. STAMP Extensions . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Reflected MNA Sub-Stack Data STAMP TLV . . . . . . . . . 8 5.2. One-Way Measurement Using Reflected Data STAMP TLVs . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The Simple Two-Way Active Measurement Protocol (STAMP) provides capabilities for the measurement of various performance metrics in IP networks [RFC8762] without the use of a control channel to pre-signal session parameters. [RFC8972] defines optional extensions in the form of TLVs for STAMP. The STAMP test packets are transmitted along a path between a Session-Sender and a Session-Reflector to measure Edge-To-Edge (E2E) performance delay and packet loss along that path. In Situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information while the packet traverses a path between two points in the network. The IOAM data fields are defined in [RFC9197]. Currently, there is no adopted method defined to reflect the collected IOAM data fields back to the Sender, where the Sender can use that information to support the hop-by-hop and edge-to-edge measurement use cases. MPLS packets may carry MPLS Network Action (MNA) Sub-Stacks as defined in [I-D.ietf-mpls-mna-hdr] and Post-Stack Header as defined in [I-D.ietf-mpls-mna-ps-hdr]. Gandhi, et al. Expires 4 December 2025 [Page 2] Internet-Draft STAMP for Reflecting MPLS Sub-Stacks June 2025 It may be desired to record and collect HBH and E2E operational and telemetry information using active measurement packets between two nodes in a network. This is achieved by augmenting STAMP [RFC8762] using optional STAMP extensions defined in [RFC8972] to reflect MNA Sub-Stacks as specified in this document. The procedure defined in this document leverages the existing implementations on the midpoint nodes with MPLS data plane without any additional requirements. 2. Conventions Used in This Document 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2.2. Abbreviations ECMP: Equal Cost Multi-Path E2E: Edge-To-Edge HBH: Hop-By-Hop IOAM: In Situ Operations, Administration, and Maintenance MNA: Multiprotocol Label Switching Network Action MTU: Maximum Transmission Unit STAMP: Simple Two-way Active Measurement Protocol TLV: Type-Length-Value 2.3. STAMP Reference Topology In the "STAMP Reference Topology" shown in Figure 1, the STAMP Session-Sender S1 initiates a Session-Sender test packet, and the STAMP Session-Reflector R1 transmits a reply Session-Reflector test packet. Node M1 is a midpoint node that does not perform any STAMP processing. T1 is a transmit timestamp, and T4 is a receive timestamp added by node S1. T2 is a receive timestamp, and T3 is a transmit timestamp added by node R1. Gandhi, et al. Expires 4 December 2025 [Page 3] Internet-Draft STAMP for Reflecting MPLS Sub-Stacks June 2025 T1 T2 / \ +-------+ Test Packet +-------+ +-------+ | | - - - - - - - - | | - - - - - - - - ->| | | S1 |=================| M1 |===================| R1 | | |<- - - - - - - - | | - - - - - - - - - | | +-------+ +-------+ Reply Test Packet +-------+ \ / T4 T3 STAMP Session-Sender STAMP Session-Reflector Figure 1: STAMP Reference Topology 3. Overview [RFC8972] defines optional extensions for STAMP. The optional extensions are added to the base STAMP test packet defined in [RFC8762] in the form of TLVs. As specified in [RFC8972], both Session-Sender and Session-Reflector test packets are symmetric in size when including all optional TLVs. The Session-Reflector reflects all received STAMP TLVs from the Session-Sender test packets. As specified in [RFC8762], STAMP test packets are transmitted with IP/UDP headers. Since midpoint nodes do not process the UDP headers in the packets, they are agnostic to the STAMP test packets in the payload. This document also defines a new TLV option for STAMP, called "Reflected MNA Sub-Stack Data" (value TBA1). When a STAMP Session- Sender adds an MNA Sub-Stack in the test packet, it also adds a "Reflected MNA Sub-Stack Data" STAMP TLV in the Session-Sender test packet with the length set to the MNA Sub-Stack length (NASL) and the value field in the TLV initialized to zeros, in order to receive a copy of that MNA Sub-Stack back in the STAMP TLV. When adding multiple MNA Sub-Stacks in the Session-Sender test packet, multiple "Reflected MNA Sub-Stack Data" TLVs MUST be added, each one with the matching length to the MNA Sub-Stack and Ancillary Data and in the same order. As the procedure defined in this document leverages the existing implementations on the midpoint nodes for the MNA Sub-Stacks, no additional requirements are specified when carrying MNA Sub-Stacks in STAMP. The MNA Sub-Stack is processed by the nodes using the same procedures specified in the document that defined the MNA Sub-Stack. Gandhi, et al. Expires 4 December 2025 [Page 4] Internet-Draft STAMP for Reflecting MPLS Sub-Stacks June 2025 An example STAMP test packet for the MPLS data plane carrying MNA Sub-Stacks in the MPLS header and reflected MNA Sub-Stack data in STAMP TLVs is shown in Figure 2. +------------------------------------------------+ | MPLS Header | +------------------------------------------------+ | MNA Sub-Stack-1 I-D.ietf-mpls-mna-hdr | ~ ~ +------------------------------------------------+ ~ ... ~ +------------------------------------------------+ | MNA Sub-Stack-N I-D.ietf-mpls-mna-hdr | ~ ~ +------------------------------------------------+ ~ ... ~ +------------------------------------------------+ | MNA Post-Stack Header I-D.ietf-mpls-mna-ps-hdr | ~ ~ +------------------------------------------------+ | IP Header | +------------------------------------------------+ | UDP Header | +------------------------------------------------+ | STAMP Packet RFC 8972 | +------------------------------------------------+ | Reflected MNA Sub-Stack-1 Data STAMP TLV (TBA1)| ~ ~ +------------------------------------------------+ ~ ... ~ +------------------------------------------------+ | Reflected MNA Sub-Stack-M Data STAMP TLV (TBA1)| ~ ~ +------------------------------------------------+ | Reflected MNA Post-Stack Data STAMP TLV (TBA1) | ~ ~ +------------------------------------------------+ Figure 2: Example STAMP Test Packet with Reflected MNA Sub-Stack Data STAMP TLV Gandhi, et al. Expires 4 December 2025 [Page 5] Internet-Draft STAMP for Reflecting MPLS Sub-Stacks June 2025 When the Session-Reflector receives a STAMP test packet with an MNA and a STAMP TLV of "Reflected MNA Sub-Stack Data," the Session- Reflector that supports this STAMP TLV MUST copy the entire MNA Sub- Stack, including the Ancillary Data and header, into the "Reflected MNA Sub-Stack Data" TLV in the Session-Reflector payload. When there are multiple MNA Sub-Stacks in the Session-Sender test packet, all MNA Sub-Stacks, including Ancillary Data, MUST be copied in the STAMP TLVs and MUST add all MNA Sub-Stacks, including Ancillary Data, in the Session-Reflector test packet in the same order. The Session-Reflector adds the matching MNA Sub-Stacks and Ancillary Data in the MPLS header of the Session-Reflector test packet for the reverse direction. When the Session-Reflector receives a STAMP test packet with an MNA Sub-Stack but without a "Reflected MNA Sub-Stack Data" STAMP TLV, the Session-Reflector does not copy the MNA Sub-Stack into the Session- Reflector test packet. When the Session-Sender test packets carry an MNA Sub-Stack that it does not require the Session-Reflector to reflect in the Session- Reflector test packet, it does not add the matching Reflected MNA Sub-Stack Data TLV in the Session-Sender test packet. If the Session-Reflector receives Session-Sender test packets with non-zero values in the first 8 bytes (excluding the Ancillary Data field that may change) of the "Reflected MNA Sub-Stack Data" STAMP TLV, it MUST match the values in the corresponding MNA Sub-Stack in the MPLS header before copying data into the STAMP TLV. This mechanism is employed in case of ambiguity when there are multiple MNA Sub-Stacks in the MPLS header 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 MPLS MTU after adding the Reflected Data STAMP TLVs. If necessary, Reflected Data STAMP TLVs can be removed to avoid violating the MPLS MTU limit. If, for any reason, the Session-Reflector does not use the received Reflected MNA Sub-Stack Data STAMP TLV for reflecting data, it MUST return the STAMP TLV as malformed, i.e., with the U flag (Unrecognized) set in the STAMP TLV Flags using the procedure defined in [RFC8972]. Gandhi, et al. Expires 4 December 2025 [Page 6] Internet-Draft STAMP for Reflecting MPLS Sub-Stacks June 2025 Note that the use case where the MNA Sub-Stack length changes in the Session-Sender test packets along the path is outside the scope of this document. Also, the use case where MNA Sub-Stacks are added or removed in the Session-Sender test packets along the path is outside the scope of this document. 4. Use Case of Reflecting IOAM Data Fields In Situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information while the packet traverses a path between two points in the network. The IOAM data fields are defined in [RFC9197]. Examples of data recorded by IOAM Trace Options include per-hop information, such as node ID, timestamp, queue depth, interface ID, interface load, etc. The information collected can be used for monitoring ECMP paths, proof-of-transit, and troubleshooting failures in the network. IOAM can be used with STAMP test packets for active measurement. The procedure and STAMP extensions defined in this document can be used to reflect the collected IOAM data fields back to the Sender, where the Sender can use that information to support the hop-by-hop and edge-to-edge measurement use cases. [I-D.ietf-mpls-mna-hdr] defines the MNA Sub-Stack to carry various Network Actions with Ancillary data. [I-D.ietf-mpls-mna-ioam] defines extensions using MNA to carry IOAM data that may be carried in In-Stack Data [I-D.ietf-mpls-mna-hdr] or Post-Stack Header [I-D.ietf-mpls-mna-ps-hdr]. The STAMP Session-Sender and Session- Reflector test packets carry the MNA Sub-Stack for HBH and E2E operational and telemetry information for active measurement, as shown in Figure 3. +------------------------------------------------+ | MPLS Header | +------------------------------------------------+ | HBH IOAM RFC 9197 | ~ MNA Sub-Stack I-D.ietf-mpls-mna-hdr ~ ~ MNA Post-Stack Header I-D.ietf-mpls-mna-ps-hdr ~ +------------------------------------------------+ | IP Header | +------------------------------------------------+ | UDP Header | +------------------------------------------------+ | STAMP Packet RFC 8972 | +------------------------------------------------+ | Reflected MNA Sub-Stack Data STAMP TLV (TBA1) | ~ ~ +------------------------------------------------+ Gandhi, et al. Expires 4 December 2025 [Page 7] Internet-Draft STAMP for Reflecting MPLS Sub-Stacks June 2025 Figure 3: Example STAMP Test Packet with Reflected MNA Sub-Stack Data TLV 5. STAMP Extensions 5.1. Reflected MNA Sub-Stack Data STAMP TLV The "Reflected MNA Sub-Stack 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 MNA Sub-Stack 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reflected MNA Sub-Stack Data | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Reflected MNA Sub-Stack Data STAMP TLV The TLV fields are defined as follows: Type: Type (value TBA1) STAMP TLV Flags: The STAMP TLV Flags follow the procedures described in [RFC8972]. Length: A two-octet field equal to the length of the Data in octets. The Session-Reflector MUST return an error in the STAMP TLV Flags when it determines that the length of the TLV does not match the length of the corresponding MNA Sub-Stack when processing in the same order as the MNA Sub-Stacks in the MPLS header. 5.2. One-Way Measurement Using Reflected Data STAMP TLVs Similarly, in the case of one-way HBH and E2E measurements for MPLS data plane, the Session-Reflector does not need to add MNA Sub-Stacks in the reply Session-Reflector test packets matching the received MNA Sub-Stacks. In this document, the Sub-TLV "MNA Sub-Stack Control" (Type TBA2) is defined for the STAMP TLV Type "Reflected Test Packet Control TLV" (Type TBA-ASYM) introduced in [I-D.ietf-ippm-asymmetrical-pkts]. Gandhi, et al. Expires 4 December 2025 [Page 8] Internet-Draft STAMP for Reflecting MPLS Sub-Stacks June 2025 When a Session-Sender test packet is received with the "MNA Sub-Stack Control" Sub-TLV, the Session-Reflector does not add the received MNA Sub-Stacks in the MPLS header of the reply Session-Reflector STAMP test packet. In the absence of this Sub-TLV in the received Session-Sender test packet, the Session-Reflector inserts new MNA Sub-Stacks matching all received MNA Sub-Stacks in the MPLS header of the reply Session- Reflector test packet. The MNA Sub-Stacks received in the Session-Sender test packets are still reflected in STAMP TLVs to the Session-Sender. 6. Security Considerations The security considerations specified in [RFC8762], [RFC8972], [I-D.ietf-mpls-mna-hdr] and [I-D.ietf-mpls-mna-ps-hdr] apply to the procedure and extensions defined in this document. In addition, the security considerations specified in [RFC9197] and [I-D.ietf-mpls-mna-ioam] also apply when using the IOAM. 7. IANA Considerations IANA has created the "STAMP TLV Types" registry for [RFC8972]. IANA is requested to allocate a value for the "Reflected MNA Sub-Stack Data" TLV Type from the IETF Review TLV range of the same registry. +=======+==============================+===============+ | Value | Description | Reference | +=======+==============================+===============+ | TBA1 | Reflected MNA Sub-Stack Data | This document | +-------+------------------------------+---------------+ Table 1: STAMP TLV Types IANA is requested to allocate values for the Sub-TLV Type "MNA Sub- Stack Control" (Type TBA2) for the STAMP TLV Type "Reflected Test Packet Control TLV" (Type TBA-ASYM) defined in [I-D.ietf-ippm-asymmetrical-pkts]. +=======+=======================+===============+ | Value | Description | Reference | +=======+=======================+===============+ | TBA2 | MNA Sub-Stack Control | This document | +-------+-----------------------+---------------+ Table 2: Sub-TLV Types for Reflected Test Packet Control STAMP TLV Gandhi, et al. Expires 4 December 2025 [Page 9] Internet-Draft STAMP for Reflecting MPLS Sub-Stacks June 2025 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, . [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, "Simple Two-Way Active Measurement Protocol Optional Extensions", RFC 8972, DOI 10.17487/RFC8972, January 2021, . [I-D.ietf-mpls-mna-hdr] Rajamanickam, J., Gandhi, R., Zigler, R., Song, H., and K. Kompella, "MPLS Network Action (MNA) Sub-Stack Solution", Work in Progress, Internet-Draft, draft-ietf-mpls-mna-hdr- 12, 3 March 2025, . [I-D.ietf-mpls-mna-ps-hdr] Rajamanickam, J., Gandhi, R., Zigler, R., Li, T., and J. Dong, "Post-Stack MPLS Network Action (MNA) Solution", Work in Progress, Internet-Draft, draft-ietf-mpls-mna-ps- hdr-01, 30 May 2025, . [I-D.ietf-mpls-mna-ioam] Gandhi, R., Mirsky, G., Li, T., Song, H., and B. Wen, "Supporting In Situ Operations, Administration and Maintenance Using MPLS Network Actions", Work in Progress, Internet-Draft, draft-ietf-mpls-mna-ioam-03, 30 May 2025, . Gandhi, et al. Expires 4 December 2025 [Page 10] Internet-Draft STAMP for Reflecting MPLS Sub-Stacks June 2025 [I-D.ietf-ippm-asymmetrical-pkts] Mirsky, G., Ruffini, E., Nydell, H., Foote, R. F., and W. Hawkins, "Performance Measurement with Asymmetrical Traffic Using STAMP", Work in Progress, Internet-Draft, draft-ietf-ippm-asymmetrical-pkts-07, 5 May 2025, . 8.2. Informative References [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . Acknowledgments TBA Authors' Addresses Rakesh Gandhi (editor) Cisco Systems, Inc. Canada Email: rgandhi@cisco.com Tianran Zhou Huawei China Email: zhoutianran@huawei.com Zhenqiang Li China Mobile China Email: lizhenqiang@chinamobile.com Gandhi, et al. Expires 4 December 2025 [Page 11]