| Internet-Draft | STAMP ECMP-Aware PM | July 2026 |
| Li, et al. | Expires 5 January 2027 | [Page] |
This document specifies procedures for configuring Simple Two-Way Active Measurement Protocol (STAMP) sessions so that test packets traverse the same ECMP or LAG forwarding path as a specified production flow. In networks that use hash-based load distribution, the forwarding path depends on a hash over packet header fields. Standard STAMP test packets carry session-specific addresses and ports that differ from production traffic, often selecting a different forwarding path and yielding measurements that do not represent the actual service quality of the production flow. The procedures in this document specify how the Session-Sender populates test packet headers with values matching a designated production flow. The Session-Reflector identifies test packets by validating the STAMP payload structure. No changes to the STAMP packet formats defined in RFC 8762 are required.¶
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 5 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Simple Two-Way Active Measurement Protocol (STAMP) [RFC8762] measures network delay, delay variation, and packet loss by exchanging test packets between a Session-Sender and a Session-Reflector. STAMP is the successor to TWAMP [RFC5357] and provides a simplified architecture that separates control and test functions.¶
In networks that use hash-based Equal-Cost Multi-Path (ECMP) [RFC2992] or Link Aggregation Group (LAG) load distribution, the forwarding path depends on a hash over selected header fields, commonly the IP source and destination addresses and transport-layer port numbers. Standard STAMP test packets use session-specific addresses and port 862, which typically differ from those of production traffic. The hash function may therefore select a different forwarding path for test packets than for the production flow under observation.¶
[RFC9503] defines techniques for probing different ECMP paths by sweeping destination addresses (e.g., within the 127/8 range) or entropy labels. Those techniques discover and measure all available ECMP paths but do not target the specific path of a given production flow. This document specifies procedures for the complementary case: measuring the path that a specific production flow takes by constructing test packets with matching header values.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the STAMP terminology defined in [RFC8762] and [RFC8972]. The following additional terms are defined:¶
This document defines operational procedures for STAMP [RFC8762] sessions. It does not modify STAMP packet formats, state machines, or protocol exchanges. [RFC8972] defines optional STAMP TLV extensions. Flow-matching test packets are fully compatible with these extensions; in particular, the SSID TLV can aid test packet identification. [RFC9503] defines STAMP procedures for Segment Routing networks, including ECMP path sweeping. This document specifies procedures for measuring the path of a specific production flow, which is a distinct use case. The procedures also apply to TWAMP Light [RFC5357] deployments, though STAMP is preferred for new deployments.¶
An ECMP-aware STAMP session requires additional configuration parameters that describe the reference flow. These parameters are used by the Session-Sender for test packet construction and by the Session-Reflector for test packet identification.¶
In addition to the standard STAMP session parameters defined in [RFC8762], the following parameters MUST be configurable on the Session-Sender: Reference Source Address, Reference Destination Address, Reference Source Port, Reference Destination Port, and Reference DSCP.¶
The Session-Reflector MUST be configured with the reference flow header parameters. Because test packets carry the same header values as production traffic, the Session-Reflector cannot rely on the default STAMP destination port (862) alone. The Session-Reflector MUST identify test packets by matching the configured reference flow headers AND validating the STAMP payload structure (sequence number, timestamp, and error estimate as defined in [RFC8762]).¶
When transmitting a test packet for an ECMP-aware session, the Session-Sender MUST populate the IP source address, IP destination address, UDP source port, and UDP destination port with the configured reference flow values. The DSCP field MUST be set to the configured reference DSCP value. The UDP payload MUST contain the STAMP Session-Sender test packet format defined in Section 4 of [RFC8762], including sequence number, timestamp, error estimate, and any optional TLVs defined in [RFC8972].¶
Because these header fields replicate the reference flow, hash-based forwarding nodes along the path compute the same hash and select the same output port or next hop as they would for the reference flow's production traffic.¶
Note: STAMP test packets always use IP protocol number 17 (UDP) regardless of the reference flow's transport protocol. If the network's hash function includes the IP protocol number, the test packet hash will differ from that of a TCP (protocol 6) or SCTP (protocol 132) reference flow. Operators SHOULD verify whether the hash function on the relevant nodes includes the IP protocol field and, if so, SHOULD assess whether this affects path selection for the reference flow. In practice, many implementations hash only on IP addresses and port numbers, and the protocol number does not influence path selection.¶
When the Session-Reflector receives a packet whose IP addresses and UDP ports match a configured ECMP-aware session, it MUST inspect the UDP payload. If the payload conforms to the STAMP test packet format defined in [RFC8762], the Session-Reflector MUST process the packet as a STAMP test packet and generate a reply.¶
The reply test packet MUST swap the source and destination IP addresses and UDP port numbers, so that hash-based forwarding on the return path selects the reverse-direction path of the reference flow. The reply payload MUST conform to the STAMP Session-Reflector format defined in [RFC8762].¶
If the payload does not match the STAMP format, the Session-Reflector MUST forward the packet as regular production traffic. This ensures that the reference flow is not disrupted.¶
Because flow-matching test packets share header fields with the reference flow, the Session-Reflector relies on payload-level inspection for identification. The following criteria SHOULD be applied in combination: Header Match (IP addresses and UDP ports match the configured reference flow parameters); Payload Length (at least 44 octets unauthenticated or 112 octets authenticated); Format Validation (STAMP fields pass structural validation); SSID Discrimination (if an SSID TLV [RFC8972] is included, it MAY be used for additional discrimination).¶
Hash-based ECMP and LAG implementations vary in which header fields participate in the hash computation. Common hash inputs include the IP source and destination addresses and the transport-layer source and destination port numbers. Some implementations additionally include the IP protocol number, MPLS entropy labels [RFC6790], IPv6 flow labels [RFC6437], or inner-header fields for tunneled packets.¶
For effective ECMP-aware measurement, the reference flow header fields used in the test packet MUST cover at least the fields that the network's hash function uses for path selection. Operators SHOULD verify which fields are included in the hash on the relevant network devices. For IPv6 networks, the flow label field may influence ECMP path selection. If the Session-Sender node supports configuring an IPv6 flow label value for the test packet, the reference flow's flow label SHOULD be replicated as well.¶
ECMP-aware STAMP sessions are configured using the same management interfaces as standard STAMP sessions. The additional reference flow parameters (addresses, ports, DSCP) extend the per-session configuration. Implementations SHOULD expose the reference flow parameters as part of the session state visible to the management system. Because test packets are indistinguishable from production traffic at the header level, network monitoring and troubleshooting tools that capture traffic based on header fields will include these test packets in their output. Operators SHOULD document active ECMP-aware sessions so that test traffic is not mistaken for anomalous production traffic during troubleshooting.¶
Flow-matching test packets share header fields with production traffic. Network security devices that filter based on header fields will apply the same policy to test and production packets. Operators MUST ensure that security policies within the measurement domain account for the presence of ECMP-aware test traffic. STAMP authenticated mode [RFC8762] SHOULD be used to provide payload-level integrity protection.¶
Flow-matching test packets carry source IP addresses that belong to the reference flow's originator, not to the Session-Sender node. Ingress filtering per BCP 38 [RFC2827] may drop these packets. Operators MUST configure ingress filters to permit ECMP-aware test traffic from authorized Session-Sender nodes within the measurement domain.¶
An incorrectly configured Session-Reflector could misidentify production traffic as test packets. Implementations MUST require successful STAMP payload validation before treating any packet as a test packet. When payload validation is ambiguous, the packet MUST be forwarded as production traffic. The rate of test packets SHOULD be limited to a negligible fraction of the reference flow's bandwidth.¶
This document has no IANA actions.¶
The authors would like to thank the members of the IPPM Working Group. The STAMP protocol suite, particularly RFC 8762, RFC 8972, and RFC 9503, provided the protocol foundation for this document.¶