]> China Mobile

Beijing100053 China lizhiqiangyjy@chinamobile.com

China Mobile

Beijing100053 China duzongpeng@chinamobile.com

Centec

Shanghai201203 China wangjj@centec.com

Centec

Shanghai201203 China chengw@centec.com

Centec

Shanghai201203 China zhanggy@centec.com

Inesa

Shanghai200030 China sunxun@inesa.com

SAIA

Shanghai200125 China chunhao.zhao@sh-aia.com

TSV IPPM STAMP ECMP LAG performance measurement flow matching 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.

Introduction The Simple Two-Way Active Measurement Protocol (STAMP) 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 and provides a simplified architecture that separates control and test functions. In networks that use hash-based Equal-Cost Multi-Path (ECMP) 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. 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.

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 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the STAMP terminology defined in and . 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.

Scope and Relationship to Existing Specifications This document defines operational procedures for STAMP sessions. It does not modify STAMP packet formats, state machines, or protocol exchanges. 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. 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 deployments, though STAMP is preferred for new deployments.

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.

Session-Sender Configuration In addition to the standard STAMP session parameters defined in , 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.

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 ).

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 , including sequence number, timestamp, error estimate, and any optional TLVs defined in . 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.

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 , 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 . 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.

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 is included, it MAY be used for additional discrimination).

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 , IPv6 flow labels , 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.

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.

Security Considerations

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 SHOULD be used to provide payload-level integrity protection.

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 may drop these packets. Operators MUST configure ingress filters to permit ECMP-aware test traffic from authorized Session-Sender nodes within the measurement domain.

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.

IANA Considerations This document has no IANA actions.

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.