rfc9946v1.txt   rfc9946.txt 
Internet Engineering Task Force (IETF) A. Morton Internet Engineering Task Force (IETF) A. Morton
Request for Comments: 9946 Request for Comments: 9946 L. Ciavattone
Category: Standards Track L. Ciavattone Category: Standards Track AT&T Labs
ISSN: 2070-1721 AT&T Labs ISSN: 2070-1721 R. Geib, Ed.
R. Geib, Ed.
Deutsche Telekom Deutsche Telekom
March 2026 March 2026
The UDP Speed Test Protocol for One-Way IP Capacity Metric Measurement The UDP Speed Test Protocol for One-Way IP Capacity Metric Measurement
Abstract Abstract
This document addresses the problem of protocol support for measuring This document addresses the problem of protocol support for measuring
One-Way IP Capacity metrics specified by RFC 9097. The Method of One-Way IP Capacity metrics specified by RFC 9097. The Method of
Measurement discussed in that RFC requires a feedback channel from Measurement discussed in that RFC requires a feedback channel from
the receiver to control the sender's transmission rate in near real- the receiver to control the sender's transmission rate in near real-
time. This document defines the UDP Speed Test Protocol (UDPSTP) for time. This document defines the UDP Speed Test Protocol (UDPSTP) for
conducting RFC 9097 and other related measurements. conducting measurements as described in RFC 9097 and other related
measurements.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
skipping to change at line 103 skipping to change at line 103
11.1. New User Port Number Assignment 11.1. New User Port Number Assignment
11.2. New KeyTable KDF 11.2. New KeyTable KDF
11.3. New UDPSTP Registry Group 11.3. New UDPSTP Registry Group
11.3.1. PDU Identifier Registry 11.3.1. PDU Identifier Registry
11.3.2. Protocol Version Registry 11.3.2. Protocol Version Registry
11.3.3. Test Setup PDU Modifier Bitmap Registry 11.3.3. Test Setup PDU Modifier Bitmap Registry
11.3.4. Test Setup PDU Authentication Mode Registry 11.3.4. Test Setup PDU Authentication Mode Registry
11.3.5. Test Setup PDU Command Response Field Registry 11.3.5. Test Setup PDU Command Response Field Registry
11.3.6. Test Activation PDU Command Request Registry 11.3.6. Test Activation PDU Command Request Registry
11.3.7. Test Activation PDU Modifier Bitmap Registry 11.3.7. Test Activation PDU Modifier Bitmap Registry
11.3.8. Test Activation PDU Rate Adjustment Algo. Registry 11.3.8. Test Activation PDU Rate Adjustment Algo Registry
11.3.9. Test Activation PDU Command Response Field Registry 11.3.9. Test Activation PDU Command Response Field Registry
11.4. Guidelines for Designated Experts 11.4. Guidelines for Designated Experts
12. References 12. References
12.1. Normative References 12.1. Normative References
12.2. Informative References 12.2. Informative References
Appendix A. KDF Example (OpenSSL) Appendix A. KDF Example (OpenSSL)
Acknowledgments Acknowledgments
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
skipping to change at line 134 skipping to change at line 134
[RFC9097]. The Method of Measurement discussed in that RFC deploys a [RFC9097]. The Method of Measurement discussed in that RFC deploys a
feedback channel from the receiver to control the sender's feedback channel from the receiver to control the sender's
transmission rate in near real-time. Section 8.1 of [RFC9097] transmission rate in near real-time. Section 8.1 of [RFC9097]
specifies requirements for this method. specifies requirements for this method.
UDPSTP supports measurement features that weren't available via TCP- UDPSTP supports measurement features that weren't available via TCP-
based speed tests and standard measurement protocols, such as the based speed tests and standard measurement protocols, such as the
One-Way Active Measurement Protocol (OWAMP) [RFC4656], Two-Way Active One-Way Active Measurement Protocol (OWAMP) [RFC4656], Two-Way Active
Measurement Protocol (TWAMP) [RFC5357], and Simple Two-Way Active Measurement Protocol (TWAMP) [RFC5357], and Simple Two-Way Active
Measurement Protocol (STAMP) [RFC8762], prior to this work. The Measurement Protocol (STAMP) [RFC8762], prior to this work. The
controlled Bulk Capacity measurement or Speed Test, respectively, is controlled Bulk Transport Capacity measurement or Speed Test,
based on UDP rather than TCP. The bulk measurement load is respectively, is based on UDP rather than TCP. The bulk measurement
unidirectional. These specifications did support the creation of load is unidirectional. These specifications did support the
asymmetric traffic in combination with some two-way communication, as creation of asymmetric traffic in combination with some two-way
supported by TWAMP and STAMP, when work on UDPSTP started. Further, communication, as supported by TWAMP and STAMP, when work on UDPSTP
two-way communications of TWAMP and STAMP are limited to reflection started. Further, two-way communications of TWAMP and STAMP are
or unidirectional load properties, but they lack support for closed limited to reflection or unidirectional load properties, but they
loop feedback operation. The latter enables limiting congestion of a lack support for closed loop feedback operation. The latter enables
bottleneck, whose capacity is measured, to a short time range. limiting congestion of a bottleneck, whose capacity is measured, to a
Support of such a control loop is the main purpose of UDPSTP. short time range. Support of such a control loop is the main purpose
of UDPSTP.
Apart from measurement functionality, a Key Derivation Function (KDF) Apart from measurement functionality, a Key Derivation Function (KDF)
has been added to provide cryptographic separation of key material has been added to provide cryptographic separation of key material
for authentication of protocol messages in a standardized and for authentication of protocol messages in a standardized and
cryptographically secure manner. This is a secondary improvement cryptographically secure manner. This is a secondary improvement
reached by UDPSTP and may simplify its reuse for other measurement reached by UDPSTP and may simplify its reuse for other measurement
purposes. Additionally, because the protocol uses synthetic payload purposes. Additionally, because the protocol uses synthetic payload
data and contains no direct user information, a decision was made to data and contains no direct user information, a decision was made to
forgo encryption support. Secondarily, this is also expected to forgo encryption support. Secondarily, this is also expected to
increase the number of low-end devices that can support the test increase the number of low-end devices that can support the test
skipping to change at line 206 skipping to change at line 207
The primary application of the protocol described here is the same as The primary application of the protocol described here is the same as
in Section 2 of [RFC7497] where: in Section 2 of [RFC7497] where:
| The access portion of the network is the focus of this problem | The access portion of the network is the focus of this problem
| statement. The user typically subscribes to a service with | statement. The user typically subscribes to a service with
| bidirectional access partly described by rates in bits per second. | bidirectional access partly described by rates in bits per second.
UDPSTP is a client-based protocol. It may be applied by consumers to UDPSTP is a client-based protocol. It may be applied by consumers to
measure their own access bandwidth. Consumers may prefer an measure their own access bandwidth. Consumers may prefer an
independent third-party domain hosting the measurement server for independent third-party domain hosting the measurement server for
this purpose. UDPSTP may be deployed in a Large-scale Measurement of this purpose. UDPSTP may be deployed in Large-scale Measurement of
Broadband Performance (LMAP) environment (see [RFC7497]), another Broadband Performance (LMAP) environments (see [RFC7497]) and other
independent third-party domain measurement server deployment. A independent third-party domain measurement server deployments. A
network operator may support operation and maintenance by UDPSTP, a network operator may support operation and maintenance by UDPSTP, a
typical intra-domain deployment. All these deployments require or typical intra-domain deployment. All these deployments require or
benefit from trust into the results, which are ensured by benefit from trusting the results, which are ensured by authenticated
authenticated communication. communication.
3. Protocol Overview 3. Protocol Overview
All messages defined by this document SHALL use UDP transport. All messages defined by this document SHALL use UDP transport.
The remainder of this section gives an informative overview of the The remainder of this section gives an informative overview of the
communication protocol between two test endpoints (without expressing communication protocol between two test endpoints (without expressing
requirements or elaborating on the authentication aspects). requirements or elaborating on the authentication aspects).
One endpoint takes the role of server, listening for connection One endpoint takes the role of server, listening for connection
skipping to change at line 249 skipping to change at line 250
maximize its own individual traffic rate. For multi-connection maximize its own individual traffic rate. For multi-connection
tests, a single client process would replicate the connection setup tests, a single client process would replicate the connection setup
and test procedure multiple times (once for each flow) to one or more and test procedure multiple times (once for each flow) to one or more
server instances. The server instance(s) would process each server instances. The server instance(s) would process each
connection independently, as if they were coming from separate connection independently, as if they were coming from separate
clients. It shall be the responsibility of the client process to clients. It shall be the responsibility of the client process to
manage the inter-related connections such as handling the individual manage the inter-related connections such as handling the individual
connection setup successes and failures, cleaning up connections connection setup successes and failures, cleaning up connections
during a test (should some fail), and aggregating the individual test during a test (should some fail), and aggregating the individual test
results into an overall set of performance statistics. Fields in the results into an overall set of performance statistics. Fields in the
Setup Request (i.e., mcIndex, mcCount, and mcIdent; see Section 6.1) Setup Request (i.e., mcIndex, mcCount, and mcIdent; see Section 5.1)
are used to both differentiate and associate the multiple connections are used to both differentiate and associate the multiple connections
that comprise a single test. that comprise a single test.
The protocol uses UDP transport [RFC0768] with two connection phases The protocol uses UDP transport [RFC0768] with two connection phases
(Control and Data). As shown below, exchanges 1 and 2 constitute the (Control and Data). As shown below, exchanges 1 and 2 constitute the
Control phase, while exchanges 3 and 4 constitute the Data phase. In Control phase, while exchanges 3 and 4 constitute the Data phase. In
this document, the term "message" and the term "Protocol Data Unit", this document, the term "message" and the term "Protocol Data Unit",
or "PDU" [RFC5044], are used interchangeably. or "PDU" [RFC5044], are used interchangeably.
1. Test Setup Request and Response: If a server instance is 1. Test Setup Request and Response: If a server instance is
skipping to change at line 281 skipping to change at line 282
server provides a unique ephemeral port number for each test server provides a unique ephemeral port number for each test
connection, allowing further communication. In a multi- connection, allowing further communication. In a multi-
connection setup, distinct UDP port numbers may be assigned with connection setup, distinct UDP port numbers may be assigned with
each Setup Response from a server instance. Distinct UDP port each Setup Response from a server instance. Distinct UDP port
numbers will be assigned if all Setup Response messages originate numbers will be assigned if all Setup Response messages originate
from the same server in that case. from the same server in that case.
2. Test Activation Request and Response: After having received a 2. Test Activation Request and Response: After having received a
confirmation of the configuration by a server, the client confirmation of the configuration by a server, the client
composes a request conveying parameters such as the testing composes a request conveying parameters such as the testing
direction, the duration of the test interval and test sub- direction, the duration of the test interval and test Sub-
intervals, and various thresholds (for a detailed discussion, see Intervals, and various thresholds (for a detailed discussion, see
[RFC9097] and [TR-471]). The server then chooses to accept, [RFC9097] and [TR-471]). The server then chooses to accept,
ignore, or modify any of the test parameters and communicates the ignore, or modify any of the test parameters and communicates the
set that will be used unless the client rejects the set that will be used unless the client rejects the
modifications. Note that the client assumes that the Test modifications. Note that the client assumes that the Test
Activation exchange has opened any co-located firewalls and Activation exchange has opened any co-located firewalls and
network address/port translators for the test connection (in network address/port translators for the test connection (in
response to the Request packet on the ephemeral port number) and response to the Request packet on the ephemeral port number) and
the traffic that follows. See [RFC9097] for a more detailed the traffic that follows. See [RFC9097] for a more detailed
discussion of firewall and NAT-related features. If the Test discussion of firewall and NAT-related features. If the Test
Activation Request is rejected or fails, the client assumes that Activation Request is rejected or fails, the client assumes that
skipping to change at line 407 skipping to change at line 408
adjustment algorithm for debugging purposes. This may be valuable adjustment algorithm for debugging purposes. This may be valuable
for post-installation or post-repair verification. for post-installation or post-repair verification.
3.2. Handling of and Safeguards Required by Self-Induced Congestion 3.2. Handling of and Safeguards Required by Self-Induced Congestion
Active capacity measurement requires inducing intentional congestion. Active capacity measurement requires inducing intentional congestion.
On paths where the capacity bottleneck is not shared with other On paths where the capacity bottleneck is not shared with other
flows, this self-congestion will be observed as loss and/or delay. flows, this self-congestion will be observed as loss and/or delay.
However, when a path is shared by other flows, the measurement However, when a path is shared by other flows, the measurement
traffic can congest the bottleneck on the path and therefore degrade traffic can congest the bottleneck on the path and therefore degrade
the performance of other flows. Unrestricted use of the tool could the performance of other flows. Unrestricted use of UDPSTP could
lead to traffic starvation and significant issues. lead to traffic starvation and significant issues.
Measurements that generate traffic on shared paths (including Wi-Fi Measurements that generate traffic on shared paths (including Wi-Fi
and Internet paths) need to consider the impact on other traffic. and Internet paths) need to consider the impact on other traffic.
Fixed-rate testing operates without congestion control and therefore Fixed-rate testing operates without congestion control and therefore
must not be executed over other operators' network segments. Fixed- must not be executed over other operators' network segments. Fixed-
rate testing, therefore, is limited to paths within a domain entirely rate testing, therefore, is limited to paths within a domain entirely
managed and operated section-wise and end-to-end by the network managed and operated section-wise and end-to-end by the network
operator performing the measurement. When the risks of disruption to operator performing the measurement. When the risks of disruption to
other flows has been considered, testing could be extended to include other flows has been considered, testing could be extended to include
skipping to change at line 436 skipping to change at line 437
A load rate adjustment algorithm (see Section 4.1) is required to A load rate adjustment algorithm (see Section 4.1) is required to
mitigate the impact of this congestion and to limit the duration of mitigate the impact of this congestion and to limit the duration of
any congestion by terminating the test when sudden impairments or a any congestion by terminating the test when sudden impairments or a
loss of connectivity is detected. loss of connectivity is detected.
4. Requirements, Security Operations, and Optional Checksum 4. Requirements, Security Operations, and Optional Checksum
Security and checksum operations aren't covered by [RFC9097], which Security and checksum operations aren't covered by [RFC9097], which
only defines the Method of Measurement. This section adds the only defines the Method of Measurement. This section adds the
operational specification related to security and optional checksum. operational specification related to security and the optional
Due to the additional complexities, and loss of the direct Layer 3 to checksum. Due to the additional complexities, and loss of the direct
Layer 4 mapping of packets to datagrams, it is recommended that Layer mapping of packets to datagrams between Layer 3 and Layer 4, it is
3 fragmentation be avoided. A simplified approach is to choose the recommended that Layer 3 fragmentation be avoided. A simplified
default datagram size that is small enough to prevent fragmentation. approach is to choose the default datagram size that is small enough
This version of the specification does not support Datagram to prevent fragmentation. This version of the specification does not
Packetization Layer Path MTU Discovery (DPLPMTUD) [RFC8899]. A support Datagram Packetization Layer Path MTU Discovery (DPLPMTUD)
future version could specify how to support this. DPLPMTUD support [RFC8899]. A future version could specify how to support this.
will require a carefully adapted protocol design to ensure DPLPMTUD support will require a carefully adapted protocol design to
interoperability. Unless IP fragmentation is expected, and is one of ensure interoperability. Unless IP fragmentation is expected, and is
the attributes being measured, the IPv4 Don't Fragment (DF) bit one of the attributes being measured, the IPv4 Don't Fragment (DF)
SHOULD be set for all tests. bit SHOULD be set for all tests.
Note: When this specification is used for network debugging, it may Note: When this specification is used for network debugging, it may
be useful for fragmentation to be under the control of the test be useful for fragmentation to be under the control of the test
administrator. administrator.
This section specifies generic requirements, which a measurement load This section specifies generic requirements, which a measurement load
rate adjustment algorithm conforming to this specification MUST rate adjustment algorithm conforming to this specification MUST
fulfill. fulfill.
4.1. Load Rate Adjustment Algorithm Requirements 4.1. Load Rate Adjustment Algorithm Requirements
This document specifies an active capacity measurement method using a This document specifies an active capacity measurement method using a
load rate adjustment algorithm. The requirements following below and load rate adjustment algorithm. The requirements following below and
the currently standardized load rate adjustment algorithms B the currently standardized load rate adjustment algorithms B
[Y.1540Amd2] and C [TR-471] result from years of experiments and [Y.1540Amd2] and C [TR-471] result from years of experiments and
testing by the original authors. These tests were performed in labs, testing by the original authors. These tests were performed in labs,
and also in the Internet, and covered a set of different fixed, and also in the Internet, and covered a set of different fixed,
broadband, mobile, and wireless access types and technologies in broadband, mobile, and wireless access types and technologies in
different countries and continents. Feedback received by performance different countries and continents. Further, the load rate
measurement experts was included, as well as changes resulting from adjustment algorithm requirements listed below reflect feedback from
performance measurement experts, as well as changes resulting from
the standardization of [RFC9097] (reflected also in algorithm B the standardization of [RFC9097] (reflected also in algorithm B
[Y.1540Amd2], which updates a prior version of this algorithm). [Y.1540Amd2], which updates a prior version of this algorithm).
Load rate adjustment algorithms for capacity measurement MUST comply Load rate adjustment algorithms for capacity measurement MUST comply
with the requirements specified by this section. New standard load with the requirements specified by this section. New standard load
rate adjustment algorithms for capacity measurement MUST be reviewed rate adjustment algorithms for capacity measurement MUST be reviewed
by IETF designated experts prior to assignment of a code point in the by IETF designated experts prior to assignment of a code point in the
"Test Activation PDU Rate Adjustment Algorithm" registry. "Test Activation PDU Rate Adjustment Algorithm" registry.
The load rate adjustment algorithm for capacity measurement The load rate adjustment algorithm for capacity measurement
skipping to change at line 502 skipping to change at line 504
5. A high-speed mode to achieve high sending rates quickly MUST 5. A high-speed mode to achieve high sending rates quickly MUST
reduce the measurement load below a level for which the first reduce the measurement load below a level for which the first
feedback interval inferred "congestion" from the measurements. feedback interval inferred "congestion" from the measurements.
Consecutive feedback intervals that have a supra-threshold count Consecutive feedback intervals that have a supra-threshold count
of sequence number anomalies and/or contain an upper delay of sequence number anomalies and/or contain an upper delay
variation threshold exception in all of the consecutive variation threshold exception in all of the consecutive
intervals indicate "congestion" within a test. The threshold of intervals indicate "congestion" within a test. The threshold of
consecutive feedback intervals SHALL be configurable with a consecutive feedback intervals SHALL be configurable with a
default of 3 intervals and a maximum duration to infer default of 3 intervals and a maximum duration to infer
congestion of 500 ms. congestion of 500 ms (milliseconds).
6. Congestion MUST be indicated if the Status Feedback PDUs 6. Congestion MUST be indicated if the Status Feedback PDUs
indicate that either sequence number anomalies were detected OR indicate that either sequence number anomalies were detected OR
the delay range was above the upper delay variation threshold. the delay range was above the upper delay variation threshold.
The RECOMMENDED threshold values are 10 for sequence number gaps The RECOMMENDED threshold values are 10 for sequence number
and 30 ms for lower and 90 ms for upper delay variation gaps, 30 ms for lower delay variation thresholds, and 90 ms for
thresholds, respectively. upper delay variation thresholds.
7. The load rate adjustment algorithm MUST include a Load PDU 7. The load rate adjustment algorithm MUST include a Load PDU
timeout and a Status PDU timeout, which both stop the test when timeout and a Status PDU timeout, which both stop the test when
received PDU streams cease unexpectedly. received PDU streams cease unexpectedly.
8. The Load PDU timeout SHALL be reset to the configured value each 8. The Load PDU timeout SHALL be reset to the configured value each
time a Load PDU is received. If the Load PDU timeout expires, time a Load PDU is received. If the Load PDU timeout expires,
the receiver SHALL be closed and no further Status PDU feedback the receiver SHALL be closed and no further Status PDU feedback
sent. The default Load PDU timeout MUST be no more than 1 sent. The default Load PDU timeout MUST be no more than 1
second. second.
9. The Status PDU timeout SHALL be reset to the configured value 9. The Status PDU timeout SHALL be reset to the configured value
each time a feedback message is received. If the Status PDU each time a feedback message is received. If the Status PDU
timeout expires, the sender SHALL be closed and no further load timeout expires, the sender SHALL be closed and no further load
packets sent. The default Status PDU timeout MUST be no more packets sent. The default Status PDU timeout MUST be no more
than 1 second. than 1 second.
10. If a network operator is certain of the IP-Layer Capacity to be 10. A network operator who is certain of the IP-Layer Capacity to be
validated, then testing MAY start with a fixed-rate test at the validated MAY start with a fixed-rate test at the IP-Layer
IP-Layer Capacity and avoid activating the measurement load rate Capacity and avoid activating the measurement load rate
adjustment algorithm (see Section 8.1 of [RFC9097]). However, adjustment algorithm (see Section 8.1 of [RFC9097]). However,
the stimulus for a diagnostic test (such as a subscriber the stimulus for a diagnostic test (such as a subscriber
request) strongly implies that there is no certainty, and the request) strongly implies that there is no certainty, and the
load adjustment algorithm is RECOMMENDED. load adjustment algorithm is RECOMMENDED.
11. This specification MUST only be used in circumstances consistent 11. This specification MUST only be used in circumstances consistent
with Section 10 (Security Considerations) of [RFC9097]. with Section 10 (Security Considerations) of [RFC9097].
12. Further measurement load rate adjustment algorithm requirements 12. Further measurement load rate adjustment algorithm requirements
are specified by [RFC9097]. are specified by [RFC9097].
The following measurement load rate adjustment algorithms are subject The following measurement load rate adjustment algorithms are subject
to these requirements: to these requirements:
* Measurement load rate adjustment algorithm B [Y.1540Amd2]. * Measurement load rate adjustment algorithm B [Y.1540Amd2].
* Measurement load rate adjustment algorithm C [TR-471]. * Measurement load rate adjustment algorithm C [TR-471].
4.2. Parameters and Definitions 4.2. Parameters and Definitions
Please refer to Section 4 of [RFC9097] for an overview of Parameters Please refer to Section 4 of [RFC9097] for an overview of parameters
related to the Maximum IP-Layer Capacity Metric and Method. A set of related to the Maximum IP-Layer Capacity Metric and Method. A set of
error codes to support debugging are provided in Section 11.3.5. error codes to support debugging are provided in Section 11.3.5.
4.3. Security Mode Operations 4.3. Security Mode Operations
There are two security modes of operation that perform authentication There are two security modes of operation that perform authentication
of the client/server messaging. The two modes are: of the client/server messaging. The two modes are:
1. A REQUIRED mode with authentication during the Control phase 1. A REQUIRED mode with authentication during the Control phase
(Test Setup and Test Activation exchanges). This mode may be (Test Setup and Test Activation exchanges). This mode may be
skipping to change at line 617 skipping to change at line 619
Upon reception, the receiver SHALL validate the message PDU for Upon reception, the receiver SHALL validate the message PDU for
correct length, validity of authDigest, immediacy of authUnixTime, correct length, validity of authDigest, immediacy of authUnixTime,
and expected formatting (PDU-specific fields are also checked, such and expected formatting (PDU-specific fields are also checked, such
as protocol version). Validation of the authDigest requires that it as protocol version). Validation of the authDigest requires that it
be extracted from the PDU and the field, along with the checkSum be extracted from the PDU and the field, along with the checkSum
field, zeroed prior to the Hashed Message Authentication Code (HMAC) field, zeroed prior to the Hashed Message Authentication Code (HMAC)
calculation used for comparison (see Section 7.2 of [RFC9145]). calculation used for comparison (see Section 7.2 of [RFC9145]).
If the validation fails, the receiver SHOULD NOT continue with the If the validation fails, the receiver SHOULD NOT continue with the
Control phase and implement silent rejection (no further packets sent Control phase and SHOULD implement silent rejection (no further
on the address/port pairs). The exception is when the testing hosts packets sent on the address/port pairs). The exception is when the
have been configured for troubleshooting Control phase failures and testing hosts have been configured for troubleshooting Control phase
rejection messages will aid in the process. failures and rejection messages will aid in the process.
If the validation succeeds, the receiver SHALL continue with the If the validation succeeds, the receiver SHALL continue with the
Control phase and compose a successful response or a response Control phase and compose a successful response or a response
indicating the error conditions identified (if any). indicating the error conditions identified (if any).
This process SHALL be executed for the request and response in the This process SHALL be executed for the request and response in the
Test Setup exchange, including the Null Request (Section 5) and the Test Setup exchange, including the Null Request (Section 5) and the
Test Activation exchange (Section 6). Test Activation exchange (Section 6).
4.3.2. Mode 2: Optional Authenticated Mode for Data Phase 4.3.2. Mode 2: Optional Authenticated Mode for Data Phase
skipping to change at line 688 skipping to change at line 690
* LocalKeyName * LocalKeyName
* KDF * KDF
* AlgID * AlgID
* Key * Key
* SendLifetimeStart * SendLifetimeStart
* SendLifetimeEnd * SendLifeTimeEnd
* AcceptLifetimeStart * AcceptLifeTimeStart
* AcceptLifetimeEnd * AcceptLifeTimeEnd
The LocalKeyName SHALL be determined from the corresponding keyId The LocalKeyName SHALL be determined from the corresponding keyId
field in the PDUs that follow. field in the PDUs that follow.
4.4.1. Key Derivation Function (KDF) 4.4.1. Key Derivation Function (KDF)
A Key Derivation Function (KDF) is a one-way function that provides A Key Derivation Function (KDF) is a one-way function that provides
cryptographic separation of key material. The protocol requires a cryptographic separation of key material. The protocol requires a
KDF to securely derive cryptographic keys used for authentication of KDF to securely derive cryptographic keys used for authentication of
protocol messages. The inclusion of a KDF ensures that keys are protocol messages. The inclusion of a KDF ensures that keys are
skipping to change at line 785 skipping to change at line 787
Appendix A, Figure 12 provides a code snippet demonstrating Appendix A, Figure 12 provides a code snippet demonstrating
derivation of the specified keys from key material using the OpenSSL derivation of the specified keys from key material using the OpenSSL
cryptographic library, specifically the high-level Key-Based EVP_KDF cryptographic library, specifically the high-level Key-Based EVP_KDF
implementation (Key-Based Envelope Key Derivation Function); see implementation (Key-Based Envelope Key Derivation Function); see
[EVP_KDF-KB] for details. [EVP_KDF-KB] for details.
4.5. Configuration of Network Functions with Stateful Filtering 4.5. Configuration of Network Functions with Stateful Filtering
Successful interaction with a local firewall assumes the firewall is Successful interaction with a local firewall assumes the firewall is
configured to allow a host to open a bidirectional connection using configured to allow a host to open a bidirectional connection using
unique source and destination addresses as well as port numbers by unique source and destination addresses as well as port numbers
sending a packet using that 4-tuple for a given transport protocol. (i.e., a 4-tuple) by sending a packet using that 4-tuple for a given
The client's interaction with its firewall depends on this transport protocol. The client's interaction with its firewall
configuration. depends on this configuration.
The firewall at the server MUST be configured with an open pinhole The firewall at the server MUST be configured with an open pinhole
for the server IP address and standard UDP port of the server. All for the server IP address and standard UDP port of the server. All
messages sent by the client to the server use this standard UDP port. messages sent by the client to the server use this standard UDP port.
The server uses one ephemeral UDP port per test connection. Assuming The server uses one ephemeral UDP port per test connection. Assuming
that the firewall administration at the server does not allow an open that the firewall administration at the server does not allow an open
UDP ephemeral port range, then the server MUST send a Null Request to UDP ephemeral port range, then the server MUST send a Null Request to
the client from the ephemeral port communicated to the client in the the client from the ephemeral port communicated to the client in the
Test Setup Response. The Null Request may not reach the client: it Test Setup Response. The Null Request may not reach the client: it
skipping to change at line 837 skipping to change at line 839
cannot itself reject. cannot itself reject.
* Pre-filtering of incorrectly addressed destination packets, before * Pre-filtering of incorrectly addressed destination packets, before
responding to a source address. responding to a source address.
All of the PDUs exchanged between the client and server support an All of the PDUs exchanged between the client and server support an
optional header checksum that covers the various fields in the UDPSTP optional header checksum that covers the various fields in the UDPSTP
PDU (excluding the payload content of the Load PDU and, to be clear, PDU (excluding the payload content of the Load PDU and, to be clear,
also the IP and UDP headers). The calculation is the same as the also the IP and UDP headers). The calculation is the same as the
16-bit one's complement Internet checksum used in the IPv4 packet 16-bit one's complement Internet checksum used in the IPv4 packet
header (see Section 3.1 of [RFC0791]). This checksum is intended for Header Checksum specification (see Section 3.1 of [RFC0791]). This
environments where UDP data integrity may be uncertain. This checksum is intended for environments where UDP data integrity may be
includes situations where the standard UDP checksum is not verified uncertain. This includes situations where the standard UDP checksum
upon reception or a nonstandard network API is in use (things is not verified upon reception or a nonstandard network API is in use
typically done to improve performance on low-end devices). However, (things typically done to improve performance on low-end devices).
all UDPSTP datagrams transmitted via IPv4 or IPv6 SHALL include a However, all UDPSTP datagrams transmitted via IPv4 or IPv6 SHALL
standard UDP checksum to protect other potential recipients to whom a include a standard UDP checksum to protect other potential recipients
corrupted packet may be delivered. In the case of a nonstandard to whom a corrupted packet may be delivered. In the case of a
network API, one option to reduce processing overhead may be to nonstandard network API, one option to reduce processing overhead may
restrict testing to only utilize a payload content of all zeros so be to restrict testing to only utilize a payload content of all zeros
that the UDP checksum calculation need not include it for Load PDUs. so that the UDP checksum calculation need not include it for Load
PDUs.
If a PDU sender is populating the checkSum field, it SHALL do so as If a PDU sender is populating the checkSum field, it SHALL do so as
the last step after the PDU is built in all other respects (with the the last step after the PDU is built in all other respects (with the
checkSum field set to zero prior to the calculation). The PDU checkSum field set to zero prior to the calculation). The PDU
receiver SHALL subsequently verify the PDU checksum whenever checksum receiver SHALL subsequently verify the PDU checksum whenever checksum
processing has been configured and the field is populated. If PDU processing has been configured and the field is populated. If PDU
checksum validation fails, the PDU SHALL be discarded. checksum validation fails, the PDU SHALL be discarded.
Because of the redundancy when used in conjunction with Because of the redundancy when used in conjunction with
authentication, it is OPTIONAL for a PDU sender to utilize the UDPSTP authentication, it is OPTIONAL for a PDU sender to utilize the UDPSTP
skipping to change at line 883 skipping to change at line 886
5.1. Client Generates Test Setup Request 5.1. Client Generates Test Setup Request
The client SHALL begin the Control phase exchange by sending a Test The client SHALL begin the Control phase exchange by sending a Test
Setup Request message to the server's (standard) control port. This Setup Request message to the server's (standard) control port. This
standard UDPSTP port number is utilized for each connection of a standard UDPSTP port number is utilized for each connection of a
multi-connection test. multi-connection test.
The client SHALL simultaneously start a test initiation timer so that The client SHALL simultaneously start a test initiation timer so that
if the Control phase fails to complete Test Setup and Test Activation if the Control phase fails to complete Test Setup and Test Activation
exchanges in the allocated time, the client software SHALL exit exchanges in the allocated time, the client software SHALL exit
(close the UDP socket and indicate an error message to the user). (i.e., the UDP socket will be closed and an error message will be
Lost messages result in a Test Setup and Test Activation failure. displayed to the user). Lost messages result in a Test Setup and
The test initiation timer MAY reuse the test termination timeout Test Activation failure. The test initiation timer MAY reuse the
value. test termination timeout value.
The watchdog timeout is configured as a 1-second interval to trigger The watchdog timeout is configured as a 1-second interval to trigger
a warning message that the received traffic has stopped. The test a warning message that the received traffic has stopped. The test
termination timeout is based on the watchdog interval and implements termination timeout is based on the watchdog interval and implements
a wait time of 2 additional seconds before triggering a non-graceful a wait time of 2 additional seconds before triggering a non-graceful
termination. termination.
Note: Any field labeled as 'reserved for alignment', in any PDU, MUST Note: Any field labeled as 'reserved for alignment', in any PDU, MUST
be set to 0 and MUST be ignored upon receipt. be set to 0 and MUST be ignored upon receipt.
The UDP PDU format layout SHALL be as follows (big-endian AB, The UDP PDU format layout SHALL be as follows (big-endian AB,
starting by most significant byte and ending by least significant starting with the most significant byte and ending with the least
byte): significant byte):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pduId | protocolVer | | pduId | protocolVer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mcIndex | mcCount | mcIdent | | mcIndex | mcCount | mcIdent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmdRequest | cmdResponse | maxBandwidth | | cmdRequest | cmdResponse | maxBandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 952 skipping to change at line 955
...) that is common to all connections of a single test. It is ...) that is common to all connections of a single test. It is
used by clients/servers to associate separate connections with a used by clients/servers to associate separate connections with a
single multi-connection test. single multi-connection test.
cmdRequest: A one-octet field set to CHSR_CREQ_SETUPREQ to indicate cmdRequest: A one-octet field set to CHSR_CREQ_SETUPREQ to indicate
a Setup Request message. Note that CHSR_CREQ_NONE remains unused. a Setup Request message. Note that CHSR_CREQ_NONE remains unused.
cmdResponse: A one-octet field. All Request PDUs always have a cmdResponse: A one-octet field. All Request PDUs always have a
Command Response of XXXX_CRSP_NONE. Command Response of XXXX_CRSP_NONE.
maxBandwith: A two-octet field. A non-zero value of this field maxBandwidth: A two-octet field. A non-zero value of this field
specifies the maximum bit rate the client expects to send or specifies the maximum bit rate the client expects to send or
receive during the requested test in Mbps. The server compares receive during the requested test in Mbps. The server compares
this value to its currently available configured limit for test this value to its currently available configured limit for test
admission control. This field MAY be used to rate-limit the admission control. This field MAY be used to rate-limit the
maximum rate the server should attempt. The maxBandwidth field's maximum rate the server should attempt. The maxBandwidth field's
most significant bit, the CHSR_USDIR_BIT, is set to 0 by default most significant bit, the CHSR_USDIR_BIT, is set to 0 by default
to indicate "downstream" and has to be set to 1 to indicate to indicate "downstream" and has to be set to 1 to indicate
"upstream". "upstream".
testPort: A two-octet field set to zero in the Test Setup Request testPort: A two-octet field set to zero in the Test Setup Request
skipping to change at line 1098 skipping to change at line 1101
* the PDU ID is not 0xACE1 (Test Setup PDU), or * the PDU ID is not 0xACE1 (Test Setup PDU), or
* a directed attack has been detected. * a directed attack has been detected.
In this case, the server will allow setup attempts to terminate In this case, the server will allow setup attempts to terminate
silently. Attack detection is beyond the scope of this silently. Attack detection is beyond the scope of this
specification. specification.
When the server replies to a Test Setup Request message, the Test When the server replies to a Test Setup Request message, the Test
Setup Response PDU is structured identically to the Request PDU and Setup Response PDU is structured identically to the Test Setup
SHALL retain the original values received in it, with the following Request PDU and SHALL retain the original values received in it, with
exceptions: the following exceptions:
* The cmdRequest field is set to CHSR_CREQ_SETUPRSP, indicating a * The cmdRequest field is set to CHSR_CREQ_SETUPRSP, indicating a
response. response.
* The cmdResponse field is set to an error code (starting at * The cmdResponse field is set to an error code (starting at
cmdResponse 2, Bad Protocol Version; see Section 11.3.5), cmdResponse 2, Bad Protocol Version; see Section 11.3.5),
indicating the reason for rejection. If cmdResponse indicates a indicating the reason for rejection. If cmdResponse indicates a
bad protocol version (CHSR_CRSP_BADVER), the protocolVer field is bad protocol version (CHSR_CRSP_BADVER), the protocolVer field is
also updated to indicate the current expected version. also updated to indicate the current expected version.
skipping to change at line 1134 skipping to change at line 1137
// //
struct controlHdrSR { struct controlHdrSR {
#define CHSR_ID 0xACE1 #define CHSR_ID 0xACE1
uint16_t pduId; // PDU ID uint16_t pduId; // PDU ID
#define PROTOCOL_VER 20 #define PROTOCOL_VER 20
uint16_t protocolVer; // Protocol version uint16_t protocolVer; // Protocol version
uint8_t mcIndex; // Multi-connection index uint8_t mcIndex; // Multi-connection index
uint8_t mcCount; // Multi-connection count uint8_t mcCount; // Multi-connection count
uint16_t mcIdent; // Multi-connection identifier uint16_t mcIdent; // Multi-connection identifier
#define CHSR_CREQ_NONE 0 #define CHSR_CREQ_NONE 0
#define CHSR_CREQ_SETUPREQ 1 // Setup request #define CHSR_CREQ_SETUPREQ 1 // Setup Request
#define CHSR_CREQ_SETUPRSP 2 // Setup response #define CHSR_CREQ_SETUPRSP 2 // Setup Response
uint8_t cmdRequest; // Command request uint8_t cmdRequest; // Command Request
#define CHSR_CRSP_NONE 0 // (used with request) #define CHSR_CRSP_NONE 0 // (used with request)
#define CHSR_CRSP_ACKOK 1 // Acknowledgment #define CHSR_CRSP_ACKOK 1 // Acknowledgment
#define CHSR_CRSP_BADVER 2 // Bad version #define CHSR_CRSP_BADVER 2 // Bad version
#define CHSR_CRSP_BADJS 3 // Jumbo setting mismatch #define CHSR_CRSP_BADJS 3 // Jumbo setting mismatch
#define CHSR_CRSP_AUTHNC 4 // Auth. not configured #define CHSR_CRSP_AUTHNC 4 // Auth. not configured
#define CHSR_CRSP_AUTHREQ 5 // Auth. required #define CHSR_CRSP_AUTHREQ 5 // Auth. required
#define CHSR_CRSP_AUTHINV 6 // Auth. (mode) invalid #define CHSR_CRSP_AUTHINV 6 // Auth. (mode) invalid
#define CHSR_CRSP_AUTHFAIL 7 // Auth. failure #define CHSR_CRSP_AUTHFAIL 7 // Auth. failure
#define CHSR_CRSP_AUTHTIME 8 // Auth. time invalid #define CHSR_CRSP_AUTHTIME 8 // Auth. time invalid
#define CHSR_CRSP_NOMAXBW 9 // Max bandwidth required #define CHSR_CRSP_NOMAXBW 9 // Max bandwidth required
#define CHSR_CRSP_CAPEXC 10 // Capacity exceeded #define CHSR_CRSP_CAPEXC 10 // Capacity exceeded
#define CHSR_CRSP_BADTMTU 11 // Trad. MTU mismatch #define CHSR_CRSP_BADTMTU 11 // Trad. MTU mismatch
#define CHSR_CRSP_MCINVPAR 12 // Multi-conn. invalid params #define CHSR_CRSP_MCINVPAR 12 // Multi-conn. invalid params
#define CHSR_CRSP_CONNFAIL 13 // Conn. allocation failure #define CHSR_CRSP_CONNFAIL 13 // Conn. allocation failure
uint8_t cmdResponse; // Command response uint8_t cmdResponse; // Command Response
#define CHSR_USDIR_BIT 0x8000 // Upstream direction bit #define CHSR_USDIR_BIT 0x8000 // Upstream direction bit
uint16_t maxBandwidth; // Required bandwidth in Mbps uint16_t maxBandwidth; // Required bandwidth in Mbps
uint16_t testPort; // Test port on server uint16_t testPort; // Test port on server
#define CHSR_JUMBO_STATUS 0x01 #define CHSR_JUMBO_STATUS 0x01
#define CHSR_TRADITIONAL_MTU 0x02 #define CHSR_TRADITIONAL_MTU 0x02
uint8_t modifierBitmap; // Modifier bitmap uint8_t modifierBitmap; // Modifier bitmap
// ========== Integrity Verification ========== // ========== Integrity Verification ==========
#define AUTHMODE_1 1 // Mode 1: Authenticated Control #define AUTHMODE_1 1 // Mode 1: Authenticated Control
#define AUTHMODE_2 2 // Mode 2: Authenticated Control+Status #define AUTHMODE_2 2 // Mode 2: Authenticated Control+Status
uint8_t authMode; // Authentication mode uint8_t authMode; // Authentication mode
skipping to change at line 1189 skipping to change at line 1192
using a new UDP socket allocated from the UDP ephemeral port range. using a new UDP socket allocated from the UDP ephemeral port range.
This new socket will also be used for the subsequent Load and Status This new socket will also be used for the subsequent Load and Status
PDUs that are part of testing (with the port number communicated back PDUs that are part of testing (with the port number communicated back
to the client in testPort field of the Test Setup Response). Then, to the client in testPort field of the Test Setup Response). Then,
the server SHALL start a watchdog timer (to terminate the new the server SHALL start a watchdog timer (to terminate the new
connection if the client goes silent) and SHALL send the Test Setup connection if the client goes silent) and SHALL send the Test Setup
Response back to the client. The watchdog timer is set to the same Response back to the client. The watchdog timer is set to the same
value as on the client side (see Section 5) value as on the client side (see Section 5)
When the server replies to the Test Setup Request message, the Test When the server replies to the Test Setup Request message, the Test
Setup Response PDU is structured identically to the Request PDU and Setup Response PDU is structured identically to the Test Setup
SHALL retain the original values received in it, with the following Request PDU and SHALL retain the original values received in it, with
exceptions: the following exceptions:
* The cmdRequest field is set to CHSR_CREQ_SETUPRSP, indicating a * The cmdRequest field is set to CHSR_CREQ_SETUPRSP, indicating a
response. response.
* The cmdResponse field is set to CHSR_CRSP_ACKOK, indicating an * The cmdResponse field is set to CHSR_CRSP_ACKOK, indicating an
acknowledgment. acknowledgment.
* The testPort field is set to the ephemeral port number to be used * The testPort field is set to the ephemeral port number to be used
for the client's Test Activation Request and all subsequent for the client's Test Activation Request and all subsequent
communication. communication.
skipping to change at line 1286 skipping to change at line 1289
<CODE BEGINS> <CODE BEGINS>
// //
// Control header for UDP payload of Null Request PDU // Control header for UDP payload of Null Request PDU
// //
struct controlHdrNR { struct controlHdrNR {
#define CHNR_ID 0xDEAD #define CHNR_ID 0xDEAD
uint16_t pduId; // PDU ID uint16_t pduId; // PDU ID
uint16_t protocolVer; // Protocol version uint16_t protocolVer; // Protocol version
#define CHNR_CREQ_NONE 0 #define CHNR_CREQ_NONE 0
#define CHNR_CREQ_NULLREQ 1 // Null request #define CHNR_CREQ_NULLREQ 1 // Null Request
uint8_t cmdRequest; // Command request uint8_t cmdRequest; // Command Request
#define CHNR_CRSP_NONE 0 // (used with request) #define CHNR_CRSP_NONE 0 // (used with request)
uint8_t cmdResponse; // Command response uint8_t cmdResponse; // Command Response
uint8_t reserved1; // (reserved for alignment) uint8_t reserved1; // (reserved for alignment)
// ========== Integrity Verification ========== // ========== Integrity Verification ==========
uint8_t authMode; // Authentication mode uint8_t authMode; // Authentication mode
uint32_t authUnixTime; // Authentication timestamp uint32_t authUnixTime; // Authentication timestamp
uint8_t authDigest[AUTH_DIGEST_LENGTH]; uint8_t authDigest[AUTH_DIGEST_LENGTH];
uint8_t keyId; // Key ID in shared table uint8_t keyId; // Key ID in shared table
uint8_t reservedAuth1; // (reserved for alignment) uint8_t reservedAuth1; // (reserved for alignment)
uint16_t checkSum; // Header checksum uint16_t checkSum; // Header checksum
}; };
<CODE ENDS> <CODE ENDS>
skipping to change at line 1320 skipping to change at line 1323
protocol, beginning with the protocol version, PDU ID (to validate protocol, beginning with the protocol version, PDU ID (to validate
the type of message), and cmdRequest for the role of the message, the type of message), and cmdRequest for the role of the message,
which MUST be Test Setup Response, CHSR_CREQ_SETUPRSP, as indicated which MUST be Test Setup Response, CHSR_CREQ_SETUPRSP, as indicated
by Figure 3. by Figure 3.
If the cmdResponse value indicates an error (values greater than If the cmdResponse value indicates an error (values greater than
CHSR_CRSP_ACKOK), the client SHALL display/report a relevant message CHSR_CRSP_ACKOK), the client SHALL display/report a relevant message
to the user or management process and exit. If the client receives a to the user or management process and exit. If the client receives a
Command Response code that is not equal to one of the codes defined, Command Response code that is not equal to one of the codes defined,
the client MUST terminate the connection and terminate operation of the client MUST terminate the connection and terminate operation of
the current Setup Request. If the Command Server Response code value the current Setup Request. If the Command Response code value
indicates success (CHSR_CRSP_ACKOK), the client SHALL compose a Test indicates success (CHSR_CRSP_ACKOK), the client SHALL compose a Test
Activation Request with all the test parameters it desires, such as Activation Request with all the test parameters it desires, such as
the test direction, the test duration, etc., as described below. the test direction, the test duration, etc., as described below.
6. Test Activation Request and Response 6. Test Activation Request and Response
This section is divided according to the sending and processing of This section is divided according to the sending and processing of
the client and server and again at the client. the client and server and again at the client.
6.1. Client Generates Test Activation Request 6.1. Client Generates Test Activation Request
skipping to change at line 1403 skipping to change at line 1406
pduId: IANA has assigned the hex value 0xACE2 (Section 11.3.1). pduId: IANA has assigned the hex value 0xACE2 (Section 11.3.1).
cmdRequest: Set to CHTA_CREQ_TESTACTUS to indicate an upstream test cmdRequest: Set to CHTA_CREQ_TESTACTUS to indicate an upstream test
activation or alternatively to CHTA_CREQ_TESTACTDS to indicate a activation or alternatively to CHTA_CREQ_TESTACTDS to indicate a
downstream test activation. Note that CHTA_CREQ_NONE remains downstream test activation. Note that CHTA_CREQ_NONE remains
unused. See Section 11.3.6. unused. See Section 11.3.6.
cmdResponse: Three CHTA_CRSP_<Indication> values are defined; see cmdResponse: Three CHTA_CRSP_<Indication> values are defined; see
Figure 7. Figure 7.
lowThresh: Two two-octet fields, low threshold Low on the Range of lowThresh: A two-octet field. The lower threshold on the range of
Round Trip Time variation, RTT (Range is values above minimum Round-Trip Time (RTT) variation (the range is composed of values
RTT); see also Table 3 [TR-471]. above the minimum RTT); see also Table 3 [TR-471].
upperThresh: Two two-octet fields, upper threshold Low on the Range upperThresh: A two-octet field. The upper threshold on the range of
of Round Trip Time variation, RTT (Range is values above minimum RTT variation (the range is composed of values above the minimum
RTT); see also Table 3 of [TR-471]. RTT); see also Table 3 of [TR-471].
trialInt: A two-octet field indicating the Status Feedback / trial trialInt: A two-octet field indicating the Status Feedback / trial
interval [ms]. The test interval Delta_t is subdivided into a interval in ms. The test interval Delta_t is subdivided into a
number of sub-intervals dt, and each sub-interval is further number of Sub-Intervals dt, and each Sub-Interval is further
divided into a number of trial intervals (see [TR-471]). Starts divided into a number of trial intervals (see [TR-471]). Starts
by 1 and is continuously incremented during a single test interval by 1 and is continuously incremented during a single test interval
(testIntTime). (testIntTime).
testIntTime: A two-octet field. Duration of the test (either testIntTime: A two-octet field. Duration of the test (either
downlink or uplink) with search algorithm in use, which serves as downlink or uplink) with search algorithm in use, which serves as
the maximum duration of the search process in seconds (see also the maximum duration of the search process in seconds (see also
TestInterval in Table 3 of [TR-471]). TestInterval in Table 3 of [TR-471]).
dscpEcn: Diffserv code point and ECN field; see also the DSCP field dscpEcn: Diffserv code point and ECN field; see also the DSCP field
skipping to change at line 1451 skipping to change at line 1454
algorithm; if True, use EnableIPDV, which uses one-way delay algorithm; if True, use EnableIPDV, which uses one-way delay
variation for the load rate adjustment algorithm). See EnableIPDV variation for the load rate adjustment algorithm). See EnableIPDV
in Table 1 of [TR-471]. in Table 1 of [TR-471].
highSpeedDelta: A one-octet field; see Appendix A of [RFC9097]. highSpeedDelta: A one-octet field; see Appendix A of [RFC9097].
slowAdjThresh and seqErrThresh: Two two-octet fields; see Appendix A slowAdjThresh and seqErrThresh: Two two-octet fields; see Appendix A
of [RFC9097]. of [RFC9097].
ignoreOooDup: A one-octet field. Ignore out-of-order duplicates, ignoreOooDup: A one-octet field. Ignore out-of-order duplicates,
Boolean. When True, only Loss counts toward received packet Boolean. When True, only loss counts toward received packet
sequence number errors. When False, Loss, Reordering, and sequence number errors. When False, loss, out-of-order, and
Duplication are all counted as sequence number errors; default duplicate totals are all counted as sequence number errors.
True (see also Table 3 of [TR-471]). Default is True (see also Table 3 of [TR-471]).
modifierBitmap: A one-octet field. This document only assigns two modifierBitmap: A one-octet field. This document only assigns two
bits in this bitmap; see Section 11.3.7: bits in this bitmap; see Section 11.3.7:
CHTA_SRIDX_ISSTART: Treat srIndexConf as the starting sending CHTA_SRIDX_ISSTART: Treat srIndexConf as the starting sending
rate to be used by the load rate adjustment algorithm. rate to be used by the load rate adjustment algorithm.
CHTA_RAND_PAYLOAD: Randomize the payload content beyond the Load CHTA_RAND_PAYLOAD: Randomize the payload content beyond the Load
PDU header. PDU header.
Other bit positions are left unassigned per this document. Other bit positions are left unassigned per this document.
rateAdjAlgo: A one-octet field. The applied load rate adjustment rateAdjAlgo: A one-octet field. The applied load rate adjustment
algorithm; see Section 11.3.8. algorithm; see Section 11.3.8.
srStruct: Sending Rate structure. Used by the server in a Test srStruct: Sending Rate structure. Used by the server in a Test
Activation Response for an upstream test to communicate the (initial) Activation Response for an upstream test to communicate the
Load PDU transmission parameters the client SHALL use. For a Test (initial) Load PDU transmission parameters the client SHALL use.
Activation Request or a downstream test, this structure SHALL be For a Test Activation Request or a downstream test, this structure
zeroed. Two sets of periodic transmission parameters are available, SHALL be zeroed. Two sets of periodic transmission parameters are
allowing for dual independent transmitters (to support a high degree available, allowing for dual independent transmitters (to support
of rate granularity). The fields are defined as follows: a high degree of rate granularity). The fields are defined as
follows:
txInterval1 and txInterval2: Two four-octet fields indicating the txInterval1 and txInterval2: Two four-octet fields indicating the
load rate transmit interval in [us]. A 100 us granularity is load rate transmit interval in us (microseconds). A 100 us
recommended for optimal rate selection. granularity is recommended for optimal rate selection.
udpPayload1 and udpPayload2: Two four-octet fields indicating the udpPayload1 and udpPayload2: Two four-octet fields indicating the
UDP payload at load rate in [byte]. UDP payload at load rate in bytes.
burstSize1 and burstSize2: Two four-octet fields indicating the burstSize1 and burstSize2: Two four-octet fields indicating the
burst size at load rate by a dimensionless number (of datagrams). burst size at load rate by a dimensionless number (of
datagrams).
udpAddon2: A four-octet field indicating the size of a single Load udpAddon2: A four-octet field indicating the size of a single
PDU to be sent at the end of the txInterval2 send sequence, even Load PDU to be sent at the end of the txInterval2 send
when udpPayload2 or burstSize2 are zero and result in no sequence, even when udpPayload2 or burstSize2 are zero and
transmission of their own. result in no transmission of their own.
subIntPeriod: A two-octet field. Test Sub-interval period in [ms] subIntPeriod: A two-octet field. Test Sub-Interval period in ms
(see also Table 3 of [TR-471]). Trials with subIntPeriod in a (see also Table 3 of [TR-471]). Trials with subIntPeriod in a
range of 100 to 10000 [ms] resulted in a default value of 1000 ms. range of 100 to 10000 ms resulted in a default value of 1000 ms.
authMode: Same as in Section 5.1. authMode: Same as in Section 5.1.
authUnixTime: Same as in Section 5.1. authUnixTime: Same as in Section 5.1.
authDigest: Same as in Section 5.1. authDigest: Same as in Section 5.1.
keyId: Same as in Section 5.1. keyId: Same as in Section 5.1.
reservedAuth1: Same as in Section 5.1. reservedAuth1: Same as in Section 5.1.
checkSum: Same as in Section 5.1. checkSum: Same as in Section 5.1.
The Test Activation Request/Response message PDU (as well as the The Test Activation Request/Response message PDU (as well as the
included Sending Rate structure) SHALL be organized as follows: included Sending Rate structure) SHALL be organized as follows:
<CODE BEGINS> <CODE BEGINS>
// //
// Sending rate structure for a single row of transmission parameters // Sending Rate structure for a single row of transmission parameters
// //
struct sendingRate { struct sendingRate {
uint32_t txInterval1; // Transmit interval (us) uint32_t txInterval1; // Transmit interval (us)
uint32_t udpPayload1; // UDP payload (bytes) uint32_t udpPayload1; // UDP payload (bytes)
uint32_t burstSize1; // UDP burst size per interval uint32_t burstSize1; // UDP burst size per interval
uint32_t txInterval2; // Transmit interval (us) uint32_t txInterval2; // Transmit interval (us)
uint32_t udpPayload2; // UDP payload (bytes) uint32_t udpPayload2; // UDP payload (bytes)
uint32_t burstSize2; // UDP burst size per interval uint32_t burstSize2; // UDP burst size per interval
uint32_t udpAddon2; // UDP add-on (bytes) uint32_t udpAddon2; // UDP add-on (bytes)
}; };
// //
// Control header for UDP payload of Test Act. Request/Response PDUs // Control header for UDP payload of Test Act. Request/Response PDUs
// //
struct controlHdrTA { struct controlHdrTA {
#define CHTA_ID 0xACE2 #define CHTA_ID 0xACE2
uint16_t pduId; // PDU ID uint16_t pduId; // PDU ID
uint16_t protocolVer; // Protocol version uint16_t protocolVer; // Protocol version
#define CHTA_CREQ_NONE 0 #define CHTA_CREQ_NONE 0
#define CHTA_CREQ_TESTACTUS 1 // Test activation upstream #define CHTA_CREQ_TESTACTUS 1 // Test activation upstream
#define CHTA_CREQ_TESTACTDS 2 // Test activation downstream #define CHTA_CREQ_TESTACTDS 2 // Test activation downstream
uint8_t cmdRequest; // Command request uint8_t cmdRequest; // Command Request
#define CHTA_CRSP_NONE 0 // (used with request) #define CHTA_CRSP_NONE 0 // (used with request)
#define CHTA_CRSP_ACKOK 1 // Acknowledgment #define CHTA_CRSP_ACKOK 1 // Acknowledgment
#define CHTA_CRSP_BADPARAM 2 // Bad/invalid test params #define CHTA_CRSP_BADPARAM 2 // Bad/invalid test params
uint8_t cmdResponse; // Command response uint8_t cmdResponse; // Command Response
uint16_t lowThresh; // Low delay variation threshold (ms) uint16_t lowThresh; // Low delay variation threshold (ms)
uint16_t upperThresh; // Upper delay variation threshold (ms) uint16_t upperThresh; // Upper delay variation threshold (ms)
uint16_t trialInt; // Status Feedback/trial interval (ms) uint16_t trialInt; // Status Feedback/trial interval (ms)
uint16_t testIntTime; // Test interval time (sec) uint16_t testIntTime; // Test interval time (sec)
uint8_t reserved1; // (reserved for alignment) uint8_t reserved1; // (reserved for alignment)
uint8_t dscpEcn; // Diffserv and ECN field for testing uint8_t dscpEcn; // Diffserv and ECN field for testing
#define CHTA_SRIDX_DEF UINT16_MAX // Request default server search #define CHTA_SRIDX_DEF UINT16_MAX // Request default server search
uint16_t srIndexConf; // Configured Sending Rate Table index uint16_t srIndexConf; // Configured Sending Rate Table index
uint8_t useOwDelVar; // Use one-way delay, not RTT (BOOL) uint8_t useOwDelVar; // Use one-way delay, not RTT (BOOL)
uint8_t highSpeedDelta; // High-speed row adjustment delta uint8_t highSpeedDelta; // High-speed row adjustment delta
uint16_t slowAdjThresh; // Slow rate adjustment threshold uint16_t slowAdjThresh; // Slow rate adjustment threshold
uint16_t seqErrThresh; // Sequence error threshold uint16_t seqErrThresh; // Sequence error threshold
uint8_t ignoreOooDup; // Ignore Out-of-Order/Dup (BOOL) uint8_t ignoreOooDup; // Ignore out-of-order/Dup (BOOL)
#define CHTA_SRIDX_ISSTART 0x01 // Use srIndexConf as starting index #define CHTA_SRIDX_ISSTART 0x01 // Use srIndexConf as starting index
#define CHTA_RAND_PAYLOAD 0x02 // Randomize payload #define CHTA_RAND_PAYLOAD 0x02 // Randomize payload
uint8_t modifierBitmap; // Modifier bitmap uint8_t modifierBitmap; // Modifier bitmap
#define CHTA_RA_ALGO_B 0 // Algorithm B #define CHTA_RA_ALGO_B 0 // Algorithm B
#define CHTA_RA_ALGO_C 1 // Algorithm C #define CHTA_RA_ALGO_C 1 // Algorithm C
uint8_t rateAdjAlgo; // Rate adjust. algorithm uint8_t rateAdjAlgo; // Rate adjust. algorithm
uint8_t reserved2; // (reserved for alignment) uint8_t reserved2; // (reserved for alignment)
struct sendingRate srStruct; // Sending rate structure struct sendingRate srStruct; // Sending Rate structure
uint16_t subIntPeriod; // Sub-interval period (ms) uint16_t subIntPeriod; // Sub-Interval period (ms)
uint16_t reserved3; // (reserved for alignment) uint16_t reserved3; // (reserved for alignment)
uint16_t reserved4; // (reserved for alignment) uint16_t reserved4; // (reserved for alignment)
uint8_t reserved5; // (reserved for alignment) uint8_t reserved5; // (reserved for alignment)
// ========== Integrity Verification ========== // ========== Integrity Verification ==========
uint8_t authMode; // Authentication mode uint8_t authMode; // Authentication mode
uint32_t authUnixTime; // Authentication timestamp uint32_t authUnixTime; // Authentication timestamp
uint8_t authDigest[AUTH_DIGEST_LENGTH]; uint8_t authDigest[AUTH_DIGEST_LENGTH];
uint8_t keyId; // Key ID in shared table uint8_t keyId; // Key ID in shared table
uint8_t reservedAuth1; // (reserved for alignment) uint8_t reservedAuth1; // (reserved for alignment)
uint16_t checkSum; // Header checksum uint16_t checkSum; // Header checksum
skipping to change at line 1665 skipping to change at line 1670
6.2.2. Server Accepts Request and Generates Response 6.2.2. Server Accepts Request and Generates Response
When the server sends the Test Activation Response, it SHALL set the When the server sends the Test Activation Response, it SHALL set the
cmdResponse field to CHTA_CRSP_ACKOK (see Section 11.3.9). cmdResponse field to CHTA_CRSP_ACKOK (see Section 11.3.9).
If the client has requested an upstream test, the server SHALL: If the client has requested an upstream test, the server SHALL:
* include the transmission parameters from the first row of the * include the transmission parameters from the first row of the
Sending Rate Table in the Sending Rate structure (if requested by Sending Rate Table in the Sending Rate structure (if requested by
srIndexConf having been set to CHTA_SRIDX_DEF), or setting srIndexConf to a value of CHTA_SRIDX_DEF), or
* include the transmission parameters from the designated Configured * include the transmission parameters from the designated Configured
Sending Rate Table index (srIndexConf) of the Sending Rate Sending Rate Table index (srIndexConf) of the Sending Rate
Table where, if CHTA_SRIDX_ISSTART is set in modifierBitmap, this Table where, if CHTA_SRIDX_ISSTART is set in modifierBitmap, this
will be used as the starting rate for the load rate adjustment will be used as the starting rate for the load rate adjustment
algorithm; else, it will be considered a fixed-rate test. algorithm; else, it will be considered a fixed-rate test.
When generating the Test Activation Response (acceptance) for a When generating the Test Activation Response (acceptance) for a
downstream test, the server SHALL set all octets of the Sending Rate downstream test, the server SHALL set all octets of the Sending Rate
structure to zero. structure to zero.
skipping to change at line 1710 skipping to change at line 1715
When the client receives the Test Activation Response message, it When the client receives the Test Activation Response message, it
SHALL first follow the Message Verification Procedure listed in SHALL first follow the Message Verification Procedure listed in
Section 5.2, Paragraph 2. Section 5.2, Paragraph 2.
After the client receives the (vetted) Test Activation Response, it After the client receives the (vetted) Test Activation Response, it
first checks the Command Response value. first checks the Command Response value.
If the client receives a Test Activation cmdResponse field value that If the client receives a Test Activation cmdResponse field value that
indicates an error, the client SHALL display/report a relevant indicates an error, the client SHALL display/report a relevant
message to the user or management process and exit. message to the user or measurement system and exit.
If the client receives a Test Activation cmdResponse field value that If the client receives a Test Activation cmdResponse field value that
is not equal to one of the codes defined in Section 11.3.9, the is not equal to one of the codes defined in Section 11.3.9, the
client MUST terminate the connection and terminate operation of the client MUST terminate the connection and terminate operation of the
current setup procedure. current setup procedure.
If the client receives a Test Activation Command Response value that If the client receives a Test Activation Command Response value that
indicates success (e.g., CHTA_CRSP_ACKOK; see Section 11.3.9), the indicates success (e.g., CHTA_CRSP_ACKOK; see Section 11.3.9), the
client SHALL update its configuration to use any test parameters client SHALL update its configuration to use any test parameters
modified by the server. If the setup parameters coerced by the modified by the server. If the setup parameters coerced by the
skipping to change at line 1777 skipping to change at line 1782
watchdog timeout expiration at each endpoint. Note that the watchdog watchdog timeout expiration at each endpoint. Note that the watchdog
timer's purpose is to detect a connection failure or a massive timer's purpose is to detect a connection failure or a massive
congestion condition only. congestion condition only.
When the server is sending Load PDUs in the role of sender, it SHALL When the server is sending Load PDUs in the role of sender, it SHALL
use the transmission parameters directly from the Sending Rate use the transmission parameters directly from the Sending Rate
Table via the index that is currently selected (which was indirectly Table via the index that is currently selected (which was indirectly
based on the feedback in its received Status Feedback messages). based on the feedback in its received Status Feedback messages).
However, when the client is sending Load PDUs in the role of sender, However, when the client is sending Load PDUs in the role of sender,
it SHALL use the discreet transmission parameters that were it SHALL use the discrete transmission parameters that were
communicated by the server in its periodic Status Feedback messages communicated by the server in its periodic Status Feedback messages
(and not referencing a Sending Rate Table directly). This approach (and not referencing a Sending Rate Table directly). This approach
allows the server to control the individual sending rates as well as allows the server to control the individual sending rates as well as
the algorithm used to decide when and how to adjust the rate. the algorithm used to decide when and how to adjust the rate.
The server uses a load rate adjustment algorithm that evaluates The server uses a load rate adjustment algorithm that evaluates
measurements taken locally at the Load PDU receiver. When the client measurements taken locally at the Load PDU receiver. When the client
is the receiver, the information is communicated to the server via is the receiver, the information is communicated to the server via
periodic Status Feedback messages. When the server is the receiver, periodic Status Feedback messages. When the server is the receiver,
the information is used directly (although it is also communicated to the information is used directly (although it is also communicated to
the client via its periodic Status Feedback messages). This approach the client via its periodic Status Feedback messages). This approach
is unique to this protocol; it provides the ability to search for the is unique to this protocol; it provides the ability to search for the
Maximum IP Capacity and specify specific sender behaviors that are maximum IP capacity and specify specific sender behaviors that are
absent from other testing tools. Although the algorithm depends on absent from other testing tools. Although the algorithm depends on
the protocol, it is not part of the protocol per se. the protocol, it is not part of the protocol per se.
The default algorithm (B; see [Y.1540]) has three paths to its The default algorithm (B; see [Y.1540]) has three paths to its
decision on the next sending rate: decision on the next sending rate:
1. When there are no impairments present (no sequence errors and low 1. When there are no impairments present (no sequence errors and low
delay variation), resulting in a sending rate increase. delay variation), resulting in a sending rate increase.
2. When there are low impairments present (no sequence errors but 2. When there are low impairments present (no sequence errors but
skipping to change at line 1821 skipping to change at line 1826
* A high-speed mode (fast) to achieve high sending rates quickly but * A high-speed mode (fast) to achieve high sending rates quickly but
that also backs off quickly when "congestion" is inferred from the that also backs off quickly when "congestion" is inferred from the
measurements. Consecutive feedback intervals that have a supra- measurements. Consecutive feedback intervals that have a supra-
threshold count of sequence number anomalies and/or contain an threshold count of sequence number anomalies and/or contain an
upper delay variation threshold exception in all of the upper delay variation threshold exception in all of the
consecutive intervals are sufficient to declare "congestion" consecutive intervals are sufficient to declare "congestion"
within a test. The threshold of consecutive feedback intervals within a test. The threshold of consecutive feedback intervals
SHALL be configurable with a default of 3 intervals. SHALL be configurable with a default of 3 intervals.
* A single-step (slow) mode where all rate adjustments use the * A single-step (slow) mode where all rate adjustments use the
minimum increase or decrease of one step in the sending rate minimum increase or decrease of one step in the Sending Rate
table. The single-step mode continues after the first inference Table. The single-step mode continues after the first inference
of "congestion" from measured impairments. of "congestion" from measured impairments.
An OPTIONAL load rate adjustment algorithm (designated C) has been An OPTIONAL load rate adjustment algorithm (designated C) has been
defined in [TR-471]. Algorithm C operation and modes are similar to defined in [TR-471]. Algorithm C operation and modes are similar to
B, but C uses multiplicative increases in the fast mode to reach the B, but C uses multiplicative increases in the fast mode to reach the
gigabit range quickly and adds the possibility to re-try the fast gigabit range quickly and provides the option to retry the fast mode
mode during a test (which improves the measurement accuracy in during a test (which improves the measurement accuracy in dynamic or
dynamic or error-prone access, such as radio access). error-prone access, such as radio access).
On the other hand, the test configuration MAY use a fixed sending On the other hand, the test configuration MAY use a fixed sending
rate requested by the client, using the field srIndexConf. rate requested by the client, using the field srIndexConf.
The client MAY communicate the desired fixed rate in its Test The client MAY communicate the desired fixed rate in its Test
Activation Request. Activation Request.
The UDP PDU format layout SHALL be as follows (big-endian AB): The UDP PDU format layout SHALL be as follows (big-endian AB):
0 1 2 3 0 1 2 3
skipping to change at line 1885 skipping to change at line 1890
rxStopped: A one-octet field. Boolean, 0 or 1, used to indicate to rxStopped: A one-octet field. Boolean, 0 or 1, used to indicate to
the remote endpoint that local receive traffic (either Load or the remote endpoint that local receive traffic (either Load or
Status PDUs) has stopped. All outgoing Load or Status PDUs SHALL Status PDUs) has stopped. All outgoing Load or Status PDUs SHALL
continue to assert this indication until traffic is received continue to assert this indication until traffic is received
again, or the test is terminated. The time threshold to trigger again, or the test is terminated. The time threshold to trigger
this condition is expected to be a reasonable fraction of the this condition is expected to be a reasonable fraction of the
watchdog timeout (a default of one second is recommended). watchdog timeout (a default of one second is recommended).
lpduSeqNo: A four-octet field indicating the Load PDU sequence lpduSeqNo: A four-octet field indicating the Load PDU sequence
number (starting at 1). Used to determine loss, out-of-order, and number (starting at 1). Used to determine loss, out-of-order, and
duplicates. duplicate totals.
udpPayload: A two-octet field indicating the total payload size of udpPayload: A two-octet field indicating the total payload size of
the UDP datagram including the Load PDU message header and payload the UDP datagram including the Load PDU message header and payload
content (i.e., what the UDP socket read function would return). content (i.e., what the UDP socket read function would return).
This field allows the Load PDU receiver to maintain accurate This field allows the Load PDU receiver to maintain accurate
receive statistics if utilizing receive truncation (only receive statistics if utilizing receive truncation (only
requesting the Load PDU message header octets from the protocol requesting the Load PDU message header octets from the protocol
stack). stack).
spduSeqErr: A two-octet field indicating the Status PDU loss count, spduSeqErr: A two-octet field indicating the Status PDU loss count,
skipping to change at line 1912 skipping to change at line 1917
of the most recent spduTime_sec/spduTime_nsec from the last Status of the most recent spduTime_sec/spduTime_nsec from the last Status
PDU received. Used for RTT measurements made by the Load PDU PDU received. Used for RTT measurements made by the Load PDU
receiver. receiver.
lpduTime_sec/lpduTime_nsec: Two four-octet fields containing the lpduTime_sec/lpduTime_nsec: Two four-octet fields containing the
local send time of the Load PDU. Used for one-way delay variation local send time of the Load PDU. Used for one-way delay variation
measurements made by the Load PDU receiver. measurements made by the Load PDU receiver.
rttRespDelay: A two-octet field indicating the RTT response delay, rttRespDelay: A two-octet field indicating the RTT response delay,
used to "adjust" raw RTT. On the Load PDU sender, it is the used to "adjust" raw RTT. On the Load PDU sender, it is the
number of milliseconds from reception of the most recent Status number of ms from reception of the most recent Status PDU (when
PDU (when the latest spduTime_sec/spduTime_nsec was obtained) to the latest spduTime_sec/spduTime_nsec was obtained) to the
the transmission of the Load PDU (where the previously obtained transmission of the Load PDU (where the previously obtained
spduTime_sec/spduTime_nsec is returned). When the Load PDU spduTime_sec/spduTime_nsec is returned). When the Load PDU
receiver is calculating RTT, by subtracting the copied Status PDU receiver is calculating RTT, by subtracting the copied Status PDU
send time (in the Load PDU) from the local Load PDU receive time, send time (in the Load PDU) from the local Load PDU receive time,
this value is subtracted from the raw RTT to correct for any this value is subtracted from the raw RTT to correct for any
response delay due to Load PDU scheduling. response delay due to Load PDU scheduling.
checkSum: An optional checksum of only the Load PDU header (see checkSum: An optional checksum of only the Load PDU header (see
Section 4.6 for guidance). The checksum does not cover the Section 4.6 for guidance). The checksum does not cover the
payload content. The calculation is done as the very last step of payload content. The calculation is done as the very last step of
building the PDU header, with the checkSum field set to zero. building the PDU header, with the checkSum field set to zero.
skipping to change at line 1949 skipping to change at line 1954
#define TEST_ACT_TEST 0 // Test active #define TEST_ACT_TEST 0 // Test active
#define TEST_ACT_STOP1 1 // Stop indication used locally by server #define TEST_ACT_STOP1 1 // Stop indication used locally by server
#define TEST_ACT_STOP2 2 // Stop indication exchanged with client #define TEST_ACT_STOP2 2 // Stop indication exchanged with client
uint8_t testAction; // Test action uint8_t testAction; // Test action
uint8_t rxStopped; // Receive traffic stopped (BOOL) uint8_t rxStopped; // Receive traffic stopped (BOOL)
uint32_t lpduSeqNo; // Load PDU sequence number uint32_t lpduSeqNo; // Load PDU sequence number
uint16_t udpPayload; // UDP payload (bytes) uint16_t udpPayload; // UDP payload (bytes)
uint16_t spduSeqErr; // Status PDU sequence error count uint16_t spduSeqErr; // Status PDU sequence error count
uint32_t spduTime_sec; // Send time in last rx'd status PDU uint32_t spduTime_sec; // Send time in last rx'd status PDU
uint32_t spduTime_nsec; // Send time in last rx'd status PDU uint32_t spduTime_nsec; // Send time in last rx'd status PDU
uint32_t lpduTime_sec; // Send time of this load PDU uint32_t lpduTime_sec; // Send time of this Load PDU
uint32_t lpduTime_nsec; // Send time of this load PDU uint32_t lpduTime_nsec; // Send time of this Load PDU
uint16_t rttRespDelay; // Response delay for RTT (ms) uint16_t rttRespDelay; // Response delay for RTT (ms)
uint16_t checkSum; // Header checksum uint16_t checkSum; // Header checksum
}; };
<CODE ENDS> <CODE ENDS>
Figure 9: Load PDU Figure 9: Load PDU
7.2. Status PDU 7.2. Status PDU
The Load PDU receiver SHALL send a Status PDU to the sender during a The Load PDU receiver SHALL send a Status PDU to the sender during a
skipping to change at line 2070 skipping to change at line 2075
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| keyId | reservedAuth1 | checkSum | | keyId | reservedAuth1 | checkSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Status PDU Layout Figure 10: Status PDU Layout
Note that the Sending Rate structure is defined in Section 6. Note that the Sending Rate structure is defined in Section 6.
The primary role of the Status Feedback message is to communicate the The primary role of the Status Feedback message is to communicate the
traffic conditions at the Load PDU receiver to the Load PDU sender. traffic conditions at the Load PDU receiver to the Load PDU sender.
While the Sub-Interval Statistics structure (sisSav) covers the most While the Sub-Interval statistics saved (sisSav) structure covers the
recently saved (completed) sub-interval, similar fields directly in most recently saved (completed) Sub-Interval, similar fields directly
the Status PDU itself cover the most recent trial interval (the time in the Status PDU itself cover the most recent trial interval (the
period between Status Feedback messages, completed by this Status time period between Status Feedback messages, completed by this
PDU). Both sets of statistics SHALL always be populated by the Load Status PDU). Both sets of statistics SHALL always be populated by
PDU receiver, regardless of role (client or server). the Load PDU receiver, regardless of role (client or server).
Details on the Status PDU measurement fields are provided in Details on the Status PDU measurement fields are provided in
[RFC9097]. The authentication and checkSum fields follow the same [RFC9097]. The authentication and checkSum fields follow the same
methodology as with the Setup Request and Response. Additional methodology as with the Setup Request and Response. Additional
information regarding fields not defined previously are as follows: information regarding fields not defined previously are as follows:
pduId: IANA has assigned the hex value 0xFEED (Section 11.3.1). pduId: IANA has assigned the hex value 0xFEED (Section 11.3.1).
spduSeqNo: A four-octet field containing the Status PDU sequence spduSeqNo: A four-octet field containing the Status PDU sequence
number (starting at 1). Used by the Load PDU sender to detect number (starting at 1). Used by the Load PDU sender to detect
Status PDU loss (in the unloaded direction). The loss count is Status PDU loss (in the unloaded direction). The loss count is
communicated back to the Load PDU receiver via spduSeqErr in communicated back to the Load PDU receiver via spduSeqErr in
subsequent Load PDUs. subsequent Load PDUs.
subIntSeqNo: A four-octet field containing the Sub-interval sequence subIntSeqNo: A four-octet field containing the Sub-Interval sequence
number (starting at 1) that corresponds to the statistics provided number (starting at 1) that corresponds to the statistics provided
in sisSav, for the last saved (completed) sub-interval. in sisSav, for the last saved (completed) Sub-Interval.
sisSav: Sub-interval statistics saved (completed) for the most sisSav: Sub-Interval statistics saved (completed) for the most
recent sub-interval (as designated by the subIntSeqNo). These recent Sub-Interval (as designated by the subIntSeqNo). These
consist of the following fields: consist of the following fields:
rxDatagrams: A four-octet field Sub-interval indicating the rxDatagrams: A four-octet field Sub-Interval indicating the
number of received datagrams during the Sub-Interval. number of received datagrams during the Sub-Interval.
rxBytes: An eight-octet field indicating the Sub-Interval byte rxBytes: An eight-octet field indicating the Sub-Interval byte
count (eight octets chosen to prevent overflow at high speeds). count (eight octets chosen to prevent overflow at high speeds).
deltaTime: A four-octet field indicating the exact duration of deltaTime: A four-octet field indicating the exact duration of
the Sub-Interval in microseconds. Used to calculate the the Sub-Interval in us. Used to calculate the received traffic
received traffic rate together with rxBytes. rate together with rxBytes.
seqErrLoss/seqErrOoo/seqErrDup: Three four-octet fields populated seqErrLoss/seqErrOoo/seqErrDup: Three four-octet fields populated
by the Loss, out-of-order, and duplicate totals. Available for by the loss, out-of-order, and duplicate totals. Available for
both the sub-interval and trial interval; it is a breakout of both the Sub-Interval and trial interval; it is a breakout of
the SeqErrors count in Table 3 of [TR-471]. seqErrOoo and the SeqErrors count in Table 3 of [TR-471]. seqErrOoo and
seqErrDup are realized by comparing sequence numbers. A seqErrDup are realized by comparing sequence numbers. A
lookback list of the last n sequence numbers received is used lookback list of the last n sequence numbers received is used
as the basis. Each Load PDU sequence number is checked against as the basis. Each Load PDU sequence number is checked against
this lookback. The number n may depend on the implementation this lookback. The number n may depend on the implementation
and on typical characteristics of environments, where UDPSTP is and on typical characteristics of environments, where UDPSTP is
deployed (like mobile networks or Wi-Fi). Currently, a default deployed (like mobile networks or Wi-Fi). Currently, a default
sequence number interval of n=32 has been chosen. Specifically sequence number interval of n=32 has been chosen. Specifically
for seqErrOoo, each successively received higher seqno sets the for seqErrOoo, each successively received higher seqno sets the
next-expected seqno to seqno+1, and anything below that is next-expected seqno to seqno+1, and anything below that is
skipping to change at line 2132 skipping to change at line 2137
the sequence 93, 94, 95, 100, 96, 97, 101, 98, 99, 102, 103, the sequence 93, 94, 95, 100, 96, 97, 101, 98, 99, 102, 103,
... reception of 96, 97, 98, and 99 would not increment the ... reception of 96, 97, 98, and 99 would not increment the
next-expected seqno and would all be considered out of order. next-expected seqno and would all be considered out of order.
delayVarMin/delayVarMax/delayVarSum/delayVarCnt: Four four-octet delayVarMin/delayVarMax/delayVarSum/delayVarCnt: Four four-octet
fields populated by the one-way delay variation measurements of fields populated by the one-way delay variation measurements of
all received Load PDUs (where avg = sum/cnt). For each Load all received Load PDUs (where avg = sum/cnt). For each Load
PDU received, the send time (lpduTime_sec/lpduTime_nsec) is PDU received, the send time (lpduTime_sec/lpduTime_nsec) is
subtracted from the local receive time, which is then subtracted from the local receive time, which is then
normalized by subtracting the current clockDeltaMin. Available normalized by subtracting the current clockDeltaMin. Available
for both the sub-interval and trial interval. for both the Sub-Interval and trial interval.
rttVarMinimum/rttVarMaximum (in sisSav): Two four-octet fields rttVarMinimum/rttVarMaximum (in sisSav): Two four-octet fields
populated by the minimum and maximum RTT delay variation populated by the minimum and maximum RTT delay variation
(rttVarSample) in the sub-interval designated by the (rttVarSample) in the Sub-Interval designated by the
subIntSeqNo. subIntSeqNo.
accumTime: The accumulated time of the test in milliseconds, accumTime: The accumulated time of the test in ms, based on the
based on the duration of each sub-interval. Equivalent to the duration of each Sub-Interval. Equivalent to the sum of each
sum of each deltaTime (although in ms) sent in each Status PDU deltaTime (although in ms) sent in each Status PDU during the
during the test. test.
clockDeltaMin: A four-octet field indicating the minimum clock clockDeltaMin: A four-octet field indicating the minimum clock delta
delta (difference) since the beginning of the test. Obtained (difference) since the beginning of the test. Obtained by
by subtracting the send time of each Load PDU (lpduTime_sec/ subtracting the send time of each Load PDU (lpduTime_sec/
lpduTime_nsec) from the local time that it was received. This lpduTime_nsec) from the local time that it was received. This
value is initialized with the first Load PDU received and is value is initialized with the first Load PDU received and is
updated with each subsequent one to maintain a current (and updated with each subsequent one to maintain a current (and
continuously updated) minimum. If the endpoint clocks are continuously updated) minimum. If the endpoint clocks are
sufficiently synchronized, this will be the minimum one-way sufficiently synchronized, this will be the minimum one-way delay
delay in milliseconds. Otherwise, this value may be negative in ms. Otherwise, this value may be negative but still valid for
but still valid for one-way delay variation measurements for one-way delay variation measurements for the default test duration
the default test duration (default is 10 [s]). If the test (default is 10 seconds). If the test duration is extended to a
duration is extended to a range of minutes, where significant range of minutes, where significant clock drift can occur,
clock drift can occur, synchronized (or at least well- synchronized (or at least well-disciplined) clocks may be
disciplined) clocks may be required. required.
rttMinimum (in Status PDU): A four-octet field indicating the rttMinimum (in Status PDU): A four-octet field indicating the
minimum "adjusted" RTT measured since the beginning of the minimum "adjusted" RTT measured since the beginning of the test.
test. See rttRespDelay (Section 7.1) regarding "adjusted" See rttRespDelay (Section 7.1) regarding "adjusted" measurements.
measurements. RTT is obtained by subtracting the copied RTT is obtained by subtracting the copied spduTime_sec/
spduTime_sec/spduTime_nsec in the received Load PDU from the spduTime_nsec in the received Load PDU from the local time at
local time at which it was received. This minimum SHALL be which it was received. This minimum SHALL be kept current (and
kept current (and continuously updated) via each Load PDU continuously updated) via each Load PDU received with an updated
received with an updated spduTime_sec/spduTime_nsec. This spduTime_sec/spduTime_nsec. This value MUST be positive. Before
value MUST be positive. Before an initial value can be an initial value can be established, and because zero is itself
established, and because zero is itself valid, it SHALL be set valid, it SHALL be set to STATUS_NODEL when communicated in the
to STATUS_NODEL when communicated in the Status PDU. Status PDU.
rttVarSample: A four-octet field indicating the most recent rttVarSample: A four-octet field indicating the most recent
"adjusted" RTT delay variation measurement. See rttRespDelay "adjusted" RTT delay variation measurement. See rttRespDelay
(Section 7.1) regarding "adjusted" measurements. RTT delay (Section 7.1) regarding "adjusted" measurements. RTT delay
variation is obtained by subtracting the current (and variation is obtained by subtracting the current (and continuously
continuously updated) "adjusted" RTT minimum, communicated as updated) "adjusted" RTT minimum, communicated as rttMinimum (in
rttMinimum (in Status PDU), from each "adjusted" RTT Status PDU), from each "adjusted" RTT measurement (which is itself
measurement (which is itself obtained by subtracting the copied obtained by subtracting the copied spduTime_sec/spduTime_nsec in
spduTime_sec/spduTime_nsec in the received Load PDU from the the received Load PDU from the local time at which it was
local time at which it was received). Note that while one-way received). Note that while one-way delay variation is measured
delay variation is measured for every Load PDU received, RTT for every Load PDU received, RTT delay variation is only sampled
delay variation is only sampled via the Status PDU sent and the via the Status PDU sent and the very next Load PDU received with
very next Load PDU received with the corresponding updated the corresponding updated spduTime_sec/spduTime_nsec. When a new
spduTime_sec/spduTime_nsec. When a new value is unavailable value is unavailable (possibly due to packet loss), and because
(possibly due to packet loss), and because zero is itself zero is itself valid, it SHALL be set to STATUS_NODEL when
valid, it SHALL be set to STATUS_NODEL when communicated in the communicated in the Status PDU.
Status PDU.
delayMinUpd: A one-octet field. Boolean, 0 or 1, indicating that delayMinUpd: A one-octet field. Boolean, 0 or 1, indicating that
the clockDeltaMin and/or rttMinimum (in Status PDU), as the clockDeltaMin and/or rttMinimum (in Status PDU), as measured
measured by the Load PDU receiver, has been updated. by the Load PDU receiver, has been updated.
tiDeltaTime/tiRxDatagrams/tiRxBytes: Three four-octet fields tiDeltaTime/tiRxDatagrams/tiRxBytes: Three four-octet fields
populated by the trial interval time in microseconds, along populated by the trial interval time in us, along with the
with the received datagram and byte counts. Used to calculate received datagram and byte counts. Used to calculate the received
the received traffic rate for the trial interval. traffic rate for the trial interval.
spduTime_sec/spduTime_nsec: Two four-octet fields containing the spduTime_sec/spduTime_nsec: Two four-octet fields containing the
local transmit time of the Status PDU. Expected to be copied local transmit time of the Status PDU. Expected to be copied into
into spduTime_sec/spduTime_nsec in subsequent Load PDUs after spduTime_sec/spduTime_nsec in subsequent Load PDUs after being
being received by the Load PDU sender. Used for RTT received by the Load PDU sender. Used for RTT measurements.
measurements.
authMode: Same as in Section 5.1. authMode: Same as in Section 5.1.
authUnixTime: Same as in Section 5.1. authUnixTime: Same as in Section 5.1.
authDigest: Same as in Section 5.1. authDigest: Same as in Section 5.1.
keyId: Same as in Section 5.1. keyId: Same as in Section 5.1.
reservedAuth1: Same as in Section 5.1. reservedAuth1: Same as in Section 5.1.
checkSum: Same as in Section 5.1. checkSum: Same as in Section 5.1.
The Status Feedback message PDU (as well as the included Sub-Interval The Status Feedback message PDU (as well as the included Sub-Interval
Statistics structure) SHALL be organized as follows: statistics structure) SHALL be organized as follows:
<CODE BEGINS> <CODE BEGINS>
// //
// Sub-interval statistics structure for received traffic information // Sub-Interval statistics structure for received traffic information
// //
#pragma pack(push, 1)
struct subIntStats { struct subIntStats {
uint32_t rxDatagrams; // Received datagrams uint32_t rxDatagrams; // Received datagrams
uint64_t rxBytes; // Received bytes (64 bits) uint64_t rxBytes; // Received bytes (64 bits)
uint32_t deltaTime; // Time delta (us) uint32_t deltaTime; // Time delta (us)
uint32_t seqErrLoss; // Loss sum uint32_t seqErrLoss; // Loss sum
uint32_t seqErrOoo; // Out-of-Order sum uint32_t seqErrOoo; // Out-of-order sum
uint32_t seqErrDup; // Duplicate sum uint32_t seqErrDup; // Duplicate sum
uint32_t delayVarMin; // Delay variation minimum (ms) uint32_t delayVarMin; // Delay variation minimum (ms)
uint32_t delayVarMax; // Delay variation maximum (ms) uint32_t delayVarMax; // Delay variation maximum (ms)
uint32_t delayVarSum; // Delay variation sum (ms) uint32_t delayVarSum; // Delay variation sum (ms)
uint32_t delayVarCnt; // Delay variation count uint32_t delayVarCnt; // Delay variation count
uint32_t rttMinimum; // Minimum round-trip time (ms) uint32_t rttVarMinimum; // Minimum RTT variation (ms)
uint32_t rttMaximum; // Maximum round-trip time (ms) uint32_t rttVarMaximum; // Maximum RTT variation (ms)
uint32_t accumTime; // Accumulated time (ms) uint32_t accumTime; // Accumulated time (ms)
}; };
#pragma pack(pop)
// //
// Status feedback header for UDP payload of status PDUs // Status Feedback header for UDP payload of status PDUs
// //
struct statusHdr { struct statusHdr {
#define STATUS_ID 0xFEED #define STATUS_ID 0xFEED
uint16_t pduId; // PDU ID uint16_t pduId; // PDU ID
uint8_t testAction; // Test action uint8_t testAction; // Test action
uint8_t rxStopped; // Receive traffic stopped (BOOL) uint8_t rxStopped; // Receive traffic stopped (BOOL)
uint32_t spduSeqNo; // Status PDU sequence number uint32_t spduSeqNo; // Status PDU sequence number
struct sendingRate srStruct; // Sending rate structure struct sendingRate srStruct; // Sending Rate structure
uint32_t subIntSeqNo; // Sub-interval sequence number uint32_t subIntSeqNo; // Sub-Interval sequence number
struct subIntStats sisSav; // Sub-interval saved stats struct subIntStats sisSav; // Sub-Interval stats saved
uint32_t seqErrLoss; // Loss sum uint32_t seqErrLoss; // Loss sum
uint32_t seqErrOoo; // Out-of-Order sum uint32_t seqErrOoo; // Out-of-order sum
uint32_t seqErrDup; // Duplicate sum uint32_t seqErrDup; // Duplicate sum
uint32_t clockDeltaMin; // Clock delta minimum (ms) uint32_t clockDeltaMin; // Clock delta minimum (ms)
uint32_t delayVarMin; // Delay variation minimum (ms) uint32_t delayVarMin; // Delay variation minimum (ms)
uint32_t delayVarMax; // Delay variation maximum (ms) uint32_t delayVarMax; // Delay variation maximum (ms)
uint32_t delayVarSum; // Delay variation sum (ms) uint32_t delayVarSum; // Delay variation sum (ms)
uint32_t delayVarCnt; // Delay variation count uint32_t delayVarCnt; // Delay variation count
#define STATUS_NODEL UINT32_MAX // No delay data/value #define STATUS_NODEL UINT32_MAX // No delay data/value
uint32_t rttMinimum; // Min round-trip time sampled (ms) uint32_t rttMinimum; // Min round-trip time sampled (ms)
uint32_t rttVarSample; // Last round-trip time sample (ms) uint32_t rttVarSample; // Last round-trip time sample (ms)
uint8_t delayMinUpd; // Delay minimum(s) updated (BOOL) uint8_t delayMinUpd; // Delay minimum(s) updated (BOOL)
skipping to change at line 2339 skipping to change at line 2344
operating in the roles of Src (test packet sender) and Dst operating in the roles of Src (test packet sender) and Dst
(receiver), with a measured path and return path between them. (receiver), with a measured path and return path between them.
The nominal duration of a measurement interval at the Destination, The nominal duration of a measurement interval at the Destination,
parameter testIntTime, MUST be constrained in a production network, parameter testIntTime, MUST be constrained in a production network,
since this is an active test method and it will likely cause since this is an active test method and it will likely cause
congestion on the Src to Dst host path during a test. congestion on the Src to Dst host path during a test.
It is RECOMMENDED to locate test endpoints as close to the intended It is RECOMMENDED to locate test endpoints as close to the intended
measured link(s) as practical. The testing operator MUST set a value measured link(s) as practical. The testing operator MUST set a value
for the MaxHops Parameter, based on the expected path length. This for the MaxHops parameter, based on the expected path length. This
Parameter can keep measurement traffic from straying too far beyond parameter can keep measurement traffic from straying too far beyond
the intended path. the intended path.
It is obviously counterproductive to run more than one independent It is obviously counterproductive to run more than one independent
and concurrent test (regardless of the number of flows in the test and concurrent test (regardless of the number of flows in the test
stream) when attempting to measure the maximum capacity on a single stream) when attempting to measure the maximum capacity on a single
path. The number of concurrent, independent tests of a path SHALL be path. The number of concurrent, independent tests of a path SHALL be
limited to one. limited to one.
The load rate adjustment algorithm's scope is limited to helping The load rate adjustment algorithm's scope is limited to helping
determine the Maximum IP-Layer Capacity in the context of an determine the Maximum IP-Layer Capacity in the context of an
skipping to change at line 2379 skipping to change at line 2384
both the interface traffic and IP-Layer Capacity simultaneously, so both the interface traffic and IP-Layer Capacity simultaneously, so
this form of diagnostic measurement may not be possible. this form of diagnostic measurement may not be possible.
10. Security Considerations 10. Security Considerations
Active metrics and measurements have a long history of security Active metrics and measurements have a long history of security
considerations. The security considerations that apply to any active considerations. The security considerations that apply to any active
measurement of live paths are relevant here. See [RFC4656] and measurement of live paths are relevant here. See [RFC4656] and
[RFC5357]. [RFC5357].
When considering privacy of those involved in measurement or those When considering privacy of users activating measurements as a
whose traffic is measured, the sensitive information available to service or users whose traffic is measured, the sensitive information
potential observers is greatly reduced when using active techniques available to potential observers is greatly reduced when using active
that are within this scope of work. Passive observations of user techniques that are within this scope of work. Passive observations
traffic for measurement purposes raise many privacy issues. See the of user traffic for measurement purposes raise many privacy issues.
privacy considerations described in the LMAP Framework [RFC7594], See the privacy considerations described in the LMAP Framework
which covers active and passive techniques. [RFC7594], which covers active and passive techniques.
Below are some new considerations for capacity measurement as Below are some new considerations for capacity measurement as
described in this document. described in this document.
1. Cooperating client and server hosts and agreements to test the 1. Cooperating client and server hosts and agreements to test the
path between the hosts are REQUIRED. Hosts perform in either the path between the hosts are REQUIRED. Hosts perform in either the
server or the client roles. One way to assure a cooperative server or the client roles. One way to assure a cooperative
agreement employs the optional Authorization mode is through the agreement employs the optional Authorization mode is through the
use of the authDigest field and the known identity associated use of the authDigest field and the known identity associated
with the shared key used to create the authDigest field via the with the shared key used to create the authDigest field via the
skipping to change at line 2457 skipping to change at line 2462
exchange in the Control phase of protocol operation and has created a exchange in the Control phase of protocol operation and has created a
new registry group for the UDPSTP. new registry group for the UDPSTP.
11.1. New User Port Number Assignment 11.1. New User Port Number Assignment
IANA has registered the following service name in the "Service Name IANA has registered the following service name in the "Service Name
and Transport Protocol Port Number Registry": and Transport Protocol Port Number Registry":
Service Name: udpstp Service Name: udpstp
Port Number: 24601 Port Number: 24601
Transport Protocol: UDP Transport Protocol: udp
Description: UDP-based IP-Layer Capacity and performance measurement Description: UDP-based IP-Layer Capacity and Performance Measurement
protocol protocol
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org> Contact: IETF Chair <chair@ietf.org>
Reference: RFC 9946 Reference: RFC 9946
The protocol uses IP-Layer Unicast. A single port number was The protocol uses IP-Layer Unicast. A single port number was
assigned to help configure firewalls and other port-based systems for assigned to help configure firewalls and other port-based systems for
access control prior to negotiating dynamic ports between client and access control prior to negotiating dynamic ports between client and
server. server.
skipping to change at line 2490 skipping to change at line 2495
Table 1: KeyTable KDFs Registry Table 1: KeyTable KDFs Registry
11.3. New UDPSTP Registry Group 11.3. New UDPSTP Registry Group
IANA has created the registries in the subsections that follow under IANA has created the registries in the subsections that follow under
a new registry group called "UDP Speed Test Protocol (UDPSTP)". a new registry group called "UDP Speed Test Protocol (UDPSTP)".
IANA has added the following note under the "UDP Speed Test Protocol IANA has added the following note under the "UDP Speed Test Protocol
(UDPSTP)" registry group: (UDPSTP)" registry group:
| Note: Values reserved for experimental use are not expected to be | Note: Values reserved for Experimental Use are not expected to be
| used on the Internet, but for experiments that are confined to | used on the Internet but are expected to be used for experiments
| closed environments. | that are confined to closed environments.
11.3.1. PDU Identifier Registry 11.3.1. PDU Identifier Registry
IANA has created the "PDU Identifier" registry under the "UDP Speed IANA has created the "PDU Identifier" registry under the "UDP Speed
Test Protocol (UDPSTP)" registry group. Every UDPSTP PDU contains a Test Protocol (UDPSTP)" registry group. Every UDPSTP PDU contains a
two-octet pduId field identifying the role and format of the PDU that two-octet pduId field identifying the role and format of the PDU that
follows. The code points in this registry are allocated according to follows. The code points in this registry are allocated according to
the registration procedures [RFC8126] described in Table 2. the registration procedures [RFC8126] described in Table 2.
+===================+=========================+ +===============+=========================+
| Range(Hex) | Registration Procedures | | Range(Hex) | Registration Procedures |
+===================+=========================+ +===============+=========================+
| 0xFFFF and 0x0000 | Reserved | | 0x0000 | Reserved |
+-------------------+-------------------------+ +---------------+-------------------------+
| 0x8000-0xFFFE | IETF Review | | 0x0001-0x7F00 | Specification Required |
+-------------------+-------------------------+ +---------------+-------------------------+
| 0x0001-0x7F00 | Specification Required | | 0x7F01-0x7FE0 | Experimental Use |
+-------------------+-------------------------+ +---------------+-------------------------+
| 0x7F01-0x7FE0 | Experimental Use | | 0x7FE1-0x7FFF | Private Use |
+-------------------+-------------------------+ +---------------+-------------------------+
| 0x7FE1-0x7FFF | Private Use | | 0x8000-0xFFFE | IETF Review |
+-------------------+-------------------------+ +---------------+-------------------------+
| 0xFFFF | Reserved |
+---------------+-------------------------+
Table 2: Registration Procedures for the Table 2: Registration Procedures for
PDU Identifier Registry the PDU Identifier Registry
IANA has assigned values in the "PDU Identifier" registry as follows: IANA has assigned values in the "PDU Identifier" registry as follows:
+===============+===============================+===========+ +===============+===============================+===========+
| Value | Description | Reference | | Value | Description | Reference |
+===============+===============================+===========+ +===============+===============================+===========+
| 0x0000 | Reserved | RFC 9946 | | 0x0000 | Reserved | RFC 9946 |
+---------------+-------------------------------+-----------+ +---------------+-------------------------------+-----------+
| 0x7F01-0x7FE0 | Reserved for Experimental Use | RFC 9946 | | 0x7F01-0x7FE0 | Reserved for Experimental Use | RFC 9946 |
+---------------+-------------------------------+-----------+ +---------------+-------------------------------+-----------+
skipping to change at line 2615 skipping to change at line 2622
+=======+===============================+===========+ +=======+===============================+===========+
| Value | Description | Reference | | Value | Description | Reference |
+=======+===============================+===========+ +=======+===============================+===========+
| 0x00 | No modifications | RFC 9946 | | 0x00 | No modifications | RFC 9946 |
+-------+-------------------------------+-----------+ +-------+-------------------------------+-----------+
| 0x01 | Allow Jumbo datagram sizes | RFC 9946 | | 0x01 | Allow Jumbo datagram sizes | RFC 9946 |
| | above sending rates of 1 Gbps | | | | above sending rates of 1 Gbps | |
+-------+-------------------------------+-----------+ +-------+-------------------------------+-----------+
| 0x02 | Use Traditional MTU (1500 | RFC 9946 | | 0x02 | Use Traditional MTU (1500 | RFC 9946 |
| | bytes with IP-header) | | | | bytes with an IP header) | |
+-------+-------------------------------+-----------+ +-------+-------------------------------+-----------+
Table 7: Initial Values of the Test Setup PDU Table 7: Initial Values of the Test Setup PDU
Modifier Bitmap Registry Modifier Bitmap Registry
11.3.4. Test Setup PDU Authentication Mode Registry 11.3.4. Test Setup PDU Authentication Mode Registry
IANA has created the "Test Setup PDU Authentication Mode" registry IANA has created the "Test Setup PDU Authentication Mode" registry
under the "UDP Speed Test Protocol (UDPSTP)" registry group. The under the "UDP Speed Test Protocol (UDPSTP)" registry group. The
Test Setup PDU layout contains an authMode field. The code points in Test Setup PDU layout contains an authMode field. The code points in
skipping to change at line 2827 skipping to change at line 2834
| 0x01 | Set when srIndexConf is | RFC 9946 | | 0x01 | Set when srIndexConf is | RFC 9946 |
| | start rate for search | | | | start rate for search | |
+-------+-----------------------------------------------+-----------+ +-------+-----------------------------------------------+-----------+
| 0x02 | Set for randomized UDP | RFC 9946 | | 0x02 | Set for randomized UDP | RFC 9946 |
| | payload | | | | payload | |
+-------+-----------------------------------------------+-----------+ +-------+-----------------------------------------------+-----------+
Table 15: Initial Values of the Test Activation PDU Modifier Table 15: Initial Values of the Test Activation PDU Modifier
Bitmap Registry Bitmap Registry
11.3.8. Test Activation PDU Rate Adjustment Algo. Registry 11.3.8. Test Activation PDU Rate Adjustment Algo Registry
IANA has created the "Test Activation PDU Rate Adjustment Algo." IANA has created the "Test Activation PDU Rate Adjustment Algo"
registry under the "UDP Speed Test Protocol (UDPSTP)" registry group. registry under the "UDP Speed Test Protocol (UDPSTP)" registry group.
The Test Activation PDU layout contains a rateAdjAlgo field. The The Test Activation PDU layout contains a rateAdjAlgo field. The
code points in this registry are allocated according to the code points in this registry are allocated according to the
registration procedures [RFC8126] described in Table 16. registration procedures [RFC8126] described in Table 16.
+=================================+=========================+ +=================================+=========================+
| Range(Capital alphabet / UTF-8) | Registration Procedures | | Range(Capital alphabet / UTF-8) | Registration Procedures |
+=================================+=========================+ +=================================+=========================+
| A-Y | IETF Review | | A-Y | IETF Review |
+---------------------------------+-------------------------+ +---------------------------------+-------------------------+
| Z | Reserved | | Z | Reserved |
+---------------------------------+-------------------------+ +---------------------------------+-------------------------+
Table 16: Registration Procedures for the Test Activation Table 16: Registration Procedures for the Test Activation
PDU Rate Adjustment Algo. Registry PDU Rate Adjustment Algo Registry
IANA has assigned capitalized alphabetic UTF-8 values, as well as the IANA has assigned capitalized alphabetic UTF-8 values, as well as the
corresponding incremental numeric values, in the "Test Activation PDU corresponding incremental numeric values, in the "Test Activation PDU
Rate Adjustment Algo." registry as follows: Rate Adjustment Algo" registry as follows:
+================+=======================+==============+ +================+=======================+==============+
| Value(Numeric) | Description | Reference | | Value(Numeric) | Description | Reference |
+================+=======================+==============+ +================+=======================+==============+
| A(n/a) | Not used | RFC 9946 | | A(n/a) | Not used | RFC 9946 |
+----------------+-----------------------+--------------+ +----------------+-----------------------+--------------+
| B(0) | Rate algorithm Type B | [Y.1540Amd2] | | B(0) | Rate algorithm Type B | [Y.1540Amd2] |
+----------------+-----------------------+--------------+ +----------------+-----------------------+--------------+
| C(1) | Rate algorithm Type C | [TR-471] | | C(1) | Rate algorithm Type C | [TR-471] |
+----------------+-----------------------+--------------+ +----------------+-----------------------+--------------+
Table 17: Initial Values of the Test Activation PDU Table 17: Initial Values of the Test Activation PDU
Rate Adjustment Algo. Registry Rate Adjustment Algo Registry
11.3.9. Test Activation PDU Command Response Field Registry 11.3.9. Test Activation PDU Command Response Field Registry
IANA has created the "Test Activation PDU Command Response Field" IANA has created the "Test Activation PDU Command Response Field"
registry under the "UDP Speed Test Protocol (UDPSTP)" registry group. registry under the "UDP Speed Test Protocol (UDPSTP)" registry group.
The Test Activation PDU layout (also) contains a cmdResponse field. The Test Activation PDU layout (also) contains a cmdResponse field.
The code points in this registry are allocated according to the The code points in this registry are allocated according to the
registration procedures [RFC8126] described in Table 18. registration procedures [RFC8126] described in Table 18.
+================+=========================+ +================+=========================+
skipping to change at line 3099 skipping to change at line 3106
return 0; return 0;
} }
if ((kctx = EVP_KDF_CTX_new(kdf)) == NULL) { if ((kctx = EVP_KDF_CTX_new(kdf)) == NULL) {
EVP_KDF_free(kdf); EVP_KDF_free(kdf);
return 0; return 0;
} }
// //
// Set parameters for KBKDF // Set parameters for KBKDF
// --------------------------------------------------------- // ---------------------------------------------------------
*p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MODE, "COUNTER", 0); *p++ = OSSL_PARAM_construct_utf8_string(
*p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MAC, "HMAC", 0); OSSL_KDF_PARAM_MODE, "COUNTER", 0);
*p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST, "SHA256", 0); *p++ = OSSL_PARAM_construct_utf8_string(
*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_KEY, Kin, strlen(Kin)); OSSL_KDF_PARAM_MAC, "HMAC", 0);
*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SALT, "UDPSTP", 6); *p++ = OSSL_PARAM_construct_utf8_string(
OSSL_KDF_PARAM_DIGEST, "SHA256", 0);
*p++ = OSSL_PARAM_construct_octet_string(
OSSL_KDF_PARAM_KEY, Kin, strlen(Kin));
*p++ = OSSL_PARAM_construct_octet_string(
OSSL_KDF_PARAM_SALT, "UDPSTP", 6);
var = snprintf(context, sizeof(context), "%u", authUnixTime); var = snprintf(context, sizeof(context), "%u", authUnixTime);
*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_INFO, context, var); *p++ = OSSL_PARAM_construct_octet_string(
OSSL_KDF_PARAM_INFO, context, var);
// //
// Confirm the following are enabled // Confirm the following are enabled
// //
var = 1; var = 1;
*p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_USE_L, &var); *p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_USE_L, &var);
*p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_USE_SEPARATOR, &var); *p++ = OSSL_PARAM_construct_int(
OSSL_KDF_PARAM_KBKDF_USE_SEPARATOR, &var);
// //
// Set counter length in bits (available as of OpenSSL 3.1) // Set counter length in bits (available as of OpenSSL 3.1)
// //
var = 32; // Length of 32 is backward compatible with OpenSSL 3.0 var = 32; // Length of 32 is backward compatible with OpenSSL 3.0
*p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_R, &var); *p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_R, &var);
*p++ = OSSL_PARAM_construct_end(); *p++ = OSSL_PARAM_construct_end();
// --------------------------------------------------------- // ---------------------------------------------------------
// //
// Derive key material // Derive key material
skipping to change at line 3158 skipping to change at line 3172
Acknowledgments Acknowledgments
This document was edited by Al Morton, who passed away before being This document was edited by Al Morton, who passed away before being
able to finalize this work. Ruediger Geib only joined later to help able to finalize this work. Ruediger Geib only joined later to help
finalize this specification. finalize this specification.
Thanks to Lincoln Lavoie, Can Desem, Greg Mirsky, Bjoern Ivar Teigen, Thanks to Lincoln Lavoie, Can Desem, Greg Mirsky, Bjoern Ivar Teigen,
Ken Kerpez, and Chen Li for reviewing this specification and Ken Kerpez, and Chen Li for reviewing this specification and
providing helpful suggestions and areas for further development. providing helpful suggestions and areas for further development.
Mohamed Boucadair's AD review improved comprehensibility of the Mohamed Boucadair's AD review improved comprehensibility of the
document, and he further navigated the document well through the document, and he provided helpful guidance well through the final
final review stages. Tommy Pauly shepherded this document. Further review stages. Tommy Pauly shepherded this document. Further
comments by Gorry Fairhurst, Éric Vyncke, Roman Danyliw, Gunter Van comments by Gorry Fairhurst, Éric Vyncke, Roman Danyliw, Gunter Van
de Velde, Deb Cooley, Tianran Zhou, Andy Newton, Giuseppe Fioccola, de Velde, Deb Cooley, Tianran Zhou, Andy Newton, Giuseppe Fioccola,
Lars Eggert, Erik Kline, and Benson Muite helped to shape the Lars Eggert, Erik Kline, and Benson Muite helped to shape the
document. David Dong and Amanda Baber provided early reviews of the document. David Dong and Amanda Baber provided early reviews of the
IANA Considerations section. IANA Considerations section.
Starting with the early SEC-DIR review, Brian Weis provided Starting with the early SEC-DIR review, Brian Weis provided
constructive guidance regarding numerous security-related protocol constructive guidance regarding numerous security-related protocol
issues. The Crypto Forum Research Group reviewed these parts, again issues. The Crypto Forum Research Group reviewed these parts, again
providing guidance. Magnus Westerlund's review resulted in further providing guidance. Magnus Westerlund's review resulted in further
changes and refinements. Ultimately, Paul Wouters' feedback was changes and refinements. Ultimately, Paul Wouters' feedback was
critical in finalizing the chosen security approach. critical in finalizing the chosen security approach.
Authors' Addresses Authors' Addresses
Al Morton Al Morton
AT&T Labs
Len Ciavattone Len Ciavattone
AT&T Labs AT&T Labs
Middletown, NJ Middletown, NJ
United States of America United States of America
Email: lenciavattone@gmail.com Email: lenciavattone@gmail.com
Ruediger Geib (editor) Ruediger Geib (editor)
Deutsche Telekom Deutsche Telekom
Deutsche Telekom Allee 9 Deutsche Telekom Allee 9
 End of changes. 103 change blocks. 
286 lines changed or deleted 301 lines changed or added

This html diff was produced by rfcdiff 1.48.