Procedures for ECMP-Aware Performance Measurement with STAMP
draft-li-ippm-stamp-ecmp-pm-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Zhiqiang Li , Zongpeng Du , Junjie Wang , Wei Cheng , Guoying Zhang , Xun Sun , Chunhao Zhao | ||
| Last updated | 2026-07-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-ippm-stamp-ecmp-pm-00
IPPM Z. Li
Internet-Draft Z. Du
Intended status: Standards Track China Mobile
Expires: 5 January 2027 J. Wang
W. Cheng
G. Zhang
Centec
X. Sun
Inesa
C. Zhao
SAIA
4 July 2026
Procedures for ECMP-Aware Performance Measurement with STAMP
draft-li-ippm-stamp-ecmp-pm-00
Abstract
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.
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."
Li, et al. Expires 5 January 2027 [Page 1]
Internet-Draft STAMP ECMP-Aware PM July 2026
This Internet-Draft will expire on 5 January 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scope and Relationship to Existing Specifications . . . . . . 3
4. Session Configuration . . . . . . . . . . . . . . . . . . . . 4
4.1. Session-Sender Configuration . . . . . . . . . . . . . . 4
4.2. Session-Reflector Configuration . . . . . . . . . . . . . 4
5. Session-Sender Procedures . . . . . . . . . . . . . . . . . . 4
6. Session-Reflector Procedures . . . . . . . . . . . . . . . . 5
7. Test Packet Identification . . . . . . . . . . . . . . . . . 5
8. ECMP and LAG Considerations . . . . . . . . . . . . . . . . . 6
9. Manageability Considerations . . . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10.1. Security Policy Considerations . . . . . . . . . . . . . 6
10.2. Source Address Considerations . . . . . . . . . . . . . 7
10.3. Production Traffic Protection . . . . . . . . . . . . . 7
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
12. Normative References . . . . . . . . . . . . . . . . . . . . 7
13. Informative References . . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
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.
Li, et al. Expires 5 January 2027 [Page 2]
Internet-Draft STAMP ECMP-Aware PM July 2026
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.
1.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. Terminology
This document uses the STAMP terminology defined in [RFC8762] and
[RFC8972]. The following additional terms are defined:
Reference Flow: The production traffic flow whose forwarding path is
the subject of performance measurement, identified by its header
fields (e.g., source and destination IP addresses, IP protocol,
source and destination port numbers).
Flow-Matching Test Packet: A STAMP test packet whose network-layer
and transport-layer header fields replicate those of the reference
flow so that hash-based forwarding selects the same path.
3. Scope and Relationship to Existing Specifications
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
Li, et al. Expires 5 January 2027 [Page 3]
Internet-Draft STAMP ECMP-Aware PM July 2026
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.
4. Session Configuration
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.
4.1. Session-Sender Configuration
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.
4.2. Session-Reflector Configuration
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]).
5. Session-Sender Procedures
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.
Li, et al. Expires 5 January 2027 [Page 4]
Internet-Draft STAMP ECMP-Aware PM July 2026
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.
6. Session-Reflector Procedures
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.
7. Test Packet Identification
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).
Li, et al. Expires 5 January 2027 [Page 5]
Internet-Draft STAMP ECMP-Aware PM July 2026
8. ECMP and LAG Considerations
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.
9. Manageability Considerations
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.
10. Security Considerations
10.1. Security Policy Considerations
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.
Li, et al. Expires 5 January 2027 [Page 6]
Internet-Draft STAMP ECMP-Aware PM July 2026
10.2. Source Address Considerations
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.
10.3. Production Traffic Protection
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.
11. IANA Considerations
This document has no IANA actions.
12. 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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
Two-Way Active Measurement Protocol", RFC 8762,
DOI 10.17487/RFC8762, March 2020,
<https://www.rfc-editor.org/info/rfc8762>.
Li, et al. Expires 5 January 2027 [Page 7]
Internet-Draft STAMP ECMP-Aware PM July 2026
[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,
<https://www.rfc-editor.org/info/rfc8972>.
13. Informative References
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000,
<https://www.rfc-editor.org/info/rfc2992>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[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,
<https://www.rfc-editor.org/info/rfc6790>.
[RFC9503] Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and B.
Janssens, "Simple Two-Way Active Measurement Protocol
(STAMP) Extensions for Segment Routing Networks",
RFC 9503, DOI 10.17487/RFC9503, October 2023,
<https://www.rfc-editor.org/info/rfc9503>.
Acknowledgements
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.
Authors' Addresses
Zhiqiang Li
China Mobile
Beijing
100053
China
Email: lizhiqiangyjy@chinamobile.com
Li, et al. Expires 5 January 2027 [Page 8]
Internet-Draft STAMP ECMP-Aware PM July 2026
Zongpeng Du
China Mobile
Beijing
100053
China
Email: duzongpeng@chinamobile.com
Junjie Wang
Centec
Shanghai
201203
China
Email: wangjj@centec.com
Wei Cheng
Centec
Shanghai
201203
China
Email: chengw@centec.com
Guoying Zhang
Centec
Shanghai
201203
China
Email: zhanggy@centec.com
Xun Sun
Inesa
Shanghai
200030
China
Email: sunxun@inesa.com
Chunhao Zhao
SAIA
Shanghai
200125
China
Email: chunhao.zhao@sh-aia.com
Li, et al. Expires 5 January 2027 [Page 9]