MPLS Working Group R. Gandhi, Ed. Internet-Draft P. Brissette Updates: 8762, 8972 (if approved) Cisco Systems, Inc. Intended status: Standards Track E. Leyton Expires: 8 March 2027 Verizon Wireless X. Min ZTE Corp. 4 September 2026 Encapsulation of Simple Two-Way Active Measurement Protocol for LSPs and Pseudowires in MPLS Networks draft-ietf-mpls-stamp-pw-18 Abstract This document specifies encapsulations for the Simple Two-Way Active Measurement Protocol (STAMP), defined in RFC 8762, and its optional extensions, defined in RFC 8972, in MPLS networks. It specifies the encapsulation of STAMP test packets for point-to-point Label Switched Paths (LSPs) and point-to-point single-segment Pseudowires (PWs), with or without an IP/UDP header, so that the test packets experience the same forwarding and Equal-Cost Multi-Path (ECMP) behavior as the data traffic being measured. In addition, two new MPLS Generic Associated Channel (G-ACh) types are defined. This document updates RFC 8762 and RFC 8972 to allow STAMP to operate without an IP/UDP header when STAMP test packets are carried over MPLS LSPs and PWs, and specifies the resulting changes to the processing of the STAMP session identifier, the TTL and IPv6 Hop Limit, and the STAMP TLV extensions. This document specifies the requirements for IPv6 STAMP in unauthenticated mode using UDP zero-checksum, which deviates from the integrity requirement in RFC 6936. 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/. Gandhi, et al. Expires 8 March 2027 [Page 1] Internet-Draft STAMP in MPLS Networks September 2026 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 8 March 2027. Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Examples of MPLS Data Traffic Use Cases . . . . . . . . . 6 2. Conventions Used in This Document . . . . . . . . . . . . . . 7 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 7 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 2.3. STAMP Reference Topology . . . . . . . . . . . . . . . . 8 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. IP/UDP Header . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Formats and G-ACh Types for STAMP . . . . . . . . . . . . 10 3.2.1. STAMP Applicability to Format-2 (without IP/UDP Header) . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. STAMP Session Identifier for LSPs and PWs . . . . . . . . 11 4. Processing STAMP for LSPs and PWs . . . . . . . . . . . . . . 12 4.1. Encapsulation Use Cases . . . . . . . . . . . . . . . . . 12 4.2. Control Channel Types for PWs . . . . . . . . . . . . . . 13 4.2.1. STAMP Test Packet Exception and Identification . . . 14 4.2.2. Applicability of Control Channel Types to STAMP . . . 15 4.3. TTL and IPv6 Hop Limit Processing . . . . . . . . . . . . 15 4.4. UDP Checksum Handling . . . . . . . . . . . . . . . . . . 17 4.4.1. IPv4 UDP Zero-Checksum . . . . . . . . . . . . . . . 17 4.4.2. IPv6 UDP Zero-Checksum . . . . . . . . . . . . . . . 17 5. Session-Sender Test Packet . . . . . . . . . . . . . . . . . 19 5.1. Session-Sender Test Packet with IP/UDP Header in Format-1 . . . . . . . . . . . . . . . . . . . . . . . . 20 Gandhi, et al. Expires 8 March 2027 [Page 2] Internet-Draft STAMP in MPLS Networks September 2026 5.2. Session-Sender Test Packet without IP/UDP Header in Format-2 . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Session-Reflector Test Packet . . . . . . . . . . . . . . . . 24 6.1. Session-Reflector Test Packet with IP/UDP Header in Format-1 . . . . . . . . . . . . . . . . . . . . . . . . 25 6.2. Session-Reflector Test Packet without IP/UDP Header in Format-2 . . . . . . . . . . . . . . . . . . . . . . . . 27 7. Operational Considerations . . . . . . . . . . . . . . . . . 29 7.1. ECMP Considerations . . . . . . . . . . . . . . . . . . . 29 7.2. STAMP Session State Notification . . . . . . . . . . . . 30 7.3. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 31 7.4. Congestion Considerations . . . . . . . . . . . . . . . . 31 7.5. MTU Requirements . . . . . . . . . . . . . . . . . . . . 32 7.6. Considerations for Broken LSPs . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 10.2. Informative References . . . . . . . . . . . . . . . . . 38 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 1. Introduction The Simple Two-Way Active Measurement Protocol (STAMP) provides capabilities for measuring various metrics in IP networks [RFC8762] without the use of a control channel to pre-signal session parameters. [RFC8972] defines optional extensions to STAMP. Label Switched Paths (LSPs) are used in MPLS networks for various services, including forwarding Layer 2 and Layer 3 data packets. LSPs can be point-to-point or point-to-multipoint. STAMP encapsulations for point-to-multipoint LSPs are outside the scope of this document. This document specifies STAMP encapsulations for point-to-point LSPs. Pseudowires (PWs) are used in MPLS networks for various services, including forwarding Layer 2 and Layer 3 data packets [RFC6658]. PWs are bidirectional in nature. PWs may use the Control Word (CW) as defined in Section 3 of [RFC4385]. This document covers STAMP encapsulations for point-to-point PWs; point-to-multipoint PWs are outside the scope of this document. PWs can be single-segment PWs or multi-segment PWs. This document specifies STAMP encapsulations for single-segment PWs; multi-segment PWs are outside the scope of this document. Gandhi, et al. Expires 8 March 2027 [Page 3] Internet-Draft STAMP in MPLS Networks September 2026 MPLS Transport Profile (MPLS-TP) [RFC5960] is designed to use the MPLS data plane without any changes. Therefore, when STAMP is specified over the MPLS data plane, it is equally applicable to MPLS- TP networks. As specified in Section 2 of [RFC5921], "OAM and protection mechanisms, and forwarding of data packets, must be able to operate without IP forwarding support." As described in Section 3.4.5 of [RFC5921], MPLS-TP LSPs and PWs may carry traffic from the attachment circuits that may be heterogeneous (e.g., any combination of SDH, PPP, Frame Relay, etc.). A Generic Associated Channel (G-ACh), as defined in [RFC5586], provides a mechanism for carrying Operations, Administration, and Maintenance (OAM) and other control messages over the MPLS data plane. The G-ACh type identifies the specific OAM message carried over the channel. Virtual Circuit Connectivity Verification (VCCV) is used as a control channel for PWs as specified in [RFC5085]. A G-ACh label (GAL) can be used as a VCCV Control Channel as specified in [RFC7708]. This document specifies the encapsulation and termination procedures for STAMP and its optional extensions for LSPs and PWs in MPLS networks. This document also specifies the encapsulation and termination procedures for STAMP test packets with or without the CW and/or an IP/UDP header for LSPs and PWs. When STAMP is used for MPLS and MPLS-TP on both LSPs and PWs, there are unique aspects, such as test packet encapsulation, test packet termination, and ECMP behavior, that need to be considered with respect to the use of the CW, and these aspects are addressed in this document. This document uses the mechanisms defined in [RFC5085] and [RFC7708] to terminate STAMP test packets on the Session-Sender and the Session-Reflector for control-plane processing for both LSPs and PWs. * The mechanism applied to terminate the STAMP test packet for an LSP or a PW is locally provisioned on both ends of the STAMP session for the LSP or PW. * The signaling extensions for the VCCV Control Channel for STAMP on PWs are outside the scope of this document. * The VCCV Control Channel signaling has only been specified for PWs, not for LSPs; therefore, local provisioning of the mechanism for an LSP is the only viable option at present. Gandhi, et al. Expires 8 March 2027 [Page 4] Internet-Draft STAMP in MPLS Networks September 2026 This document uses the existing G-ACh types "Associated Channel carries an IPv4 packet" and "Associated Channel carries an IPv6 packet" when STAMP test packets are transmitted with an IP/UDP header for LSPs and PWs. In addition, this document defines two new G-ACh types when STAMP test packets are transmitted without an IP/UDP header. Additional considerations for encapsulating STAMP for performance measurement of Segment Routing LSPs over the MPLS data plane are described in [I-D.ietf-spring-stamp-srpm-mpls], and are outside the scope of this document. This document updates [RFC8762] and [RFC8972] to allow STAMP to operate without an IP/UDP header when STAMP test packets are carried over MPLS LSPs and PWs, and specifies the resulting changes to the processing of the STAMP session identifier, the TTL and IPv6 Hop Limit, and the STAMP TLV extensions. This document specifies the requirements for IPv6 STAMP in unauthenticated mode using UDP zero-checksum, which deviates from the integrity requirement in [RFC6936]. 1.1. Requirements STAMP test packets need to be transmitted with the same label stack as the LSP and PW data traffic to ensure proper validation of the underlay path taken by the actual data traffic. In addition, STAMP test packets need to consider the underlay path taken by the LSP and PW data traffic in the network. PW data traffic may be encapsulated with the CW, as defined in Section 3 of [RFC4385], and an IP header. As such, STAMP test packets need to be transmitted over these PWs using a G-ACh and an IP/UDP header. When a STAMP test packet is transmitted to the target IP address of a STAMP Session-Reflector, it is encapsulated for an MPLS LSP by the data plane based on the reachability of that IP address over the LSP. Hence, STAMP test packets are treated the same as the data traffic forwarded over the LSP by the transit nodes along the path. Private Line Emulation (PLE) [RFC9801] traffic is sent over a Packet Switched Network (PSN) as a Virtual Private Wire Service (VPWS) using PWs. The data packets are encapsulated with the PLE CW, but they do not carry any IP header. As such, STAMP test packets need to be transmitted using the same label stack, including the VPWS PW label as the PLE traffic [RFC9801], and encapsulated using a G-ACh but without an IP/UDP header. This allows STAMP test packets to experience the same forwarding behavior, follow the same underlay path as the PLE traffic. Gandhi, et al. Expires 8 March 2027 [Page 5] Internet-Draft STAMP in MPLS Networks September 2026 The G-ACh provides support for the OAM control channel associated with MPLS-TP [RFC5960] LSPs and PWs. The OAM control channel for MPLS-TP needs to be extended to encapsulate STAMP test packets using the G-ACh types. This extension is similar to the G-ACh types defined for delay and loss measurement packets in [RFC6374]. The encapsulation requirements for STAMP test packets transmitted on the LSPs and PWs in MPLS networks can be summarized as follows: * The G-ACh needs to support STAMP test packets with an IP/UDP header. * The G-ACh needs to support STAMP test packets without an IP/UDP header. * The G-ACh types need to support demultiplexing of the control channel for STAMP test packets. * Session-Sender test packets need to follow the underlay path taken by the data traffic that uses the CW. * Session-Sender test packets need to follow the same underlay path as the data traffic that uses the CW and an Entropy Label defined in [RFC6790]. * Session-Sender test packets need to follow the same underlay path as the data traffic that uses the CW but does not use an Entropy Label defined in [RFC6790]. * Session-Reflector test packets can follow the reverse underlay path taken by Session-Sender test packets. * Session-Reflector test packets can follow the same reverse underlay path as the Session-Sender test packets. 1.2. Examples of MPLS Data Traffic Use Cases Examples of MPLS data traffic use cases for STAMP test packets with IP/UDP headers are: 1. MPLS PW Data Traffic (with CW and IP header) 2. MPLS-TP PW Data Traffic (with CW and IP header) 3. MPLS LSP Data Traffic (with IP header) Examples of MPLS data traffic use cases for STAMP test packets without IP/UDP headers are: Gandhi, et al. Expires 8 March 2027 [Page 6] Internet-Draft STAMP in MPLS Networks September 2026 1. MPLS Ethernet PW Data Traffic [RFC4448] 2. PLE [RFC9801] PW Data Traffic 3. TDM over IP [RFC5087] PW Data Traffic (with no IP header) 4. MPLS-TP LSP Data Traffic 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 +==============+====================================+===========+ | Abbreviation | Meaning | Reference | +==============+====================================+===========+ | CE | Customer Edge | [RFC4026] | +--------------+------------------------------------+-----------+ | CW | Control Word | [RFC4385] | +--------------+------------------------------------+-----------+ | ECMP | Equal-Cost Multi-Path | [RFC6790] | +--------------+------------------------------------+-----------+ | ACH | Associated Channel | [RFC5586] | +--------------+------------------------------------+-----------+ | G-ACh | Generic Associated Channel | [RFC5586] | +--------------+------------------------------------+-----------+ | GAL | Generic Associated Channel Label | [RFC5586] | +--------------+------------------------------------+-----------+ | HMAC | Hashed Message Authentication Code | [RFC8762] | +--------------+------------------------------------+-----------+ | HL | Hop Limit | [RFC8200] | +--------------+------------------------------------+-----------+ | L2VPN | Layer 2 Virtual Private Network | [RFC4026] | +--------------+------------------------------------+-----------+ | L3VPN | Layer 3 Virtual Private Network | [RFC4026] | +--------------+------------------------------------+-----------+ | LSP | Label Switched Path | [RFC3032] | +--------------+------------------------------------+-----------+ | MPLS | Multiprotocol Label Switching | [RFC3032] | +--------------+------------------------------------+-----------+ | MPLS-TP | MPLS Transport Profile | [RFC5960] | Gandhi, et al. Expires 8 March 2027 [Page 7] Internet-Draft STAMP in MPLS Networks September 2026 +--------------+------------------------------------+-----------+ | OAM | Operations, Administration, and | [RFC5586] | | | Maintenance | | +--------------+------------------------------------+-----------+ | PE | Provider Edge | [RFC4026] | +--------------+------------------------------------+-----------+ | PFN | Post-Stack First Nibble | [RFC9790] | +--------------+------------------------------------+-----------+ | PLE | Private Line Emulation | [RFC9801] | +--------------+------------------------------------+-----------+ | PSN | Packet Switched Network | [RFC9801] | +--------------+------------------------------------+-----------+ | RA | Router Alert | [RFC5085] | +--------------+------------------------------------+-----------+ | PW | Pseudowire | [RFC6658] | +--------------+------------------------------------+-----------+ | S bit | Bottom of Stack bit | [RFC3032] | +--------------+------------------------------------+-----------+ | SSID | STAMP Session Identifier | [RFC8972] | +--------------+------------------------------------+-----------+ | STAMP | Simple Two-Way Active Measurement | [RFC8762] | | | Protocol | | +--------------+------------------------------------+-----------+ | TC | Traffic Class | [RFC5462] | +--------------+------------------------------------+-----------+ | TDM | Time-Division Multiplexing | [RFC5087] | +--------------+------------------------------------+-----------+ | TTL | Time to Live | [RFC3032] | +--------------+------------------------------------+-----------+ | VCCV | Virtual Circuit Connectivity | [RFC5085] | | | Verification | | +--------------+------------------------------------+-----------+ | VPWS | Virtual Private Wire Service | [RFC9801] | +--------------+------------------------------------+-----------+ Table 1: Abbreviations 2.3. STAMP Reference Topology In the STAMP reference topology shown in Figure 1, there is an LSP or a PW to transport data between Provider Edge (PE) endpoints S1 and R1. The STAMP Session-Sender on PE node S1 initiates a Session- Sender test packet, and the STAMP Session-Reflector on PE node R1 transmits a reply Session-Reflector test packet. The Session- Reflector test packet may be transmitted to the STAMP Session-Sender node S1 on the same path (that is, the same set of links and nodes) in the reverse direction of the path taken toward the Session- Reflector node R1. Gandhi, et al. Expires 8 March 2027 [Page 8] Internet-Draft STAMP in MPLS Networks September 2026 |<-------- Pseudowire ------->| |<-------- LSP -------------->| | | | T1 T2 | | / \ | +-------+ Test Packet +-------+ | | - - - - - - - - - ->| | | S1 |=====================| R1 | | |<- - - - - - - - - - | | +-------+ Reply Test Packet +-------+ \ / T4 T3 STAMP Session-Sender STAMP Session-Reflector Provider Edge Endpoint Provider Edge Endpoint Figure 1: STAMP Reference Topology using LSP and PW 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. The STAMP test packets are used for one-way and round-trip performance metrics, such as delay, delay variation, and packet loss [RFC8972]. 3. Overview The STAMP Session-Sender and Session-Reflector test packet payloads defined in [RFC8972] are encapsulated and transmitted over the LSPs and PWs in MPLS networks. The STAMP Session Identifier (SSID) defined in [RFC8972] is used to identify the STAMP session and MUST be set to a nonzero value. The SSID MUST be carried in STAMP test packets in both directions so that the STAMP sessions for LSPs and PWs can be identified. 3.1. IP/UDP Header The IP/UDP header specified in this section is applicable to all STAMP sessions using an IP/UDP header and is not limited to STAMP sessions for LSPs and PWs. The STAMP Session-Sender and Session-Reflector addresses for a STAMP session are provisioned on both ends of the LSP or PW. Gandhi, et al. Expires 8 March 2027 [Page 9] Internet-Draft STAMP in MPLS Networks September 2026 The base STAMP test packet payloads can be transported using a UDP header and destination UDP port number 862 as the default destination port, as specified in Section 4.1 of [RFC8762]. The source port number is chosen as follows: * The source UDP port number SHOULD be chosen using a randomized allocation method as specified in [RFC6056] to provide protection against off-path attacks, as recommended in [RFC8085]. * The source UDP port number SHOULD be chosen from the Dynamic Ports range (49152-65535) [RFC6335] to avoid conflicts with well-known and registered service ports. * The source UDP port number MUST distinguish between the received Session-Reflector test packets and the Session-Sender test packets from the reverse direction. 3.2. Formats and G-ACh Types for STAMP STAMP test packet payloads are encapsulated over a G-ACh in two formats: Format-1 (with an IP/UDP header) and Format-2 (without an IP/UDP header). * Format-1 (with IP/UDP Header): - For encapsulating the STAMP test packet payloads over a G-ACh with IP/UDP headers, the channel types "Associated Channel carries an IPv4 packet" and "Associated Channel carries an IPv6 packet" [RFC4385] are used for both Session-Sender and Session- Reflector test packets. - The destination UDP port number in the Session-Sender and Session-Reflector test packets distinguishes the test packets. * Format-2 (without IP/UDP Header): - For encapsulating the STAMP test packet payloads over a G-ACh without adding IP/UDP headers, two new channel types are defined in this document: one for the Session-Sender test packets (see Section 5.2) and one for the Session-Reflector test packets (see Section 6.2). - The different channel types are required for the Session-Sender and Session-Reflector test packets because the STAMP test packets do not have a way to discriminate between them. Gandhi, et al. Expires 8 March 2027 [Page 10] Internet-Draft STAMP in MPLS Networks September 2026 3.2.1. STAMP Applicability to Format-2 (without IP/UDP Header) This document updates the procedures defined in [RFC8762] and [RFC8972] for Format-2 STAMP test packets because they do not carry IP/UDP headers. The base STAMP test packet defined in [RFC8762] and the STAMP Session Identifier defined in [RFC8972] carry no dependency on the IP or UDP header, and the integrity protection of Section 4.4 of [RFC8762] and the HMAC TLV of Section 4.8 of [RFC8972] are computed over the STAMP packet alone. These apply to Format-2 unchanged. A TLV that reports or sets a field of the IP or UDP header cannot be used with Format-2 test packets. A Session-Sender MUST NOT include such a TLV in a Format-2 test packet, and a Session-Reflector that receives one MUST set the U flag as specified in Section 4 of [RFC8972] and MUST NOT attempt to populate it. This applies to the Location TLV (Section 4.2 of [RFC8972]), the Class of Service TLV (Section 4.4 of [RFC8972]), the Destination Node Address TLV (Section 3 of [RFC9503]), and the Return Address Sub-TLVs of the Return Path TLV (Section 4 of [RFC9503]). Requirements in [RFC8762] and [RFC8972] that operate on the IP or UDP header likewise have no effect for Format-2 test packets, including the UDP header Length comparison required by Section 4 of [RFC8972] and the UDP port considerations in Section 7 of [RFC8762]. 3.3. STAMP Session Identifier for LSPs and PWs Section 3 of [RFC8972] defines the STAMP session identifier that is also applicable to [RFC8762] as follows: * "A STAMP Session is identified by the 4-tuple (source and destination IP addresses, source and destination UDP port numbers)". * "An implementation of the STAMP Session-Reflector that supports this specification MUST identify a STAMP Session using the SSID in combination with elements of the usual 4-tuple for the session". This document updates the definition of the STAMP session identifier in Section 3 of [RFC8972] for LSPs and PWs for the following reasons: * STAMP test packets in Format-1 can carry a non-routable destination IP address (see Section 5) and a random or dynamic source port number (see Section 3.1). * STAMP test packets in Format-2 do not carry an IP/UDP header. Gandhi, et al. Expires 8 March 2027 [Page 11] Internet-Draft STAMP in MPLS Networks September 2026 STAMP sessions for LSPs and PWs on the Session-Sender and the Session-Reflector MUST be identified as follows. STAMP test packets that cannot identify the associated STAMP sessions MUST be discarded as specified in Section 3 of [RFC8972]. * Format-1 (with IP/UDP Header): - The Session-Reflector address that is the source address, the destination UDP port, and the SSID in the received Session- Reflector test packets, along with the locally provisioned STAMP session parameters are used by the Session-Sender to identify a STAMP session. - The Session-Sender address that is the source address, the destination UDP port, and the SSID in the received Session- Sender test packets, along with the locally provisioned STAMP session parameters are used by the Session-Reflector to identify a STAMP session. * Format-2 (without IP/UDP Header): - The SSID along with the reverse direction LSP and PW context in the received Session-Reflector test packets, along with the locally provisioned STAMP session parameters are used by the Session-Sender to identify a STAMP session. - The SSID along with the LSP and PW context in the received Session-Sender test packets, along with the locally provisioned STAMP session parameters are used by the Session-Reflector to identify a STAMP session. 4. Processing STAMP for LSPs and PWs 4.1. Encapsulation Use Cases The following encapsulations are defined for STAMP test packets for the data traffic being measured for LSPs and PWs: * Use Case 1: STAMP for LSP data traffic with an IP header: - The STAMP test packet payloads are transported with an IP/UDP header and an MPLS header using the same label stack as the LSP. - The label stack may include the L2 or L3 VPN label for the service when carried over the LSP. Gandhi, et al. Expires 8 March 2027 [Page 12] Internet-Draft STAMP in MPLS Networks September 2026 * Use Case 2: STAMP for LSP data traffic with an IP header and the CW: - The STAMP test packet payloads are transported with an IP/UDP header, a G-ACh header and an MPLS header using the same label stack as the LSP. - The label stack may include the L2 or L3 VPN label for the service when carried over the LSP. * Use Case 3: STAMP for PW data traffic with the CW: - The STAMP test packet payloads are encapsulated with an MPLS header using the same label stack as the PW, including the PW label, and a G-ACh header. * Additional IP-version considerations: - When using an IP header, the IP version (IPv4 or IPv6) in the STAMP test packets MUST match the IP version of the data traffic carried by the LSPs and PWs being measured. When an LSP carries both IPv4 and IPv6 data traffic, the IP version used in the STAMP test packet MUST match the IP version of the specific data traffic flow being measured. 4.2. Control Channel Types for PWs The OAM Control Channel traffic between two PE endpoints is not forwarded beyond the PE endpoints toward Customer Edge (CE) devices; instead, the OAM messages are intercepted at the PE endpoints for exception processing in the control plane. [RFC5085] and [RFC7708] define mechanisms for the Control Channel to terminate OAM messages for PWs. 1. Type 1: "PWE3 Control Word with 0001b as first nibble (PW-ACH)", defined in Section 5.1.1 of [RFC5085] MUST be added when measuring PWs with the CW. 2. Type 2: "MPLS Router Alert Label" defined in Section 5.1.2 of [RFC5085] allows the termination of OAM messages on the remote PE endpoint nodes by adding the Router Alert (RA) Label [RFC3032] immediately above the PW label. 3. Type 3: "MPLS PW Label with TTL == 1" defined in Section 5.1.3 of [RFC5085] allows the termination of OAM messages on the remote PE endpoint nodes by forcing them to be terminated on the remote PE endpoints. Gandhi, et al. Expires 8 March 2027 [Page 13] Internet-Draft STAMP in MPLS Networks September 2026 4. Type 4: "GAL" defined in [RFC7708] allows the termination of OAM messages on the remote PE endpoint nodes by adding the GAL at the bottom of the label stack. As specified in Section 3 of [RFC7708], when the PW CW is not used, the Type 4 MAY be used. As specified in Section 6 of [RFC7708], Type 1 and Type 4 are mutually exclusive for PWs. As specified in Section 4.2 of [RFC5586], the GAL MUST NOT be used with PWs in MPLS-TP networks. Therefore, the GAL encapsulation for STAMP does not apply to MPLS-TP PWs. 4.2.1. STAMP Test Packet Exception and Identification [RFC5085] and [RFC7708] define mechanisms by which an OAM message carried on a PW is excepted from the forwarding path at the PE endpoints and delivered to the control plane for processing. This document applies those mechanisms to STAMP test packets. Exactly one of them is in effect for a given STAMP session, provisioned as described in Section 1. The ECMP considerations for these mechanisms are specified in Section 7.1. Two distinct functions are involved, and this document uses both: * Exception: Types 3 and 4 except the test packet from the forwarding path without reference to its payload. Type 3 uses a TTL of 1 in the ultimate label, which Section 2.1 of [RFC3032] requires not to be forwarded further. Type 4 uses the GAL, which Section 4.2 of [RFC5586] requires not to be forwarded on. Type 1 is a base MPLS behaviour and apply irrespective of which label carries it. * Identification: Once excepted, the test packet is identified by the G-ACh header following the label stack: the Channel Type indicates whether an IP/UDP header and a STAMP payload follow (Format-1) or a STAMP payload alone (Format-2). Where a GAL is present, Section 4.2 of [RFC5586] requires it to be followed by an G-ACh. For a PW, the PW label supplies the context in which the Post-Stack First Nibble (PFN) is interpreted, as described in Section 3 of [RFC9790]. As specified in [RFC9570], use of RA has been retired for MPLS OAM due to security vulnerability reasons specified in [RFC6398] and MUST NOT be used for STAMP. Hence, Type 2 that uses RA is not considered by the procedure specified for STAMP in this document. Gandhi, et al. Expires 8 March 2027 [Page 14] Internet-Draft STAMP in MPLS Networks September 2026 Type 1 is the exception to that separation: there the PFN is itself the means by which the egress PE excepts the packet from the forwarding path, so it must be unambiguous with respect to user traffic. Type 1 therefore applies only to PWs that use the Control Word, in whose encapsulation the PFN of user packets is 0x0. This is the requirement in Section 2.1 of [RFC5586] and Section 7 of [RFC4385], and the reason Section 5.1.1 of [RFC5085] limits Type 1 to PW types that employ the Control Word. For a PW that does not use the Control Word, one of Types 3 or 4 MUST be in effect, because the PFN alone cannot except a test packet from the forwarding path on such a PW. Section 5.1.2 of [RFC5085] and Section 5.1.3 of [RFC5085] permit Type 3 whether or not the Control Word is present, and Section 3 of [RFC7708] permits Type 4. 4.2.2. Applicability of Control Channel Types to STAMP The Control Channel types defined in [RFC5085] and [RFC7708] are applied to terminate STAMP test packets as shown in Table 2. The G-ACh Channel Type is determined by the STAMP header format and is independent of the control channel type in effect. The control channel types 1, 3, and 4 are applicable to both formats, subject to the Control Word condition on Type 1 and to the MPLS-TP PW restriction on Type 4 specified in Section 4.2 above. +===============+========================================+=========+ | STAMP Header | G-ACh Channel | Control | | Format | | Channel | +===============+========================================+=========+ | Format-1 (IP/ | Associated Channel carries an IPv4 | Types | | UDP headers) | packet (0x0021) and Associated Channel | 1, 3, 4 | | | carries an IPv6 packet (0x0057) | | +---------------+----------------------------------------+---------+ | Format-2 (no | STAMP Session-Sender G-ACh (TBA1) and | Types | | IP/UDP | STAMP Session-Reflector G-ACh (TBA2) | 1, 3, 4 | | headers) | | | +---------------+----------------------------------------+---------+ Table 2: STAMP Header Format and G-ACh Channel Type 4.3. TTL and IPv6 Hop Limit Processing The TTL and IPv6 HL processing for the Session-Reflector is specified in Section 4.3 of [RFC8762] as follows: * The Session-Sender TTL field is one octet long, and its value is a copy of the TTL field in IPv4 (or HL in IPv6) from the received STAMP test packet. Gandhi, et al. Expires 8 March 2027 [Page 15] Internet-Draft STAMP in MPLS Networks September 2026 Both the Session-Sender and the Session-Reflector MUST NOT discard the received Session-Sender STAMP test packets when the TTL or IPv6 HL is not 255. This document updates the TTL and IPv6 HL processing specified in [RFC8762] for received Session-Sender STAMP test packets, processed in the following order: 1. When a Session-Sender STAMP test packet is received with an MPLS header at the Session-Reflector (in both Format-1 and Format-2), the Session-Sender TTL field on the Session-Reflector STAMP test packet is set to the TTL value in the topmost MPLS label stack entry of the received packet. 2. Follow the TTL and IPv6 HL processing for the Session-Reflector as specified in Section 4.3 of [RFC8762]. The following rules apply to the TTL and IPv6 HL fields in the STAMP test packets transmitted by both the Session-Sender and the Session- Reflector: * The IPv4 TTL and IPv6 HL MUST be set to 255 in both Session-Sender and Session-Reflector test packets as that allows to determine the number of hops that IP-forwarded the test packet (for example, when penultimate hop of an LSP removes the MPLS header). The received Session-Sender TTL in the STAMP packet allows Session- Sender to verify it against expected TTL. * The non-ultimate MPLS label TTL MUST be set to 255 in both Session-Sender and Session-Reflector test packets. The non- ultimate MPLS label TTL MUST be set to 255 in both Session-Sender and Session-Reflector test packets. The exception is that the TTL in the ultimate PW label or ultimate LSP label is set to 1 when using "MPLS PW Label with TTL == 1" (Type 3) (see Section 4.2) in both Session-Sender and Session-Reflector test packets. The TTL values in the label stack of a STAMP test packet are set as specified above and are not derived from one another. The Uniform Model TTL derivation in Section 3.6 of [RFC3443] does not apply: a test packet is originated by the Session-Sender rather than transiting the LSP or PW, and the header immediately following the label stack is an ACH, which is neither a label stack entry nor an IP packet. Label TTLs are set independently, as in the Pipe and Short Pipe Models of [RFC3443]. Gandhi, et al. Expires 8 March 2027 [Page 16] Internet-Draft STAMP in MPLS Networks September 2026 4.4. UDP Checksum Handling The UDP checksum handling specified in this section is applicable to all STAMP sessions using IPv4/UDP and IPv6/UDP and is not limited to STAMP sessions for LSPs and PWs. As specified in [RFC8085], the UDP checksum provides a statistical guarantee that the payload was not corrupted in transit, truncated, or padded. The following example limitations for STAMP timestamping necessitate the exceptions to permit the use of UDP zero-checksum for IPv4 and IPv6. * When the local processor cannot recompute the UDP checksum after adding the timestamp in the STAMP test packet. * When the local processor cannot add a checksum complement [RFC7820] after adding the timestamp in the STAMP test packet. 4.4.1. IPv4 UDP Zero-Checksum Use of the UDP checksum with IPv4 MUST be the default configuration for all implementations. For IPv4, [RFC768] permits an option to disable UDP checksum processing by setting the checksum value to zero. For IPv4 STAMP test packets, the Session-Sender and Session-Reflector can use this exception for the UDP ports specifically used in STAMP sessions to set the UDP checksum value to 0 with additional checks on the source and destination addresses in the STAMP test packets. 4.4.2. IPv6 UDP Zero-Checksum STAMP test packets are the innermost payload and are not a tunnel encapsulation. This document applies the exception in Section 8.1 of [RFC8200] to IPv6 STAMP even though STAMP is not a tunnel protocol, because the STAMP payload is the innermost protocol payload and has no inner packet whose integrity would be protected by a UDP checksum. The UDP zero-checksum requirements of [RFC6936] therefore apply directly to the STAMP payload rather than to a tunnel encapsulation carrying an inner packet. For IPv6, any node that implements UDP zero-checksum mode MUST follow the requirements specified in [RFC6936] and [RFC8085] as described below, with one deviation. Gandhi, et al. Expires 8 March 2027 [Page 17] Internet-Draft STAMP in MPLS Networks September 2026 * In this specification, the use of UDP zero-checksum for IPv6 STAMP in unauthenticated mode deviates from requirement 5 in Section 5 of [RFC6936]. * Requirement 5 of Section 5 of [RFC6936] cannot be satisfied because STAMP is not a tunnel protocol and does not include an inner packet with a CRC or other mechanism for checking packet integrity in unauthenticated mode. * This deviation from [RFC6936] requirement is limited to the IPv6 STAMP sessions in unauthenticated mode that MUST operate under the constraints listed below. IPv6 UDP zero-checksum can be enabled only when the following requirements, recommendations, and constraints are satisfied and the residual risk due to STAMP test packet corruption is acceptable. 1. UDP zero-checksum is enabled only for the specific UDP port or port range used by a STAMP session, at both the Session-Sender and Session-Reflector. This corresponds to requirement 1 in Section 5 of [RFC6936]. 2. STAMP test packets in authenticated mode, as defined in Figures Section 3 of [RFC8972] and Section 4 of [RFC8972], are RECOMMENDED in networks where packet integrity is required. This corresponds to requirement 2 in Section 5 of [RFC6936]. 3. Requirement 3 in Section 5 of [RFC6936] does not apply to STAMP because STAMP packets are not tunnel payloads and do not rely on an inner packet integrity check. 4. UDP zero-checksum is handled in STAMP so that corruption of header information is detected in STAMP and does not result in accumulation of incorrect state for the protocol. This corresponds to requirement 4 in Section 5 of [RFC6936]. 5. Requirements 6 and 7 in Section 5 of [RFC6936] are not applicable to STAMP as they are related to the keep alive messages. 6. Middleboxes within the controlled domain that process the IPv6 STAMP test packets MUST comply with Requirements 8 through 10 of Section 5 of [RFC6936]. Gandhi, et al. Expires 8 March 2027 [Page 18] Internet-Draft STAMP in MPLS Networks September 2026 Additional specific guidance from Section 3.4.1 of [RFC8085] applied to IPv6 STAMP test packets that use UDP zero-checksum is summarized below: 1. Use of the UDP checksum with IPv6 MUST be the default configuration for all implementations. This corresponds to the first requirement in Section 3.4.1 of [RFC8085]. 2. The receiving endpoint MUST verify a non-zero UDP checksum packet and MUST discard it if checksum verification fails; it MUST NOT treat the packet as a valid measurement result. This corresponds to the second requirement in Section 3.4.1 of [RFC8085] and also applies to Section 4 of [RFC6936] and Section 5 of [RFC6936]. 3. The receiving endpoint MUST only permit the use of UDP zero- checksum for IPv6 on a UDP destination port number that is specifically enabled for STAMP and MUST check that the source and destination IPv6 addresses are valid and discard any packet for which this check fails. This corresponds to the third requirement in Section 3.4.1 of [RFC8085]. 4. STAMP sessions are restricted to networks under a single administrative domain (see Section 7), where the operator is willing to take the risk of STAMP test packet corruption affecting measurements when using UDP zero-checksum. This corresponds to the fourth requirement in Section 3.4.1 of [RFC8085]. 5. STAMP sessions that choose to use a UDP zero-checksum MUST NOT make assumptions regarding the correctness of received test packets and MUST behave correctly when a UDP datagram is corrupted. This corresponds to the fifth requirement in Section 3.4.1 of [RFC8085]. 5. Session-Sender Test Packet STAMP Session-Sender test packets are transmitted on an LSP or a PW using an MPLS header with an IP/UDP header in Format-1 or without an IP/UDP header in Format-2. Additionally: Gandhi, et al. Expires 8 March 2027 [Page 19] Internet-Draft STAMP in MPLS Networks September 2026 * For PWs, Session-Sender test packets are transmitted on the PW using the label stack of the PW, including the PW label and the G-ACh. * For LSPs, Session-Sender test packets are transmitted on the LSP using the label stack of the LSP, with a G-ACh where the LSP carries the CW or where a GAL is used. Where neither is present, the test packet is transmitted in Format-1 with an IP/UDP header and no G-ACh, as in Use Case 1 of Section 4.1; Format-2 is not applicable in that case. 5.1. Session-Sender Test Packet with IP/UDP Header in Format-1 The content of an example STAMP Session-Sender test packet for an LSP or a PW encapsulated using a G-ACh and an IP/UDP header in Format-1 is shown in Figure 2. Gandhi, et al. Expires 8 March 2027 [Page 20] Internet-Draft STAMP in MPLS Networks September 2026 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label(1) | TC |0| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Label or Ultimate LSP Label | TC |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | . Associated Channel carries an IPv4 packet (0x0021) or . . Associated Channel carries an IPv6 packet (0x0057) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Header | . Source IP Address . . = Session-Sender IPv4 or IPv6 Address . . Destination IP Address . . = Session-Reflector IPv4 or IPv6 Address . . IPv4 Protocol or IPv6 Next Header = UDP (17) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Header | . Source Port = As chosen by Session-Sender . . Destination Port = User-configured Destination Port or 862 . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload = Test Packet as specified in Section 3 of RFC 8972 | . in Figure 1 and Figure 3 . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Example Session-Sender Test Packet with G-ACh and IP/ UDP Header in Format-1 The TTL of the PW label or ultimate LSP label is 1 only where control channel Type 3 is in effect, as specified in Section 4.3; for Types 1 and 4 it is set as it would be for the data traffic being measured. Where a GAL is present, the packet is intercepted by the GAL as specified in Section 4.2 of [RFC5586], and the GAL LSE TTL is set to 1. Where Type 4 is in effect with Format-1, a GAL is present immediately above the G-ACh as shown in Figure 3, and the remainder of the packet is as shown in Figure 2. Per Section 4.2 this does not apply to MPLS-TP PWs. Gandhi, et al. Expires 8 March 2027 [Page 21] Internet-Draft STAMP in MPLS Networks September 2026 The destination address in the IP header of a STAMP test packet can be one of the following when adding an MPLS encapsulation for an LSP or a PW. * A routable IPv4 address * A routable IPv6 address * An IPv4 address from the 127/8 range * An IPv6 address from the Dummy IPv6 Prefix 100:0:0:1::/64 [RFC9780] [IANA-IPv6-REG] For an IPv6 address from the dummy prefix, as specified in Section 1 of [RFC9780], this source-only prefix is deliberately used as a destination to generate an exception. Example implementations include: * An implementation using a routable IP address as the destination address during the initial forwarding step, before the STAMP test packet gets forwarded into the MPLS LSP or PW. * An implementation using a non-routable IP address as the destination address while adding both an IP header and an MPLS encapsulation in the same forwarding step. When adding the G-ACh header [RFC5586] with the channel type "Associated Channel carries an IPv4 packet" or "Associated Channel carries an IPv6 packet", it MUST immediately follow the bottom of the label stack. The payload contains the STAMP Session-Sender test packet defined in [RFC8972]. The STAMP Session-Sender test packet G-ACh header contains the following fields: * PFN: The PFN is set to 0x1 [RFC9790]. * Version: The Version field is set to 0, as defined in [RFC4385]. * Reserved: Reserved bits MUST be set to zero upon transmission and ignored upon receipt. * Channel Type: Associated Channel carries an IPv4 packet (0x0021) or Associated Channel carries an IPv6 packet (0x0057) [RFC4385]. Gandhi, et al. Expires 8 March 2027 [Page 22] Internet-Draft STAMP in MPLS Networks September 2026 5.2. Session-Sender Test Packet without IP/UDP Header in Format-2 The content of an example STAMP Session-Sender test packet for an LSP or a PW encapsulated using the GAL and a G-ACh without an IP/UDP header in Format-2 is shown in Figure 3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label(1) | TC |0| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Label or Ultimate LSP Label | TC |0| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | TC |1| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | STAMP Sender G-ACh (TBA1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload = Test Packet as specified in Section 3 of RFC 8972 | . in Figure 1 and Figure 3 . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Example Session-Sender Test Packet with GAL and G-ACh without IP/UDP Header in Format-2 The TTL of the PW label or ultimate LSP label is 1 only where control channel Type 3 is in effect, as specified in Section 4.3; for Types 1 and 4 it is set as it would be for the data traffic being measured. Where a GAL is present, the packet is intercepted by the GAL as specified in Section 4.2 of [RFC5586], and the GAL LSE TTL is set to 1. When adding the G-ACh header [RFC5586] with the new STAMP Session- Sender channel type (value TBA1), it MUST immediately follow the bottom of the label stack. The payload contains the STAMP Session- Sender test packet defined in [RFC8972]. The STAMP channel type allows the encapsulated STAMP payload to be identified. The STAMP Session-Sender test packet G-ACh header contains the following fields: * PFN: The PFN is set to 0x1 [RFC9790]. Gandhi, et al. Expires 8 March 2027 [Page 23] Internet-Draft STAMP in MPLS Networks September 2026 * Version: The Version field is set to 0, as defined in [RFC4385]. * Reserved: Reserved bits MUST be set to zero upon transmission and ignored upon receipt. * Channel Type: G-ACh type for STAMP Session-Sender packet (value TBA1). 6. Session-Reflector Test Packet STAMP Session-Reflector test packets are transmitted with an IP/UDP header in Format-1 or without an IP/UDP header in Format-2. The Session-Reflector processes and returns a received STAMP test packet in both cases as follows: * When a Session-Sender test packet is received with a G-ACh, the Session-Reflector MUST reflect the test packet to the Session- Sender using the same G-ACh in the reverse direction of the bidirectional LSP or PW. - The Session-Reflector MUST transmit the reflected test packet on the same path in the reverse direction of the bidirectional LSP or PW. - The Session-Reflector uses the PW label or the ultimate LSP label in the received packet to determine the reverse-direction LSP or PW context. - If the received packet context is a PW, the Session-Reflector MUST use the reverse-direction PW label stack and G-ACh to transmit the Session-Reflector test packet. The reverse- direction PW label stack can be determined through static configuration or the signaling protocol used to establish the PW. - If the received packet context is a bidirectional LSP, the Session-Reflector MUST use the reverse-direction LSP label stack and G-ACh to transmit the Session-Reflector test packet. The reverse-direction LSP label stack can be determined through static configuration or the signaling protocol used to establish the bidirectional LSP. - If the Session-Reflector cannot find a reverse-direction LSP or PW context for the received test packet, it MUST discard the received packet and MUST NOT transmit a reply. Gandhi, et al. Expires 8 March 2027 [Page 24] Internet-Draft STAMP in MPLS Networks September 2026 - The reflected test packet MUST include an IP/UDP header (Format-1) if the received Session-Sender test packet includes one (see Section 6.1); otherwise, it MUST be sent without an IP/UDP header (Format-2) (see Section 6.2). * In all other cases for STAMP test packets using an IP/UDP header (Format-1), the Session-Reflector MUST reflect the test packet using an IP/UDP header based on the information in the IP/UDP header of the Session-Sender test packet as specified in Section 6.1 and is subject to the Return Path TLV applicability (Section 4 of [RFC9503]). 6.1. Session-Reflector Test Packet with IP/UDP Header in Format-1 The content of an example STAMP Session-Reflector test packet for an LSP or a PW encapsulated using a G-ACh and an IP/UDP header in Format-1 is shown in Figure 4. Gandhi, et al. Expires 8 March 2027 [Page 25] Internet-Draft STAMP in MPLS Networks September 2026 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label(1) | TC |0| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Label or Ultimate LSP Label | TC |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | . Associated Channel carries an IPv4 packet (0x0021) or . . Associated Channel carries an IPv6 packet (0x0057) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Header | . Source IP Address . . = Configured on Session-Reflector . . Destination IP Address . . = Source IP Address from Session-Sender Test Packet . . IPv4 Protocol or IPv6 Next Header = UDP (17) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Header | . Source Port = As chosen by Session-Reflector . . Destination Port . . = Source Port from Session-Sender Test Packet . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload = Test Packet as specified in Section 3 of RFC 8972 | . in Figure 2 and Figure 4 . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Example Session-Reflector Test Packet with G-ACh and IP/UDP Header in Format-1 The TTL of the PW label or ultimate LSP label is 1 only where control channel Type 3 is in effect, as specified in Section 4.3; for Types 1 and 4 it is set as it would be for the data traffic being measured. Where a GAL is present, the packet is intercepted by the GAL as specified in Section 4.2 of [RFC5586], and the GAL LSE TTL is set to 1. Gandhi, et al. Expires 8 March 2027 [Page 26] Internet-Draft STAMP in MPLS Networks September 2026 When adding the G-ACh header [RFC5586] with the channel type "Associated Channel carries an IPv4 packet" or "Associated Channel carries an IPv6 packet", it MUST immediately follow the bottom of the label stack. The payload contains the STAMP Session-Reflector test packet defined in [RFC8972]. The STAMP Session-Reflector test packet MUST use the source address and the source UDP port from the received test packet as the destination address and the destination UDP port when an IP/UDP header is present in the received test packet. The STAMP Session-Reflector test packet G-ACh header contains the following fields: * PFN: The PFN is set to 0x1 [RFC9790]. * Version: The Version field is set to 0, as defined in [RFC4385]. * Reserved: Reserved bits MUST be set to zero upon transmission and ignored upon receipt. * Channel Type: Associated Channel carries an IPv4 packet (0x0021) or Associated Channel carries an IPv6 packet (0x0057) [RFC4385]. 6.2. Session-Reflector Test Packet without IP/UDP Header in Format-2 The content of an example STAMP Session-Reflector test packet for an LSP or a PW encapsulated using the GAL and a G-ACh without an IP/UDP header in Format-2 is shown in Figure 5. Gandhi, et al. Expires 8 March 2027 [Page 27] Internet-Draft STAMP in MPLS Networks September 2026 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label(1) | TC |0| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Label or Ultimate LSP Label | TC |0| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | TC |1| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | STAMP Reflector G-ACh (TBA2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload = Test Packet as specified in Section 3 of RFC 8972 | . in Figure 2 and Figure 4 . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Example Session-Reflector Test Packet with GAL and G-ACh without IP/ UDP Header in Format-2 The TTL of the PW label or ultimate LSP label is 1 only where control channel Type 3 is in effect, as specified in Section 4.3; for Types 1 and 4 it is set as it would be for the data traffic being measured. Where a GAL is present, the packet is intercepted by the GAL as specified in Section 4.2 of [RFC5586], and the GAL LSE TTL is set to 1. When adding the G-ACh header [RFC5586] with the new STAMP Session- Reflector channel type (value TBA2), it MUST immediately follow the bottom of the label stack. The payload contains the STAMP Session- Reflector test packet defined in [RFC8972]. The STAMP channel type allows the encapsulated STAMP payload to be identified. The STAMP Session-Reflector test packet G-ACh header contains the following fields: * PFN: The PFN is set to 0x1 [RFC9790]. * Version: The Version field is set to 0, as defined in [RFC4385]. * Reserved: Reserved bits MUST be set to zero upon transmission and ignored upon receipt. Gandhi, et al. Expires 8 March 2027 [Page 28] Internet-Draft STAMP in MPLS Networks September 2026 * Channel Type: G-ACh type for STAMP Session-Reflector packet (value TBA2). 7. Operational Considerations The operational considerations specified in Section 5 of [RFC8762] also apply to the procedure specified in this document. Further, the operation and management of performance measurement based on STAMP specified in Section 3 of [RFC8762] also apply to the procedure specified in this document. When a destination UDP port number other than the default port 862 is used, the same network-impact study and agreement requirements specified in Section 3.1 apply. Based on local policy, an operator may add the MPLS encapsulation only for STAMP test packets destined to addresses within the MPLS administrative domain. 7.1. ECMP Considerations The following considerations apply when encapsulating STAMP test packets to follow the same ECMP path as the data traffic being measured. * G-ACh encapsulation enables STAMP test packets in Format-1 and Format-2 to follow the ECMP path taken by data packets that use the CW when label-based ECMP is used, as defined in [RFC4928]. This assumes that the nodes on the packet path apply the same ECMP selection to STAMP test packets as to data packets with the CW. * Because STAMP test packets in Format-1 use IP addresses different from those used by the data packets, IP ECMP specified in [RFC4928] may result in different ECMP load-balancing decisions, as specified in Section 2.4.5.2 of [RFC7325]. Gandhi, et al. Expires 8 March 2027 [Page 29] Internet-Draft STAMP in MPLS Networks September 2026 * Special-purpose labels (values 0-15) are not to be used in ECMP decisions. Section 2.1.1.1 of [RFC9790] recommends that load balancing use the value of a dedicated label and deprecates the practice of deducing the payload type from the PFN; Section 2.4.5.1 of [RFC7325] states the same requirement for special-purpose labels including the GAL. On conforming equipment, the GAL does not change the ECMP selection, and STAMP test packets follow the same path as data packets with the same label stack. Where an LSP traverses non-conforming equipment, the presence of the GAL can cause STAMP test packets to take a different path from the traffic being measured, as noted in Section 3 of [RFC7708]; a control channel type that adds no label ought to be provisioned in that case. * When using the "MPLS PW Label with TTL == 1" mechanism, the TTL field SHOULD NOT be used to make ECMP decisions as specified in Section 2.4.5.1 of [RFC7325] in order for the STAMP test packets to follow the same path as data packets with the same label stack. 7.2. STAMP Session State Notification The STAMP session state change notifications specified in this section are applicable to all STAMP sessions and are not limited to STAMP sessions for LSPs and PWs. The STAMP session state monitoring allows the Session-Sender to determine whether the STAMP test is idle, active, or failed. A STAMP implementation SHOULD generate state-change notifications as follows: * STAMP session state is notified as idle when the Session-Sender is not transmitting test packets. * The STAMP session state is initially notified as active when the Session-Sender is transmitting test packets and at least one Session-Reflector test packet is received. * The STAMP session state is notified as failed when N consecutive Session-Reflector test packets are not received after the STAMP session state is notified as active, where N (the consecutive packet loss count) is a locally provisioned value. * The STAMP session state transitions from failed back to active when the Session-Sender is transmitting test packets and at least one Session-Reflector test packet is again received. Gandhi, et al. Expires 8 March 2027 [Page 30] Internet-Draft STAMP in MPLS Networks September 2026 Because STAMP test packets are transmitted over the LSP or PW being measured, a connectivity failure of that LSP or PW typically manifests as the continuous packet loss specified above, resulting in the STAMP session state being notified as failed. 7.3. Rate Limiting The rate limiting considerations specified in this section are applicable to all STAMP sessions and are not limited to STAMP sessions for LSPs and PWs. On both Session-Sender and Session-Reflector nodes, as each STAMP test packet is processed by the control plane and consumes CPU and memory resources, it is subject to rate limiting as a protection against denial-of-service attacks. Such rate limiting on the punt path is indistinguishable from the actual loss in the network and can therefore be reported as packet loss. It is useful for an operator to know that rate limiting was applied to STAMP test packets (for example, based on the UDP ports used for STAMP in Format-1, and LSP or PW context and Channel Type used for STAMP in Format-2), so that the alerting system can correlate STAMP packets being rate-limited with failure notifications. This throttling or policing of incoming STAMP test packets SHOULD NOT be more stringent than the bandwidth allocated to the STAMP test packets to prevent invalid measurement results. Additional guidance on configuring punt-path rate limiters can also be found in Section 9 of [RFC5085]. 7.4. Congestion Considerations The rate at which STAMP test packets are transmitted must be configured and accounted for when provisioning bandwidth for LSPs and PWs. The configured transmit rate must be appropriate for the bandwidth capacity in both directions. This applies to both Format-1 and Format-2 STAMP test packets and MUST include the MTU requirements specified in Section 7.5. As specified in Section 7 of [RFC8762], the load of the STAMP-test packets offered to a network MUST be carefully estimated, and the possible impact on the existing services MUST be thoroughly analyzed before launching the test session. Section 3.1.5 of [RFC8085] provides guidance on handling network load for a UDP-based protocol, and applies to the STAMP test packets in Format-1. Gandhi, et al. Expires 8 March 2027 [Page 31] Internet-Draft STAMP in MPLS Networks September 2026 The congestion considerations in Section 9 of [RFC5085] apply to the STAMP test packets. As specified in Section 9 of [RFC5085], the ICMP and MPLS LSP PING applications should be rate-limited to below 5% of the bit-rate of the associated PW. This rate limit also applies to the STAMP test packets. Because the Session-Reflector responds to each received test packet, the following requirements apply when provisioning bandwidth: * The reverse direction can generate a comparable test packet transmit rate and MUST be accounted independently when provisioning the reverse direction LSP and PW. * The configured transmit rate MUST account for cases where the reverse direction has less capacity than the forward direction. 7.5. MTU Requirements The size of a STAMP test packet, including the encapsulation overhead, MUST fit within the LSP or PW MTU independently in both directions. * When using the Extra Padding TLV (value 1) defined in [RFC8972], its size MUST be included when selecting the test packet size, with the default of symmetric size meaning the reflected test packet matches the size of the received test packet. * When the GAL is used, it adds 4 octets of label stack in the case of both Format-1 and Format-2, relative to the data traffic being measured. * When a G-ACh is used, it adds 4 octets to the test packet. Relative to the data traffic being measured, where that traffic carries a Control Word, the G-ACh header occupies the position of the Control Word and adds no net overhead; where it does not, the G-ACh adds 4 octets. A test packet with G-ACh encapsulation that exceeds the LSP or PW MTU is dropped rather than fragmented and can therefore appear as packet loss. * The IPv4/UDP encapsulation adds 28 octets whereas the IPv6/UDP encapsulation adds 48 octets to the Format-1 test packets. Format-1 test packets need to be sized to avoid IP fragmentation. Gandhi, et al. Expires 8 March 2027 [Page 32] Internet-Draft STAMP in MPLS Networks September 2026 7.6. Considerations for Broken LSPs Forwarding STAMP test packets with an IP/UDP header on a broken LSP would cause the STAMP session to be down when all packets on the LSP are dropped. Otherwise, when the test packets are incorrectly forwarded by MPLS or IP to the egress node (hosting the STAMP Session-Reflector), it could lead to an invalid measurement of the LSP, for example, if the packets followed a different path than the LSP. A non-routable IPv4/IPv6 destination address, specified in Section 5.1, avoids IP-forwarding Session-Sender test packets to the egress node on a different path than the LSP. However, there is a potential risk of receiving Session-Reflector test packets from an unintended STAMP Session-Reflector hosted on the node where the broken LSP terminates, since the STAMP Session-Reflector may not know that the test packets were received due to a broken LSP. In this case, network analytics would detect invalid measurements reported by STAMP over a broken LSP path. Further, the destination IP address-based filtering SHOULD be provisioned on the edges of the MPLS administrative domain to prevent the IP-forwarded STAMP test packets for a broken LSP within the domain from leaking outside the domain. A non-routable IPv4/IPv6 destination address, specified in Section 5.1, MAY be used in STAMP test packets to help avoid this. Note that this edge filtering does not protect against the case where the Session-Sender and Session- Reflector both reside within the same administrative domain: a natively IP-routed STAMP test packet would still reach the Session- Reflector without ever crossing a domain edge. In this case, the non-routable destination address technique specified above remains the primary mitigation. The considerations specified above also apply to the reverse direction. In particular, when the reverse LSP is broken, a Session- Reflector test packet with an IP/UDP header may be incorrectly forwarded by MPLS or IP to the ingress node (hosting the STAMP Session-Sender). This is because its destination address is the Session-Sender's source address, which is routable. The non-routable destination address technique specified above does not protect the reflected packet. Operators SHOULD therefore apply appropriate filtering policies at the edges of the MPLS administrative domain to prevent reflected STAMP test packets from leaking outside the domain. As STAMP test packets in Format-2 are not IP-forwarded, the above considerations are not applicable. However, when the test packets are incorrectly MPLS forwarded to the egress node, it could lead to invalid measurements of the LSP. Gandhi, et al. Expires 8 March 2027 [Page 33] Internet-Draft STAMP in MPLS Networks September 2026 8. Security Considerations The procedures defined in this document are intended for deployment in a single network administrative domain. As such, the Session- Sender address, the Session-Reflector address, and the IP and MPLS forward and return paths are provisioned by the operator for the STAMP session. It is assumed that the operator has verified the integrity of the IP and MPLS forward and return paths used to transmit STAMP test packets. The security considerations specified in [RFC8762] and [RFC8972] also apply to the procedure specified in this document. Specifically, the message integrity protection using HMAC, as defined in Section 4.4 of [RFC8762], also applies to the procedure specified in this document. When an IP/UDP header is used, the measures specified in Section 7 of [RFC8762] to mitigate attacks using the registered UDP port number also apply. Routers that support G-ACh are subject to the same security considerations as defined in [RFC4385] and [RFC5586]. The message throttling mechanisms specified in the security considerations in Section 10 of [RFC5085] to protect against potential (deliberate or unintentional) attacks also apply to the procedure specified in this document. If desired, attacks can be mitigated by performing basic validation checks in Session-Reflector test packets received at the Session- Sender, such as verifying that timestamp T2 is later than timestamp T1 (when the Session-Sender and Session-Reflector clocks are synchronized) in the STAMP Reference Topology shown in Figure 1. The minimal state associated with this protocol also limits the extent of measurement disruption that can be caused by a corrupt or invalid test packet to a single test cycle. An attacker able to inject STAMP test packets into an LSP or PW can corrupt the measurement: forged Session-Reflector test packets accepted by a Session-Sender produce incorrect delay and loss results, and forged Session-Sender test packets cause a Session- Reflector to generate replies that consume capacity on the return path and on the punt path described in Section 7.3. An attacker able to suppress test packets can cause the STAMP session state to be reported as failed for an LSP or PW that is in fact healthy. To mitigate these threats, operators SHOULD filter STAMP test packets at the edges of the MPLS administrative domain. Gandhi, et al. Expires 8 March 2027 [Page 34] Internet-Draft STAMP in MPLS Networks September 2026 Off-path attack protection differs by format. For Format-1, the source UDP port number is chosen as specified in [RFC8762], which provides the protection against off-path attacks recommended in [RFC8085]. For Format-2 there is no UDP header and no source port number; the corresponding protection is provided by the LSP or PW context on which the test packet is received, together with the requirement in Section 5 of [RFC5586] that a node discard associated channel packets on a Channel Type it has not indicated it will process. For both formats, STAMP test packets sent within an MPLS administrative domain benefit from the MPLS encapsulation itself, which makes it extremely difficult for off-path attackers to inject packets that follow the correct label stack and MPLS forwarding path. The requirement that Session-Reflector test packets MUST be transmitted on the reverse LSP or PW (see Section 6) further restricts the paths that valid STAMP test packets can traverse, providing defense against off-path attacks. Furthermore, implementations SHOULD NOT assign SSIDs [RFC8972] predictably. To avoid predictability, implementations can leverage a Cryptographically Secure Pseudorandom Number Generator [NIST-CSPRNG]. The STAMP test packets received via a PW or an LSP are processed in the context of that PW or LSP, and the encapsulations defined in this document do not introduce a mechanism for cross-service OAM interactions. 9. IANA Considerations IANA maintains the G-ACh Type Registry (see https://www.iana.org/assignments/g-ach-parameters/g-ach- parameters.xhtml). IANA is requested to allocate values for the G-ACh Types for STAMP from the "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)" registry. +=======+====================================+===============+ | Value | Description | Reference | +=======+====================================+===============+ | TBA1 | STAMP Session-Sender G-ACh Type | This document | +-------+------------------------------------+---------------+ | TBA2 | STAMP Session-Reflector G-ACh Type | This document | +-------+------------------------------------+---------------+ Table 3: STAMP G-ACh Types 10. References 10.1. Normative References Gandhi, et al. Expires 8 March 2027 [Page 35] Internet-Draft STAMP in MPLS Networks September 2026 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC768, August 1980, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, . [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, DOI 10.17487/RFC3443, January 2003, . [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, . [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, DOI 10.17487/RFC4928, June 2007, . [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, . [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, . [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, DOI 10.17487/RFC6056, January 2011, . Gandhi, et al. Expires 8 March 2027 [Page 36] Internet-Draft STAMP in MPLS Networks September 2026 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, . [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 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, . [RFC7708] Nadeau, T., Martini, L., and S. Bryant, "Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator", RFC 7708, DOI 10.17487/RFC7708, November 2015, . [RFC9780] Mirsky, G., Mishra, G., and D. Eastlake 3rd, "Bidirectional Forwarding Detection (BFD) for Multipoint Networks over Point-to-Multipoint MPLS Label Switched Paths (LSPs)", RFC 9780, DOI 10.17487/RFC9780, May 2025, . Gandhi, et al. Expires 8 March 2027 [Page 37] Internet-Draft STAMP in MPLS Networks September 2026 [RFC9790] Kompella, K., Bryant, S., Bocci, M., Mirsky, G., Ed., Andersson, L., and J. Dong, "IANA Registry and Processing Recommendations for the First Nibble Following a Label Stack", RFC 9790, DOI 10.17487/RFC9790, July 2025, . [RFC9801] Gringeri, S., Whittaker, J., Leymann, N., Schmutzer, C., Ed., and C. Brown, "Private Line Emulation over Packet Switched Networks", RFC 9801, DOI 10.17487/RFC9801, July 2025, . 10.2. Informative References [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, . [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, . [RFC5087] Stein, Y., Shashoua, R., Insler, R., and M. Anavi, "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, DOI 10.17487/RFC5087, December 2007, . [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, . [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, . [RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, DOI 10.17487/RFC5960, August 2010, . [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, . Gandhi, et al. Expires 8 March 2027 [Page 38] Internet-Draft STAMP in MPLS Networks September 2026 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 2011, . [RFC6658] Bryant, S., Ed., Martini, L., Swallow, G., and A. Malis, "Packet Pseudowire Encapsulation over an MPLS PSN", RFC 6658, DOI 10.17487/RFC6658, July 2012, . [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., and C. Pignataro, "MPLS Forwarding Compliance and Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, August 2014, . [RFC7820] Mizrahi, T., "UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)", RFC 7820, DOI 10.17487/RFC7820, March 2016, . [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, . [RFC9503] Gandhi, R., Ed., Filsfils, C., Chen, M., Janssens, B., and R. Foote, "Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks", RFC 9503, DOI 10.17487/RFC9503, October 2023, . [RFC9570] Kompella, K., Bonica, R., and G. Mirsky, Ed., "Deprecating the Use of Router Alert in LSP Ping", RFC 9570, DOI 10.17487/RFC9570, May 2024, . [I-D.ietf-spring-stamp-srpm-mpls] Gandhi, R., Filsfils, C., Janssens, B., Chen, M., and R. F. Foote, "Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the MPLS Data Plane", Work in Progress, Internet- Draft, draft-ietf-spring-stamp-srpm-mpls-06, 18 August 2026, . Gandhi, et al. Expires 8 March 2027 [Page 39] Internet-Draft STAMP in MPLS Networks September 2026 [NIST-CSPRNG] NIST Special Publication 800-90A Revision 1, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators, Revision 1", June 2015. [IANA-IPv6-REG] IANA, "IANA IPv6 Special-Purpose Address Registry", . Acknowledgments The authors would like to thank Bharath Vasudevan, Ali Sianati, and Parag Jain for the discussions regarding the method to punt STAMP test packets to the control plane for processing. The authors would also like to thank Greg Mirsky, Loa Andersson, Li Zhang, Richard Foote (Footer), and Stewart Bryant for reviewing this document and providing useful comments and suggestions. Thanks to Carlos Pignataro for the PerfMetrdir review, Russ White for the early Rtgdir review, Russ Housley for the Gen-ART review, Vidhi Goel for the telechat TSVART review, Giuseppe Fioccola for the Opsdir review, Jen Linkova for the telechat Intdir review, Yaron Sheffer for the early Secdir review, Roman Danyliw, Gorry Fairhurst, Mohamed Boucadair, Eric Vyncke, Gunter Van de Velde, Mike Bishop, and Ketan Talaulikar for IESG review which helped improve this document. Authors' Addresses Rakesh Gandhi (editor) Cisco Systems, Inc. Canada Email: rgandhi@cisco.com Patrice Brissette Cisco Systems, Inc. Canada Email: pbrisset@cisco.com Edward Leyton Verizon Wireless Email: edward.leyton@verizonwireless.com Gandhi, et al. Expires 8 March 2027 [Page 40] Internet-Draft STAMP in MPLS Networks September 2026 Xiao Min ZTE Corp. Nanjing China Email: xiao.min2@zte.com.cn Gandhi, et al. Expires 8 March 2027 [Page 41]