draft-ietf-ippm-asymmetrical-pkts-11.txt   draft-ietf-ippm-asymmetrical-pkts-12.txt 
Network Working Group G. Mirsky IPPM Working Group G. Mirsky
Internet-Draft Ericsson Internet-Draft Independent
Intended status: Standards Track E. Ruffini Intended status: Standards Track E. Ruffini
Expires: 24 August 2026 OutSys Expires: 16 September 2026 OutSys
H. Nydell H. Nydell
Cisco Systems Cisco Systems
R. Foote R. Foote
Nokia Nokia
W. Hawkins W. Hawkins
University of Cincinnati University of Cincinnati
20 February 2026 15 March 2026
Performance Measurement with Asymmetrical Traffic Using Simple Two-Way Performance Measurement with Asymmetrical Traffic Using Simple Two-Way
Active Measurement Protocol (STAMP) Active Measurement Protocol (STAMP)
draft-ietf-ippm-asymmetrical-pkts-11 draft-ietf-ippm-asymmetrical-pkts-12
Abstract Abstract
This document defines an optional STAMP extension that allows a This document defines an optional extension to the Simple Two-Way
Session-Reflector to send packets whose length or quantity differs Active Measurement Protocol (STAMP) that enables a Session-Reflector
from those sent by the Session-Sender. While standard STAMP to send asymmetrical packets, that is, response packets whose size or
exchanges packets symmetrically, some measurement scenarios benefit quantity differs from those sent by the Session-Sender. While
from asymmetric response packets to better reflect real application standard STAMP exchanges are symmetrical, certain measurement
conditions. This extension enables the Session-Reflector to send scenarios benefit from reflected packets of different lengths or
packets of different sizes and/or additional packets not tied one- additional responses to better approximate application traffic
for-one to incoming test packets. The document also analyzes conditions. The extension specifies the Reflected Test Packet
challenges in multicast performance monitoring and specifies STAMP Control TLV and associated procedures, analyzes challenges in active
procedures to improve measurement efficiency and reduce network performance measurement (including in multicast environments), and
impact. describes STAMP behaviors to improve measurement efficiency and
reduce network impact.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 August 2026. This Internet-Draft will expire on 16 September 2026.
Copyright Notice Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Terminology and Acronyms . . . . . . . . . . . . . . . . 3
2. Reflected Test Packet Control TLV . . . . . . . . . . . . . . 4 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.1. Address Group Sub-TLVs . . . . . . . . . . . . . . . . . 7 3. Reflected Test Packet Control TLV . . . . . . . . . . . . . . 4
2.1.1. Layer 2 Address Group Sub-TLV . . . . . . . . . . . . 7 3.1. Address Group Sub-TLVs . . . . . . . . . . . . . . . . . 7
2.1.2. Layer 3 Address Group Sub-TLV . . . . . . . . . . . . 8 3.1.1. Layer 2 Address Group Sub-TLV . . . . . . . . . . . . 7
3. Operational Considerations . . . . . . . . . . . . . . . . . 9 3.1.2. Layer 3 Address Group Sub-TLV . . . . . . . . . . . . 9
3.1. Rate Measurement . . . . . . . . . . . . . . . . . . . . 9 4. Operational Considerations . . . . . . . . . . . . . . . . . 10
3.1.1. Operational Considerations for Performing Rate 4.1. Rate Measurement . . . . . . . . . . . . . . . . . . . . 10
Measurement . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Operational Considerations for Performing Rate
3.2. Active Performance Measurement in Multicast Measurement . . . . . . . . . . . . . . . . . . . . . 10
Environment . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Active Performance Measurement in Multicast
3.3. Using Reflected Test Packet Control TLV in Combination with Environment . . . . . . . . . . . . . . . . . . . . . . . 11
Other TLVs . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Using Reflected Test Packet Control TLV in Combination with
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 Other TLVs . . . . . . . . . . . . . . . . . . . . . . . 12
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Reflected Test Packet Control TLV Type . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.2. Conformant Reflected Packet STAMP TLV Flag . . . . . . . 15 8.1. Reflected Test Packet Control TLV Type . . . . . . . . . 16
7.3. Layer 2 and Layer 3 Address Group Sub-TLV Types . . . . . 15 8.2. Conformant Reflected Packet STAMP TLV Flag . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.3. Layer 2 and Layer 3 Address Group Sub-TLV Types . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] defines Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] defines
the base STAMP functionalities. STAMP Optional Extensions [RFC8972] the base STAMP functionalities. STAMP Optional Extensions [RFC8972]
introduces a TLV structure that allows a Session-Sender to include introduces a TLV structure that allows a Session-Sender to include
optional instructions for Session-Reflectors to extend the optional instructions for Session-Reflectors to extend the
functionality of the base STAMP protocol. New STAMP TLVs can be functionality of the base STAMP protocol. New STAMP TLVs can be
defined to support scenarios like the ones described in [RFC7497], defined to support scenarios like the ones described in [RFC7497],
which discusses the coordination of messaging between the source and which discusses the coordination of messaging between the source and
destination to help deliver one of the fundamental principles of IP destination to help deliver one of the fundamental principles of IP
performance metric measurements, minimizing the test traffic effect performance metric measurements, minimizing the test traffic effect
on user flows. on user flows.
By default, a STAMP Session-Sender and a Session-Reflector exchange By default, a STAMP Session-Sender and a Session-Reflector exchange
packets symmetrically: the number of packets sent by the Session- packets symmetrically: the number of packets sent by the Session-
Reflector and the Session-Sender are the same and the length of the Reflector and the Session-Sender are the same and the length of the
packets sent by the Session-Reflector and the Session-Sender are the packets sent by the Session-Reflector and the Session-Sender are the
same. However, in some scenarios, e.g., rate measurements discussed same. However, in some scenarios, e.g., rate measurements discussed
in [RFC7497], it would be beneficial for a Session-Reflector to in [RFC7497], it would be beneficial for a Session-Reflector to
respond with Asymmetrical Test packets: packets whose length is not respond with asymmetrical test packets: packets whose length is not
symmetrical to test packet sent by the Session-Sender and/or packets symmetrical to the test packet sent by the Session-Sender and/or
that are not sent in direct response to a packet received from a packets that are not sent in direct response to a packet received
Session-Sender. The optional extension defined in this document from a Session-Sender. The optional extension defined in this
gives operators the tools to create such Asymmetrical Packets between document gives operators the tools to create such asymmetrical
a Session-Sender and a Session-Reflector. packets between a Session-Sender and a Session-Reflector.
Measurement of performance metrics in a multicast network using an Measurement of performance metrics in a multicast network using an
active measurement method (Section 3.4 of [RFC7799]) has specific active measurement method (Section 3.4 of [RFC7799]) has specific
challenges compared to what operators experience monitoring in a challenges compared to what operators experience monitoring in a
unicast network. This document analyzes these challenges and unicast network. This document analyzes these challenges and
specifies procedures and STAMP extensions to achieve more efficient specifies procedures and STAMP extensions to achieve more efficient
measurements with a lesser impact on a network. measurements with a lesser impact on a network.
1.1. Terminology 2. Conventions Used in This Document
2.1. Terminology and Acronyms
The document uses terms defined in [RFC8762], especially Session- The document uses terms defined in [RFC8762], especially Session-
Sender, Session-Reflector and Symmetrical Packets. Sender, Session-Reflector and symmetrical packets.
The document uses terms defined in [RFC8972], especially STAMP The document uses terms defined in [RFC8972], especially STAMP
Session Identifier (SSID), STAMP TLV Flags and Sub-TLVs. Session Identifier (SSID), STAMP TLV Flags and Sub-TLVs.
The document uses the terms In-Service and Out-of-Service defined in The document uses the terms In-Service and Out-of-Service defined in
[RFC7497]. [RFC7497].
In this document, "Asymmetrical Packets" has two meanings, depending In this document, "asymmetrical packets" has two meanings, depending
on the context. First, an Asymmetrical Packet means a packet sent by on the context. The first aspect is asymmetry in packet size between
a Session-Reflector with a size different from the packet sent by the a packet sent by a Session-Reflector and the packet it received from
Session-Sender. The second, third, fourth, etc. packets sent by the the Session-Sender. The second aspect is asymmetry in the number of
Session-Reflector in response to a single test packet received from a packets the Session-Reflector transmits in response to receiving a
Session-Sender are also referred to as Asymmetrical Packets. single STAMP test packet.
In this document, a Multicast Network means a network that sends data In this document, a multicast network means a communication network
from a single source to multiple destinations by transmitting a model where a sender transmits a single packet addressed to a
single packet to a single, specially designated address. multicast group, and the network delivers copies of that packet to
multiple receivers that have joined the group.
1.2. Requirements Language CE Congestion Experienced
ECN Early Congestion Notification
EUI Extended Unique Identifier
MAC Media Access Control address
STAMP Simple Two-way Active Measurement Protocol
TLV Type-Length-Value
2.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Reflected Test Packet Control TLV 3. Reflected Test Packet Control TLV
This section defines a new optional STAMP extension, Reflected Test This section defines an additional optional STAMP extension,
Packet Control TLV and a new STAMP TLV Flag value. The format of Reflected Test Packet Control TLV and an additional bit-flag in the
this TLV is presented in Figure 1. STAMP TLV Flags field. The format of this TLV is presented in
Figure 1.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type | Length | |STAMP TLV Flags| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Length of the Reflected Packet |Number of the Reflected Packets| |Length of the Reflected Packet |Number of the Reflected Packets|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interval Between the Reflected Packets | | Interval Between the Reflected Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs ~ ~ Sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Reflected Test Packet Control TLV Format Figure 1: Reflected Test Packet Control TLV Format
The descriptions of the fields are as follows: The descriptions of the fields are as follows:
STAMP TLV Flags is a one-octet field. STAMP TLV Flags is a one-octet field [RFC8972].
Type is a one-octet field that identifies the Reflected Test Type is a one-octet field that identifies the Reflected Test
Packet Control TLV. This field is set to TBA1 (Section 7.1). Packet Control TLV. This field is set to TBA1 (Section 8.1).
Length is a two-octet field. The value is variable, and MUST NOT Length is a two-octet field. The value is variable, and MUST NOT
be smaller than 12 octets. be smaller than 12 octets.
Length of the Reflected Packet is a two-octet field. The value is Length of the Reflected Packet is a two-octet field. The value is
an unsigned integer that is the requested length of a reflected an unsigned integer that is the requested length of a reflected
test packet in octets. test packet in octets.
Number of the Reflected Packets is a two-octet field. The value Number of the Reflected Packets is a two-octet field. The value
is an unsigned integer that is the number of reflected test is an unsigned integer that is the number of reflected test
skipping to change at page 5, line 24 skipping to change at page 5, line 48
Interval Between the Reflected Packets is a four-octet field. The Interval Between the Reflected Packets is a four-octet field. The
value is an unsigned integer set to the interval in nanoseconds value is an unsigned integer set to the interval in nanoseconds
between the transmission of the consecutive reflected test packets between the transmission of the consecutive reflected test packets
in response to receiving a STAMP test packet with the Reflected in response to receiving a STAMP test packet with the Reflected
Test Packet Control TLV. Test Packet Control TLV.
Sub-TLVs is an optional field that includes additional information Sub-TLVs is an optional field that includes additional information
communicated by a Session-Sender. communicated by a Session-Sender.
Also, a new STAMP TLV flag [RFC8972], Conformant Reflected Packet is Also, an additional STAMP TLV flag [RFC8972], Conformant Reflected
allocated by IANA from "STAMP TLV Flags" subregistry (Section 7.2): Packet is allocated by IANA from "STAMP TLV Flags" subregistry
the one-bit C flag (TBA4). A Session-Sender MUST zero this flag on (Section 8.2): the one-bit C flag (TBA4). A Session-Sender MUST zero
transmission, and the Session-Reflector MUST ignore its value on the this flag on transmission, and the Session-Reflector MUST ignore its
receipt of a STAMP test packet with a STAMP TLV. value on the receipt of a STAMP test packet with a STAMP TLV.
A Session-Sender MAY include the Reflected Test Packet Control TLV in A Session-Sender MAY include the Reflected Test Packet Control TLV in
a STAMP test packet. If the received STAMP test packet includes the a STAMP test packet. If the received STAMP test packet includes the
Reflected Test Packet Control TLV, the Session-Reflector MUST Reflected Test Packet Control TLV, the Session-Reflector MUST
transmit a sequence of reflected test packets according to the transmit a sequence of reflected test packets according to the
following rules: following rules:
The length of the reflected test packet MUST be the largest of The length of the reflected test packet MUST be the largest of
the: the:
skipping to change at page 6, line 7 skipping to change at page 6, line 29
to exclude any Extra Padding TLV present in combination with to exclude any Extra Padding TLV present in combination with
Reflected Test Packet Control TLV is to support a scenario when a Reflected Test Packet Control TLV is to support a scenario when a
Session-Reflector is requested to transmit a sequence of packets Session-Reflector is requested to transmit a sequence of packets
shorter than the received STAMP packet. shorter than the received STAMP packet.
b. The value in the Length of the Reflected Packet field of the b. The value in the Length of the Reflected Packet field of the
Reflected Test Packet Control TLV aligned at a four-octet Reflected Test Packet Control TLV aligned at a four-octet
boundary. boundary.
In a case where the length of the reflected packet calculated by this In a case where the length of the reflected packet calculated by this
rule is longer than the length of the reflected packet calculated by rule is longer than the length of the reflected packet calculated by
the rules in Section 3 of [RFC8972], the Session-Reflector MUST use the rules in Section 4 of [RFC8972], the Session-Reflector MUST use
the Extra Padding TLV (Section 4.1 of [RFC8972]) to increase the the Extra Padding TLV (Section 4.1 of [RFC8972]) to increase the
length of the reflected test packet. If the calculated length of the length of the reflected test packet. If the calculated length of the
reflected packet exceeds the maximum transmission unit (MTU) of the reflected packet exceeds the maximum transmission unit (MTU) of the
interface to reach the Session-Sender, the Session-Reflector MUST set interface to reach the Session-Sender, the Session-Reflector MUST set
the C (Conformant Reflected Packet) STAMP TLV flag (Section 7.2) to the C (Conformant Reflected Packet) STAMP TLV flag (Section 8.2) to
1, and MUST transmit a single reflected packet of the length equal to 1, and MUST transmit a single reflected packet of the length equal to
MTU of the egress interface. Otherwise, the Session-Reflector MUST MTU of the egress interface. Otherwise, the Session-Reflector MUST
set the C flag to 0 in each reflected test packet. set the C flag to 0 in each reflected test packet.
The number of reflected test packets in the sequence MUST equal the The number of reflected test packets in the sequence MUST equal the
value of the "Number of the Reflected Packets" field. value of the Number of the Reflected Packets field.
If the value of the "Number of the Reflected Packets" field is larger If the value of the Number of the Reflected Packets field is larger
than one, the interval between the transmission of two consecutive than one, the interval between the transmission of two consecutive
reflected packets in the sequence MUST be equal to the value in the reflected packets in the sequence MUST be equal to the value in the
"Interval Between the Reflected Packets" field in nanoseconds. To Interval Between the Reflected Packets field in nanoseconds. To
prevent excessive congestion caused by reflected packets, a prevent excessive congestion caused by reflected packets, a
Session-Reflector that supports the Reflected Test Control TLV MUST Session-Reflector that supports the Reflected Test Control TLV MUST
enforce limits on both the data rate (bytes per second) and the total enforce limits on both the data rate (bytes per second) and the total
data volume (bytes) of the STAMP payload it generates in response to data volume (bytes) of the STAMP payload it generates in response to
an incoming test packet. If a test packet is received that would an incoming test packet. If a test packet is received that would
generate traffic that exceeds either of these limits, the Session- generate traffic that exceeds either of these limits, the Session-
Reflector MUST set the C flag (Section 7.2) to 1, and MUST transmit a Reflector MUST set the C flag (Section 8.2) to 1, and MUST transmit a
single reflected packet of the length calculated by the rules listed single reflected packet of the length calculated by the rules listed
above. Otherwise, the Session-Reflector MUST set the C flag to 0 in above. Otherwise, the Session-Reflector MUST set the C flag to 0 in
each reflected test packet. each reflected test packet.
If the "Number of Reflected Packets" field is set to zero, the If the Number of Reflected Packets field is set to zero, the Session-
Session-Reflector MUST NOT send any reflected packets. By default, Reflector MUST NOT send any reflected packets. Furthermore, in this
the Session-Reflector MUST discard the received STAMP test packet. A case, the Session-Reflector SHOULD discard the received STAMP test
local policy MAY override this default behavior and specify packet. However, a local policy MAY override this default behavior
alternative handling. Note that this behavior of the Session- and specify an alternative handling. Note that this behavior of the
Reflector is demonstrated when the Control Code Flags field of the Session-Reflector is demonstrated when the Control Code Flags field
Return Path Control Code sub-TLV (Section 4.1.1 of [RFC9503]) is set of the Return Path Control Code sub-TLV (Section 4.1.1 of [RFC9503])
to No Reply Requested. If this the intended behavior, use of the is set to No Reply Requested. If this the intended behavior, use of
Return Path TLV is preferable. the Return Path TLV is preferable.
Each reflected test packet in the sequence is formed according to Each reflected test packet in the sequence is formed according to
Section 4.3 of [RFC8762]. Section 4.3 of [RFC8762].
As defined above, there are two cases when a Session-Reflector will As defined above, there are two cases when a Session-Reflector will
set the C flag in the reflected packet. To disambiguate which case set the C flag in the reflected packet. To disambiguate which case
led to the C flag being set to 1, an implementation of Session-Sender led to the C flag being set to 1, an implementation of a Session-
may use the following: Sender may use the following:
The requested length exceeds the MTU of the egress interface of The requested length exceeds the MTU of the egress interface of
the Session-Reflector if the length of the received reflected the Session-Reflector if the length of the received reflected
STAMP packet is less than the value of the Length of the STAMP packet is less than the value of the Length of the Reflected
"Reflected Packet" field. Packet field.
The requested data rate and/or the data volume exceed the limits The requested data rate and/or the data volume exceed the limits
set at the Session-Reflector if the length of the received set at the Session-Reflector if the length of the received
reflected STAMP packet equals the value of the Length of the reflected STAMP packet equals the value of the Length of the
"Reflected Packet" field. Reflected Packet field.
2.1. Address Group Sub-TLVs 3.1. Address Group Sub-TLVs
2.1.1. Layer 2 Address Group Sub-TLV 3.1.1. Layer 2 Address Group Sub-TLV
Layer 2 Address Group Sub-TLV: A 16-octet sub-TLV that includes the An optional Layer 2 Address Group sub-TLV is a variable-length sub-
EUI-48 Address Group Mask and EUI-48 Address Group. The Type of the TLV that includes a Layer 2 Address Group Mask and Address Group
sub-TLV is TBA2 (Section 7.3). The value of the sub-TLV Length field fields used by the Session-Sender to select the Session-Reflectors
MUST be equal to 12. The format of the Layer 2 Address Group Sub-TLV for a response. The Layer 2 Address Group sub-TLV can convey EUI-48
is presented in Figure 2. (Extended Unique Identifier), EUI-64 ([IEEE-802.3-2022], and a 16-bit
short address for local identification within a Personal Area Network
([IEEE-802.15.4-2024]). The format of the Layer 2 Address Group sub-
TLV is presented in Figure 2.
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Flags | Sub-TLV Type | Sub-TLV Length | | Sub-TLVFlags| Sub-TLV Type | Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EUI-48 Address Group Mask | ~ Layer 2 Address Group Mask (variable length) ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | ~ Layer 2 Address Group (varaible length) ~
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EUI-48 Address Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Layer 2 Address Group Sub-TLV Format Figure 2: Layer 2 Address Group Sub-TLV Format
The Value field of the Layer 2 Address Group Sub-TLV consists of the where:
Sub-TLV Type is a one-octet field. IANA is requested to assign
value TBA2 (Section 8.3).
Sub-TLV Length is a two-octet field whose value equals the length
of the Value field of the Layer 2 Address Group sub-TLV in octets.
Because lengths of MAC Address Group Mask and MAC Address Group
fields MUST be equal, valid values for the Sub-TLV Length are 4,
12, and 16. Any other value MUST be considered by the Session-
Reflector as a malformed sub-TLV.
The Value field of the Layer 2 Address Group sub-TLV consists of the
following fields: following fields:
EUI-48 Address Group Mask: A six-octet field that represents the Layer 2 Address Group Mask: A field that represents the bitmask to
bitmask to be applied to all MAC addresses associated with the be applied to all MAC addresses associated with the Session-
Session-Reflector. Reflector. The length of the field is 1/2 the value of the sub-
TLV Length field.
EUI-48 Address Group: A six-octet field that represents the group Layer 2 Address Group: A field that represents the group to which
that this TLV is addressed to. If the Session-Reflector applies this TLV is addressed. The length of the field is 1/2 the value
the EUI-48 Address Group Mask to its MAC address and the result is of the sub-TLV Length field.
equal to the EUI-48 Address Group, then the Session-Reflector MUST
stop processing the Layer 2 Address Group sub-TLV and continue
processing the received test packet. If no matches are found, the
Session-Reflector MUST stop processing the received packet.
2.1.2. Layer 3 Address Group Sub-TLV If the Session-Reflector applies the value of the Layer 2 Address
Group Mask field (using a bitwise AND) to any of its MAC addresses
with the same length and the result is equal to the value of the
Layer 2 Address Group field, then the Session-Reflector MUST stop
processing the Layer 2 Address Group sub-TLV and continue processing
the received test packet. If no matches are found, the Session-
Reflector MUST stop processing the received packet.
Layer 3 Address Group Sub-TLV: A variable-length sub-TLV that 3.1.2. Layer 3 Address Group Sub-TLV
includes the IP address family, IP prefix, and IP prefix length. The
Type of the sub-TLV is TBA3 (Section 7.3). The value of the sub-TLV
Length field MUST be equal to 8 if the value of the Address Family
field is set to 1 (i.e., IPv4). The value of the sub-TLV Length
field MUST be equal to 20 if the value of the Address Family field is
set to 2 (i.e., IPv6). The format of Layer 3 Address Group Sub-TLV
is presented in Figure 3.
0 1 2 3 An optional Layer 3 Address Group sub-TLV is a variable-length sub-
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 TLV that includes the IP prefix and IP prefix length fields used by
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the Session-Sender to select the Session-Reflectors for a response.
| Sub-TLV Flags | Sub-TLV Type | Sub-TLV Length | The format of Layer 3 Address Group sub-TLV is presented in Figure 3.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family| Prefix Length | Reserved | 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
~ IP Prefix ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Flags | Sub-TLV Type | Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IP Prefix ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Layer 3 Address Group Sub-TLV Format Figure 3: Layer 3 Address Group Sub-TLV Format
The Value field of the Layer 3 Address Group Sub-TLV consists of the where:
following fields:
Address Family: A one-octet field that indicates the type of the Sub-TLV Type is a one-octet field. IANA is requested to assign
IP address contained in the "IP Prefix" field. If that is IPv4 value TBA3 (Section 8.3).
address, then the value MUST be set to 1. For an IPv6 address,
the value MUST be set to 2. Other values MUST be considered Sub-TLV Length is a two-octet field whose value equals either 8,
invalid. if the IP Prefix is the prefix for an IPv4 address, or 20 if the
IP Prefix is the prefix for an IPv6 address. Any other value MUST
be considered by the Session-Reflector as a malformed sub-TLV.
The Value field of the Layer 3 Address Group sub-TLV consists of the
following fields:
Prefix Length: A one-octet unsigned integer field that contains Prefix Length: A one-octet unsigned integer field that contains
the length, in bits, of the prefix of the value in the "IP Prefix" the length, in bits, of the prefix of the value in the IP Prefix
field. field
Reserved: A two-octet field. The field MUST be set to zeros on Reserved: A three-octet field. The field MUST be set to zeros on
transmission and ignored on receipt. transmission and ignored on receipt.
IP Prefix: A variable-length field. Depending on the value of the IP Prefix: A variable-length field. The length of the field is
"Address Family" field, the field contains either an IPv4 or IPv6 four octets if the IP Prefix is the prefix for an IPv4 address, or
address. If the former, the length is four octets; if the latter 16 if the IP Prefix is the prefix for an IPv6 address.
- 16 octets.
The Layer 3 Address Group sub-TLV applies to all IP addresses When processing this sub-TLV, the Session-Reflector will construct an
associated with the Session-Reflector. If an IP address of the IP mask according to the value, n, in the Prefix Length field. The
Session-Reflector, when masked by the value in the IP Prefix field, IP mask will be an IP address (of the family specified by the value
matches the value of the IP Prefix, the Session-Reflector MUST stop of the Sub-TLV Length field, according to the semantics above) where
processing the Layer 3 Address Group sub-TLV and continue processing the n most-significant bits are set to 1 and all other bits are set
the received packet. If no matches are found, the Session-Reflector to 0. Once the mask is constructed, if the Session-Reflector applies
MUST stop processing the received packet. it (using a bitwise AND) to any of its IP addresses of the same
family and the result is equal to the value in the IP Prefix field,
then the Session-Reflector MUST stop processing the Layer 3 Address
Group sub-TLV and continue processing the received test packet. If
no matches are found, the Session-Reflector MUST stop processing the
received packet.
3. Operational Considerations 4. Operational Considerations
3.1. Rate Measurement 4.1. Rate Measurement
[RFC7497] defines the problem of access rate measurement in access [RFC7497] defines the problem of access rate measurement in access
networks. Essential requirements identified for a test protocol are networks. Essential requirements identified for a test protocol are
the ability to control packet characteristics on the tested path, the ability to control packet characteristics on the tested path,
such as asymmetric rate and asymmetric packet size. The Reflected such as asymmetric rate and asymmetric packet size. The Reflected
Test Packet Control TLV, defined in Section 2, conforms to the Test Packet Control TLV, defined in Section 3, conforms to the
requirements for measuring access rate by providing optional controls requirements for measuring access rate by providing optional controls
of the number of reflected test packets, the size of the reflected of the number of reflected test packets, the size of the reflected
packet(s), and the time interval, i.e., rate, in transmitting the packet(s), and the time interval, i.e., rate, in transmitting the
sequence of the reflected test packets. The access rate metric and sequence of the reflected test packets. The access rate metric and
method of access rate measurement are out of the scope of this method of access rate measurement are out of the scope of this
document. The UDP Speed Test ([RFC9097] and document. The UDP Speed Test ([RFC9097] and
[I-D.ietf-ippm-capacity-protocol]) also allows for the measurement of [I-D.ietf-ippm-capacity-protocol]) also allows for the measurement of
access bandwidth. access bandwidth.
3.1.1. Operational Considerations for Performing Rate Measurement 4.1.1. Operational Considerations for Performing Rate Measurement
General considerations for using a testing protocol for rate General considerations for using a testing protocol for rate
measurement are documented in Section 7 of [RFC7497]. These measurement are documented in Section 7 of [RFC7497]. These
considerations are specific for In-Service and Out-of-Service (using considerations are specific for In-Service and Out-of-Service (using
the terminology of [RFC7497]) rate measurement. In the Out-of- the terminology of [RFC7497]) rate measurement. In the Out-of-
Service testing, an operator may use a very high traffic rate and/or Service testing, an operator may use a very high traffic rate and/or
volume (i.e., high values for the Length of the Reflected Packet and/ volume (i.e., high values for the Length of the Reflected Packet and/
or Number of the Reflected Packets parameters, and/or low values for or Number of the Reflected Packets parameters, and/or low values for
the Interval Between the Reflected Packets parameter of the Reflected the Interval Between the Reflected Packets parameter of the Reflected
Test Packet Control TLV) to create congestion in the bottleneck. Test Packet Control TLV) to create congestion in the bottleneck.
However, when performing In-Service rate testing, an operator may However, when performing In-Service rate testing, an operator may
start with a low rate and/or volume and gradually increase them with start with a low rate and/or volume and gradually increase them with
each transmitted Reflected Test Packet Control TLV. each transmitted Reflected Test Packet Control TLV.
3.2. Active Performance Measurement in Multicast Environment A service subscriber performing extensive rate measurements on the
operational network, SHOULD consider the Consideration 6 in
Section 10 of [I-D.ietf-ippm-capacity-protocol].
4.2. Active Performance Measurement in Multicast Environment
For performance measurements using STAMP in a multicast environment, For performance measurements using STAMP in a multicast environment,
a Session-Sender is expected to be the root and Session-Reflectors a Session-Sender is expected to be the root and Session-Reflectors
leaves of the same multicast distribution tree. The mechanism of are the leaves of the same multicast distribution tree. The
constructing the multicast tree is outside the scope of this mechanism of constructing the multicast tree is outside the scope of
document. this document.
According to [RFC8972], a STAMP Session is demultiplexed by a According to [RFC8972], a STAMP Session is demultiplexed by a
Session-Reflector by the tuple that consists of source and Session-Reflector by the tuple that consists of source and
destination IP addresses, source and destination UDP port numbers, or destination IP addresses, source and destination UDP port numbers, or
the source IP address and STAMP Session Identifier. That is also the the source IP address and STAMP Session Identifier. That is also the
case when monitoring performance of a multicast flow, despite the case when monitoring performance of a multicast flow, despite the
fact that the destination IP address is a multicast address. fact that the destination IP address is a multicast address.
Therefore, there is no special behavior defined for a Session- Therefore, there is no special behavior defined for a Session-
Reflector upon receiving a STAMP test packet over a multicast tree. Reflector upon receiving a STAMP test packet over a multicast tree.
It processes the packet according to [RFC8762] and [RFC8972]. The It processes the packet according to [RFC8762] and [RFC8972]. The
Session-Reflector MUST use the source IP address of the received Session-Reflector MUST use the source IP address of the received
STAMP test packet as the destination IP address of the reflected test STAMP test packet as the destination IP address of the reflected test
packet, and MUST use one of the IP addresses associated with the node packet, and MUST use one of the IP addresses associated with the node
as the source IP address for that packet. As a result, a Session- as the source IP address for that packet. As a result, a Session-
Sender may receive multiple replies from multiple counterparts Sender may receive multiple replies from multiple counterpart
Session-Reflectors. Such a Session-Sender may include a Reflected Session-Reflectors. Such a Session-Sender may include a Reflected
Test Packet Control TLV and include either a Layer 2 Address Group Test Packet Control TLV and include either a Layer 2 Address Group
Sub-TLV or Layer 3 Address Group Sub-TLV to limit the Session- sub-TLV or a Layer 3 Address Group sub-TLV to limit the Session-
Reflectors that respond. Reflectors that respond.
The multicast environment itself could be configured to help The multicast environment itself could be configured to help
alleviate the possibility that network congestion may occur if a alleviate the possibility that network congestion may occur if a
single test packet generates a large number of concurrent replies, single test packet generates a large number of concurrent replies,
all directed to the same endpoint. Depending on the multicast- all directed to the same endpoint. Depending on the multicast-
implementation, adding the Reflected Test Packet Control TLV could implementation, adding the Reflected Test Packet Control TLV could
allow the multicast environment to limit the number of replies by allow the multicast environment to limit the number of replies by
updating fields of any STAMP packets it sees by modifying their updating fields of any STAMP packets it sees by modifying their
Reflected Test Packet Control TLV Sub-TLV values: Reflected Test Packet Control TLV Sub-TLV values:
Randomly by specifying a Layer 2 Address Group Sub-TLV: for Randomly by specifying a Layer 2 Address Group sub-TLV: for
example, setting the EUI-48 Address Group Mask to 0xF and the example, setting the EUI-48 Address Group Mask to 0xF and the
EUI-48 Address Group to 0x1. As a result, only 1 out of 16 EUI-48 Address Group to 0x1. As a result, only 1 out of 16
reflectors will reply; reflectors will reply;
Having a specific vendor NIC by specifying a Layer 2 Address Group Having a specific vendor NIC by specifying a Layer 2 Address Group
Sub-TLV with the EUI-48 Address Group Mask set to 0xFFFFFF000000; sub-TLV with the EUI-48 Address Group Mask set to 0xFFFFFF000000;
Belonging to specific IP networks, for example, a subnet dedicated Belonging to specific IP networks, for example, a subnet dedicated
to IPv6 over IPv4 encapsulation by specifying the appropriate to IPv6 over IPv4 encapsulation by specifying the appropriate
Layer 3 Address Group Sub-TLV. Layer 3 Address Group sub-TLV.
Multicast traffic is also intrinsically asymmetrical, and focus on Multicast traffic is also intrinsically asymmetrical. The upstream
the return path is usually limited. The Length of the Reflected (source-to-receiver) direction typically dominates, while the return
Packet value can be used to ensure the reflected packet transports path receives limited attention because multicast communication is
all the timestamps and requested information, crucial for the primarily one-to-many and generates comparatively little downstream
underlying measure, but is as short as possible so as not to flood or receiver-to-source traffic. The Length of the Reflected Packet
the network with useless data. value can be used to ensure the reflected packet transports all the
timestamps and requested information, crucial for the underlying
measure, but is as short as possible so as not to flood the network
with useless data.
3.3. Using Reflected Test Packet Control TLV in Combination with Other 4.3. Using Reflected Test Packet Control TLV in Combination with Other
TLVs TLVs
[RFC9503] defines the Return Path TLV which, when used in combination [RFC9503] defines the Return Path TLV which, when used in combination
with the Return Address Sub-TLV, allows a Session-Sender to request with the Return Address Sub-TLV, allows a Session-Sender to request
the reflected packet be sent to a different address from the Session- the reflected packet be sent to a different address from the Session-
Sender one. These STAMP extensions could be used in combination with Sender one. These STAMP extensions could be used in combination with
the Reflected Packet Control TLV, defined in this document, to direct the Reflected Packet Control TLV, defined in this document, to direct
the reflected STAMP test packets to a collector of measurement data the reflected STAMP test packets to a collector of measurement data
(according to [RFC7594]) for further processing and network (according to [RFC7594]) for further processing and network
analytics. An example of the use case is a multicast scenario when, analytics. An example of the use case is a multicast scenario when,
skipping to change at page 11, line 37 skipping to change at page 13, line 5
Control TLVs in the reflected STAMP packet. Furthermore, the Control TLVs in the reflected STAMP packet. Furthermore, the
Session-Reflector SHOULD log a notification to inform an operator Session-Reflector SHOULD log a notification to inform an operator
about the misconstructed STAMP packet. about the misconstructed STAMP packet.
Reflected Test Packet Control TLV can be combined with the Class of Reflected Test Packet Control TLV can be combined with the Class of
Service TLV [RFC8972] to augment rate testing or testing in a Service TLV [RFC8972] to augment rate testing or testing in a
multicast network with monitoring the consistency of Differentiated multicast network with monitoring the consistency of Differentiated
Services Code Point and Explicit Congestion Notification values in Services Code Point and Explicit Congestion Notification values in
forward and reverse directions of the particular STAMP test session. forward and reverse directions of the particular STAMP test session.
4. Security Considerations 5. Security Considerations
Security considerations discussed in [RFC7497], [RFC8762],[RFC8972], Security considerations discussed in [RFC7497], [RFC8762],[RFC8972],
and [RFC9503] apply to this document. Furthermore, spoofed STAMP and [RFC9503] apply to this document. Furthermore, spoofed STAMP
test packets with the Reflected Test Packet Control TLV can be test packets with the Reflected Test Packet Control TLV can be
exploited to conduct a Denial-of-Service (DoS) attack. Hence, exploited to conduct a Denial-of-Service (DoS) attack. Hence,
implementations MUST use an identity protection mechanism. For implementations MUST use an identity protection mechanism. For
example, the Session-Reflector may verify the information about the example, the Session-Reflector may verify the information about the
source of the STAMP packet against a pre-defined list of trusted source of the STAMP packet against a pre-defined list of trusted
nodes. Furthermore, an implementation that supports this nodes. Furthermore, an implementation that supports this
specification MUST provide administrative control of support of the specification MUST provide administrative control of support of the
skipping to change at page 12, line 13 skipping to change at page 13, line 30
if integrity protection is enabled, any in-path modification will if integrity protection is enabled, any in-path modification will
cause verification to fail unless the modifying element is within the cause verification to fail unless the modifying element is within the
trust boundary and can recompute the integrity check. trust boundary and can recompute the integrity check.
Furthermore, a DoS attack using the Reflected Test Packet Control TLV Furthermore, a DoS attack using the Reflected Test Packet Control TLV
might target the STAMP Session-Reflector by overloading it with test might target the STAMP Session-Reflector by overloading it with test
packet reflection, e.g., minuscule intervals and/or an excessive packet reflection, e.g., minuscule intervals and/or an excessive
number of concurrent test sessions. To mitigate that, a Session- number of concurrent test sessions. To mitigate that, a Session-
Reflector implementation that supports the new TLV MUST provide a Reflector implementation that supports the new TLV MUST provide a
mechanism to limit the reflection rate and volume of STAMP test mechanism to limit the reflection rate and volume of STAMP test
packets (see Section 2 for detailed discussion). packets (see Section 3 for detailed discussion).
Considering the potential number of reflected packets generated by a Considering the potential number of reflected packets generated by a
single test packet sent to a multicast address, parameters in the single test packet sent to a multicast address, parameters in the
first STAMP test packet with the Reflected Test Packet Control TLV first STAMP test packet with the Reflected Test Packet Control TLV
MUST be selected conservatively. Consider the Number of the MUST be selected conservatively. Consider the Number of the
Reflected Packets field value set to one. As a result, a Session- Reflected Packets field value set to one. As a result, a Session-
Sender, by counting the packets reflected after originating a first Sender, by counting the packets reflected after originating a first
STAMP test packet with the Reflected Test Packet Control TLV, can STAMP test packet with the Reflected Test Packet Control TLV, can
evaluate the load caused by using the Reflected Test Packet Control evaluate the load caused by using the Reflected Test Packet Control
TLV in which more than a single reflected packet to the same TLV in which more than a single reflected packet to the same
skipping to change at page 12, line 35 skipping to change at page 13, line 52
the Reflected Test Packet Control TLV in a multicast network further, the Reflected Test Packet Control TLV in a multicast network further,
a Session-Sender SHOULD sign packets using the HMAC TLV when sending a Session-Sender SHOULD sign packets using the HMAC TLV when sending
such messages in unauthenticated mode [RFC8762]. But even with the such messages in unauthenticated mode [RFC8762]. But even with the
HMAC TLV, the Reflected Test Packet Control TLV could be exploited by HMAC TLV, the Reflected Test Packet Control TLV could be exploited by
a replay attack. To mitigate that risk, a STAMP Session-Reflector a replay attack. To mitigate that risk, a STAMP Session-Reflector
SHOULD use the value of the Sequence Number field [RFC8762] of the SHOULD use the value of the Sequence Number field [RFC8762] of the
received STAMP test packet. If that value compared to the received received STAMP test packet. If that value compared to the received
in the previous test packet of the same STAMP test session is not in the previous test packet of the same STAMP test session is not
monotonically increasing, then the Session-Reflector MUST respond monotonically increasing, then the Session-Reflector MUST respond
with a single reflected packet, setting the U flag to 1 [RFC8972]. with a single reflected packet, setting the U flag to 1 [RFC8972].
That may not indicate the replay attack, but there's packet re- That may not indicate a replay attack, but there's packet re-ordering
ordering or packet duplication in the network. An operator can use or packet duplication in the network. An operator can use other
other diagnostic methods to characterize and localize the problem. diagnostic methods to characterize and localize the problem. An
An implementation of the Session-Reflector can use the Serial Number implementation of the Session-Reflector can use the Serial Number
Arithmetic ([RFC1982]) or any of the other methods to verify the Arithmetic ([RFC1982]) or any of the other methods to verify the
correct ordering of test packets. correct ordering of test packets.
A Session-Sender SHOULD NOT send the next STAMP test packet with the A Session-Sender SHOULD NOT send the next STAMP test packet with the
Reflected Test Packet Control TLV before the Session-Reflector is Reflected Test Packet Control TLV before the Session-Reflector is
expected to complete transmitting all reflected packets in response expected to complete transmitting all reflected packets in response
to the Reflected Test Packet Control TLV in the previous test packet. to the Reflected Test Packet Control TLV in the previous test packet.
In some scenarios the Reflected Test Packet Control TLV might induce In some scenarios the Reflected Test Packet Control TLV might induce
congestion on the transient bottleneck. Section 10 of [RFC9097] congestion on the transient bottleneck. Section 10 of [RFC9097]
specifies security requirements for capacity measurements with specifies security requirements for capacity measurements with
asymmetric UDP loads. When planning In-Service capacity measurement asymmetric UDP loads.
operators SHOULD follow recommendations formulated in Section 7 of
[RFC7497]. Section 3.1.5 of [RFC8085] determines that a UDP When planning In-Service capacity measurement operators SHOULD follow
recommendations formulated in Sections 3 and 7 of [RFC7497]. If the
underlay network is ECN-capable, a Session-Reflector may receive
STAMP test packets with the ECN field marked as Congestion
Experienced (CE). ECN markings provide an indication of incipient
congestion rather than packet loss. However, the interpretation of
what constitutes "significant congestion" and the operational
thresholds for reacting to ECN-CE depend on the specific deployment,
service objectives, and operator policy. Operators should be aware
that In-Service capacity measurements may influence congestion
conditions, potentially contributing to ECN-CE marking in the
network. Implementations and operational procedures SHOULD ensure
that the use of STAMP for In-Service measurement does not
unintentionally degrade data traffic or lead to misinterpretation of
ECN-related congestion signals. Appropriate thresholds and
mitigation actions remain deployment-specific and SHOULD be guided by
operator policy and network performance objectives.
Furthermore, Section 3.1.5 of [RFC8085] determines that a UDP
congestion control SHOULD respond quickly to experienced congestion congestion control SHOULD respond quickly to experienced congestion
and account for loss rate and response time when choosing a new rate. and account for loss rate and response time when choosing a new rate.
Appendix A of [RFC9097] offers sample pseudocode for a UDP load rate And Section 8.1 of [RFC9097] specifies the load rate adjustment
adjustment algorithm with congestion control. algorithm with its sample pseudocode offered in Appendix A.
5. Implementation Status 6. Implementation Status
Note to RFC Editor: This section MUST be removed before publication Note to RFC Editor: This section MUST be removed before publication
of the document. of the document.
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942]. Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
skipping to change at page 13, line 47 skipping to change at page 15, line 33
- The implementation's name: Teaparty. - The implementation's name: Teaparty.
- A brief general description: Teaparty is an open source - A brief general description: Teaparty is an open source
implementation of the Simple Two-Way Active Measurement Protocol and implementation of the Simple Two-Way Active Measurement Protocol and
many of the optional extensions. The implementation can function as many of the optional extensions. The implementation can function as
a Session-Sender and Session-Reflector. It contains support for a Session-Sender and Session-Reflector. It contains support for
Authenticated and Unauthenticated modes. It also contains an Authenticated and Unauthenticated modes. It also contains an
implementation of a STAMP dissector for Wireshark. implementation of a STAMP dissector for Wireshark.
- The implementation's level of maturity: Interoperable with Junos OS - The implementation's level of maturity: Interoperable with Junos OS
Evolved STAMP/TWAMP-Light implementations (https://www.juniper.net/do Evolved STAMP/TWAMP-Light implementations
cumentation/us/en/software/junos/standards/topics/concept/rpm.html), (https://www.juniper.net/documentation/us/en/software/junos/standards/
Nokia's TWAMP Light implementation (https://github.com/nokia/twampy), topics/concept/rpm.html), Nokia's TWAMP Light implementation
and Cujo's TWAMP Light implementation (https://github.com/getCUJO/ (https://github.com/nokia/twampy), and Cujo's TWAMP Light
twamp-light). implementation (https://github.com/getCUJO/twamp-light).
- Coverage: Includes support for: - Coverage: Includes support for:
* Authenticated and Unauthenticated modes * Authenticated and Unauthenticated modes
* Stateless and stateful operation * Stateless and stateful operation
* 9 standardized and to-be standardized extensions * 9 standardized and to-be standardized extensions
- Version compatibility: N/A - Version compatibility: N/A
skipping to change at page 14, line 39 skipping to change at page 16, line 27
or not (a complete implementation of the Access Report extension or not (a complete implementation of the Access Report extension
requires such support). Overall, implementation was straightforward. requires such support). Overall, implementation was straightforward.
- Contact information: Source code is available at - Contact information: Source code is available at
https://github.com/cerfcast/teaparty. Author is available at https://github.com/cerfcast/teaparty. Author is available at
https://datatracker.ietf.org/person/hawkinsw@obs.cr https://datatracker.ietf.org/person/hawkinsw@obs.cr
- The date when information about this particular implementation was - The date when information about this particular implementation was
last updated: April 28, 2025 last updated: April 28, 2025
6. Acknowledgments 7. Acknowledgments
The authors thank Zhang Li, Ruediger Geib, Rakesh Gandhi, Giuseppe The authors thank Zhang Li, Ruediger Geib, Rakesh Gandhi, Giuseppe
Fiocolla, Xiao Min, Greg White, and Rohan Bhosle for their thorough Fiocolla, Xiao Min, Greg White, and Rohan Bhosle for their thorough
reviews and helpful suggestions, which improved the document. reviews and helpful suggestions, which improved the document.
7. IANA Considerations 8. IANA Considerations
Note to the RFC Editor: Please update all TBA1/TBA2/TBA3/TBA4 through Note to the RFC Editor: Please update all TBA1/TBA2/TBA3/TBA4 through
the document with the values assigned by IANA. the document with the values assigned by IANA.
7.1. Reflected Test Packet Control TLV Type 8.1. Reflected Test Packet Control TLV Type
IANA is requested to assign a new value for the Reflected Test Packet IANA is requested to assign a new value for the Reflected Test Packet
Control TLV from the STAMP TLV Types registry under the "Simple Two- Control TLV from the STAMP TLV Types registry under the "Simple Two-
way Active Measurement Protocol (STAMP) TLV Types" registry group way Active Measurement Protocol (STAMP) TLV Types" registry group
according to Table 1. according to Table 1.
+=======+===============================+===============+ +=======+===============================+===============+
| Value | Description | Reference | | Value | Description | Reference |
+=======+===============================+===============+ +=======+===============================+===============+
| TBA1 | Reflected Test Packet Control | This document | | TBA1 | Reflected Test Packet Control | This document |
+-------+-------------------------------+---------------+ +-------+-------------------------------+---------------+
Table 1: New Reflected Test Packet Control Type TLV Table 1: New Reflected Test Packet Control Type TLV
7.2. Conformant Reflected Packet STAMP TLV Flag 8.2. Conformant Reflected Packet STAMP TLV Flag
IANA is requested to allocate a bit position for the Conformant IANA is requested to allocate a bit position for the Conformant
Reflected Packet flag from the "STAMP TLV Flags" registry under the Reflected Packet flag from the "STAMP TLV Flags" registry under the
"Simple Two-way Active Measurement Protocol (STAMP) TLV Types" "Simple Two-way Active Measurement Protocol (STAMP) TLV Types"
registry group according to Table 2. registry group according to Table 2.
+==============+========+=============+===============+ +==============+========+=============+===============+
| Bit position | Symbol | Description | Reference | | Bit position | Symbol | Description | Reference |
+==============+========+=============+===============+ +==============+========+=============+===============+
| TBA4 | C | Conformance | This document | | TBA4 | C | Conformance | This document |
+--------------+--------+-------------+---------------+ +--------------+--------+-------------+---------------+
Table 2: Conformant Reflected Packet STAMP TLV Flag Table 2: Conformant Reflected Packet STAMP TLV Flag
7.3. Layer 2 and Layer 3 Address Group Sub-TLV Types 8.3. Layer 2 and Layer 3 Address Group Sub-TLV Types
IANA is requested to assign new values for the Layer 2 and Layer 3 IANA is requested to assign new values for the Layer 2 Address Group
Address Group Sub-TLV Types from the "STAMP Sub-TLV Types" registry and Layer 3 Address Group sub-TLV Types from the "STAMP Sub-TLV
under the "Simple Two-way Active Measurement Protocol (STAMP) TLV Types" registry under the "Simple Two-way Active Measurement Protocol
Types" registry group according to Table 3. (STAMP) TLV Types" registry group according to Table 3.
+=======+=======================+================+===============+ +=======+=======================+================+===============+
| Value | Description | TLV Used | Reference | | Value | Description | TLV Used | Reference |
+=======+=======================+================+===============+ +=======+=======================+================+===============+
| TBA2 | Layer 2 Address Group | Reflected Test | This document | | TBA2 | Layer 2 Address Group | Reflected Test | This document |
| | | Packet Control | | | | | Packet Control | |
+-------+-----------------------+----------------+---------------+ +-------+-----------------------+----------------+---------------+
| TBA3 | Layer 3 Address Group | Reflected Test | This document | | TBA3 | Layer 3 Address Group | Reflected Test | This document |
| | | Packet Control | | | | | Packet Control | |
+-------+-----------------------+----------------+---------------+ +-------+-----------------------+----------------+---------------+
Table 3: STAMP Sub-TLV Types for the Reflected Test Packet Table 3: STAMP Sub-TLV Types for the Reflected Test Packet
Control TLV Control TLV
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
DOI 10.17487/RFC1982, August 1996, DOI 10.17487/RFC1982, August 1996,
<https://www.rfc-editor.org/info/rfc1982>. <https://www.rfc-editor.org/info/rfc1982>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 17, line 11 skipping to change at page 18, line 31
Protocol Optional Extensions", RFC 8972, Protocol Optional Extensions", RFC 8972,
DOI 10.17487/RFC8972, January 2021, DOI 10.17487/RFC8972, January 2021,
<https://www.rfc-editor.org/info/rfc8972>. <https://www.rfc-editor.org/info/rfc8972>.
[RFC9503] Gandhi, R., Ed., Filsfils, C., Chen, M., Janssens, B., and [RFC9503] Gandhi, R., Ed., Filsfils, C., Chen, M., Janssens, B., and
R. Foote, "Simple Two-Way Active Measurement Protocol R. Foote, "Simple Two-Way Active Measurement Protocol
(STAMP) Extensions for Segment Routing Networks", (STAMP) Extensions for Segment Routing Networks",
RFC 9503, DOI 10.17487/RFC9503, October 2023, RFC 9503, DOI 10.17487/RFC9503, October 2023,
<https://www.rfc-editor.org/info/rfc9503>. <https://www.rfc-editor.org/info/rfc9503>.
8.2. Informative References 9.2. Informative References
[I-D.ietf-ippm-capacity-protocol] [I-D.ietf-ippm-capacity-protocol]
Ciavattone, L. and R. Geib, "UDP Speed Test Protocol for Ciavattone, L. and R. Geib, "UDP Speed Test Protocol for
One-way IP Capacity Metric Measurement", Work in Progress, One-way IP Capacity Metric Measurement", Work in Progress,
Internet-Draft, draft-ietf-ippm-capacity-protocol-25, 16 Internet-Draft, draft-ietf-ippm-capacity-protocol-25, 16
September 2025, <https://datatracker.ietf.org/doc/html/ September 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-ippm-capacity-protocol-25>. draft-ietf-ippm-capacity-protocol-25>.
[IEEE-802.15.4-2024]
"IEEE Standard for Low-Rate Wireless Networks",
IEEE Standard for Low-Rate Wireless Networks, December
2024.
[IEEE-802.3-2022]
"IEEE Standard for Ethernet", IEEE Standard for Ethernet,
July 2022.
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A Framework for Large-Scale Aitken, P., and A. Akhter, "A Framework for Large-Scale
Measurement of Broadband Performance (LMAP)", RFC 7594, Measurement of Broadband Performance (LMAP)", RFC 7594,
DOI 10.17487/RFC7594, September 2015, DOI 10.17487/RFC7594, September 2015,
<https://www.rfc-editor.org/info/rfc7594>. <https://www.rfc-editor.org/info/rfc7594>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>. May 2016, <https://www.rfc-editor.org/info/rfc7799>.
skipping to change at page 17, line 47 skipping to change at page 19, line 32
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC9097] Morton, A., Geib, R., and L. Ciavattone, "Metrics and [RFC9097] Morton, A., Geib, R., and L. Ciavattone, "Metrics and
Methods for One-Way IP Capacity", RFC 9097, Methods for One-Way IP Capacity", RFC 9097,
DOI 10.17487/RFC9097, November 2021, DOI 10.17487/RFC9097, November 2021,
<https://www.rfc-editor.org/info/rfc9097>. <https://www.rfc-editor.org/info/rfc9097>.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
Ericsson Independent
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
Ernesto Ruffini Ernesto Ruffini
OutSys OutSys
Email: eruffini@outsys.org Email: eruffini@outsys.org
Henrik Nydell Henrik Nydell
Cisco Systems Cisco Systems
Email: hnydell@cisco.com Email: hnydell@cisco.com
 End of changes. 76 change blocks. 
220 lines changed or deleted 294 lines changed or added

This html diff was produced by rfcdiff 1.49. The latest version is available from https://github.com/ietf-tools/rfcdiff