rfc9946v4.txt   rfc9946.txt 
Internet Engineering Task Force (IETF) A. Morton Internet Engineering Task Force (IETF) A. Morton
Request for Comments: 9946 L. Ciavattone Request for Comments: 9946 L. Ciavattone
Category: Standards Track AT&T Labs Category: Standards Track AT&T Labs
ISSN: 2070-1721 R. Geib, Ed. ISSN: 2070-1721 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 (UDPSTP) 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 measurements as described in RFC 9097 and other related conducting measurements as described in RFC 9097 and other related
measurements. measurements.
skipping to change at line 53 skipping to change at line 54
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1. Terminology 2. Conventions and Terminology
1.2. Requirements Language 3. Scope, Goals, and Applicability
2. Scope, Goals, and Applicability 4. Protocol Overview
3. Protocol Overview 4.1. Fixed-Rate Testing
3.1. Fixed-Rate Testing 4.2. Handling of and Safeguards Required by Self-Induced
3.2. Handling of and Safeguards Required by Self-Induced
Congestion Congestion
4. Requirements, Security Operations, and Optional Checksum 5. Requirements, Security Operations, and Optional Checksum
4.1. Load Rate Adjustment Algorithm Requirements 5.1. Load Rate Adjustment Algorithm Requirements
4.2. Parameters and Definitions 5.2. Parameters and Definitions
4.3. Security Mode Operations 5.3. Security Mode Operations
4.3.1. Mode 1: Required Authenticated Mode 5.3.1. Mode 1: Required Authenticated Mode
4.3.2. Mode 2: Optional Authenticated Mode for Data Phase 5.3.2. Mode 2: Optional Authenticated Mode for Data Phase
4.4. Key Management 5.4. Key Management
4.4.1. Key Derivation Function (KDF) 5.4.1. Key Derivation Function (KDF)
4.5. Configuration of Network Functions with Stateful Filtering 5.5. Configuration of Network Functions with Stateful Filtering
4.6. Optional Checksum 5.6. Optional Checksum
5. Test Setup Request and Response 6. Test Setup Request and Response
5.1. Client Generates Test Setup Request 6.1. Client Generates Test Setup Request
5.2. Server Test Setup Request Processing and Response 6.2. Server Test Setup Request Processing and Response
Generation Generation
5.2.1. Test Setup Request Processing -- Rejection 6.2.1. Test Setup Request Processing -- Rejection
5.2.2. Test Setup Request Processing -- Acceptance 6.2.2. Test Setup Request Processing -- Acceptance
5.3. Setup Response Processing at the Client 6.3. Setup Response Processing at the Client
6. Test Activation Request and Response 7. Test Activation Request and Response
6.1. Client Generates Test Activation Request 7.1. Client Generates Test Activation Request
6.2. Server Processes Test Activation Request and Generates 7.2. Server Processes Test Activation Request and Generates
Response Response
6.2.1. Server Rejects or Modifies Request 7.2.1. Server Rejects or Modifies Request
6.2.2. Server Accepts Request and Generates Response 7.2.2. Server Accepts Request and Generates Response
6.3. Client Processes Test Activation Response 7.3. Client Processes Test Activation Response
7. Test Load Stream Transmission and Measurement Status Feedback 8. Test Load Stream Transmission and Measurement Status Feedback
Messages Messages
7.1. Load PDU and Roles 8.1. Load PDU and Roles
7.2. Status PDU 8.2. Status PDU
8. Stopping a Test 9. Stopping a Test
9. Operational Considerations for the Measurement Method 10. Operational Considerations for the Measurement Method
9.1. Notes on Interface Measurements 10.1. Notes on Interface Measurements
10. Security Considerations 11. Security Considerations
11. IANA Considerations 12. IANA Considerations
11.1. New User Port Number Assignment 12.1. New User Port Number Assignment
11.2. New KeyTable KDF 12.2. New KeyTable KDF
11.3. New UDPSTP Registry Group 12.3. New UDPSTP Registry Group
11.3.1. PDU Identifier Registry 12.3.1. PDU Identifier Registry
11.3.2. Protocol Version Registry 12.3.2. Protocol Version Registry
11.3.3. Test Setup PDU Modifier Bitmap Registry 12.3.3. Test Setup PDU Modifier Bitmap Registry
11.3.4. Test Setup PDU Authentication Mode Registry 12.3.4. Test Setup PDU Authentication Mode Registry
11.3.5. Test Setup PDU Command Response Field Registry 12.3.5. Test Setup PDU Command Response Field Registry
11.3.6. Test Activation PDU Command Request Registry 12.3.6. Test Activation PDU Command Request Registry
11.3.7. Test Activation PDU Modifier Bitmap Registry 12.3.7. Test Activation PDU Modifier Bitmap Registry
11.3.8. Test Activation PDU Rate Adjustment Algo Registry 12.3.8. Test Activation PDU Rate Adjustment Algo Registry
11.3.9. Test Activation PDU Command Response Field Registry 12.3.9. Test Activation PDU Command Response Field Registry
11.4. Guidelines for Designated Experts 12.4. Guidelines for Designated Experts
12. References 13. References
12.1. Normative References 13.1. Normative References
12.2. Informative References 13.2. Informative References
Appendix A. KDF Example (OpenSSL) Appendix A. KDF Example (OpenSSL)
Acknowledgments Acknowledgments
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
The performance community has seen the development of Informative The performance community has seen the development of informative
Bulk Transport Capacity (BTC) definitions in "A Framework for Bulk Transport Capacity (BTC) definitions in "A Framework for
Defining Empirical Bulk Transfer Capacity Metrics" [RFC3148] and Defining Empirical Bulk Transfer Capacity Metrics" [RFC3148] and
"Defining Network Capacity" [RFC5136] as well as experimental metric "Defining Network Capacity" [RFC5136] as well as experimental metric
definitions and methods in "Model-Based Metrics for Bulk Transport definitions and methods in "Model-Based Metrics for Bulk Transport
Capacity" [RFC8337]. Capacity" [RFC8337].
This document specifies the UDP Speed Test Protocol (UDPSTP) to This document specifies the UDP Speed Test Protocol (UDPSTP) to
enable the measurement of One-Way IP Capacity metrics as defined by enable the measurement of One-Way IP Capacity metrics as defined by
[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 Transport Capacity measurement or Speed Test, controlled BTC measurement or Speed Test, respectively, is based on
respectively, is based on UDP rather than TCP. The bulk measurement UDP rather than TCP. The bulk measurement load is unidirectional.
load is unidirectional. These specifications did support the These specifications did support the creation of asymmetric traffic
creation of asymmetric traffic in combination with some two-way in combination with some two-way communication, as supported by TWAMP
communication, as supported by TWAMP and STAMP, when work on UDPSTP and STAMP, when work on UDPSTP started. Further, two-way
started. Further, two-way communications of TWAMP and STAMP are communications of TWAMP and STAMP are limited to reflection or
limited to reflection or unidirectional load properties, but they unidirectional load properties, but they lack support for closed loop
lack support for closed loop feedback operation. The latter enables feedback operation. The latter enables limiting congestion of a
limiting congestion of a bottleneck, whose capacity is measured, to a bottleneck, whose capacity is measured, to a short time range.
short time range. Support of such a control loop is the main purpose Support of such a control loop is the main purpose of UDPSTP.
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. This is also expected to increase the
increase the number of low-end devices that can support the test number of low-end devices that can support the test methodology.
methodology.
1.1. Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Downstream UDP Speed Test: A client-initiated Network Capacity Downstream UDP Speed Test: A client-initiated Network Capacity
measurement between a server acting as sender and a client acting measurement between a server acting as sender and a client acting
as receiver. as receiver.
Upstream UDP Speed Test: A client-initiated Network Capacity Upstream UDP Speed Test: A client-initiated Network Capacity
measurement between a client acting as sender and a server acting measurement between a client acting as sender and a server acting
as receiver. as receiver.
1.2. Requirements Language In this document, the term "message" and the term "Protocol Data
Unit", or "PDU" [RFC5044], are used interchangeably.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Scope, Goals, and Applicability 3. Scope, Goals, and Applicability
The scope of this document is to define a protocol to measure the The scope of this document is to define a protocol to measure the
Maximum IP-Layer Capacity Metric according to the Method of Maximum IP-Layer Capacity Metric according to the Method of
Measurement standardized by Section 8 of [RFC9097]. As such, this Measurement standardized by Section 8 of [RFC9097]. As such, this
document adheres to the applicability scope defined in Section 2 of document adheres to the applicability scope defined in Section 2 of
[RFC9097]. [RFC9097].
Some aspects of this protocol and end-host configuration can lead to Some aspects of this protocol and end-host configuration can lead to
support of additional forms of measurement, such as application support of additional forms of measurement, such as application
emulation enabled by creative use of the load rate adjustment emulation enabled by creative use of the load rate adjustment
skipping to change at line 197 skipping to change at line 196
general Congestion Control Algorithm (CCA). Instead, the load rate general Congestion Control Algorithm (CCA). Instead, the load rate
adjustment algorithm's goal is to help determine the Maximum IP-Layer adjustment algorithm's goal is to help determine the Maximum IP-Layer
Capacity in the context of an infrequent, diagnostic, short-term Capacity in the context of an infrequent, diagnostic, short-term
measurement. measurement.
The goal is to harmonize the specified IP-Layer Capacity Metric and The goal is to harmonize the specified IP-Layer Capacity Metric and
Method across the industry, and this protocol supports the Method across the industry, and this protocol supports the
specifications of IETF (see [RFC9097]) and other Standards specifications of IETF (see [RFC9097]) and other Standards
Development Organizations (SDOs) (see, e.g., [TR-471]). Development Organizations (SDOs) (see, e.g., [TR-471]).
The primary application of the protocol described here is the same as The primary application of UDPSTP described here is the same as in
in Section 2 of [RFC7497] where: 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 Large-scale Measurement of this purpose. UDPSTP may be deployed in Large-scale Measurement of
Broadband Performance (LMAP) environments (see [RFC7497]) and other Broadband Performance (LMAP) environments (see [RFC7497]) and other
independent third-party domain measurement server deployments. 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 trusting the results, which are ensured by authenticated benefit from trusting the results, which are ensured by authenticated
communication. communication.
3. Protocol Overview 4. Protocol Overview
All messages defined by this document SHALL use UDP transport. All messages defined by this document SHALL use UDP transport
[RFC0768].
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
requests on a standard UDP Speed Test Protocol port number from the requests on a standard UDP Speed Test Protocol port number from the
other endpoint, the client. other endpoint, the client.
The client requires configuration of a test direction parameter The client requires configuration of a test direction parameter
(upstream or downstream test, where the client performs the role of (upstream or downstream test, where the client performs the role of
sender or receiver, respectively) as well as the hostname or IP sender or receiver, respectively) as well as the hostname or IP
address(es) of the server(s) in order to begin the setup and address(es) of the server(s) in order to begin the setup and
configuration exchanges with the server(s). By default, the client configuration exchanges with the server(s). By default, the client
uses the single, standard UDPSTP port number per connection (see uses the single, standard UDPSTP port number per connection (see
Section 5). If the default port number is not used, the client may Section 6). If the default port number is not used, the client may
require configuration of the control port number used by each server. require configuration of the control port number used by each server.
This would be the case if multiple server instances (processes) This would be the case if multiple server instances (processes)
operate on one or more machines. operate on one or more machines.
Additionally, multi-connection (multi-flow) testing is supported by Additionally, multi-connection (multi-flow) testing is supported by
the protocol. Each connection is independent and attempts to the protocol. Each connection is independent and attempts to
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 is the responsibility of the client process to manage
manage the inter-related connections such as handling the individual 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 5.1) Setup Request (i.e., mcIndex, mcCount, and mcIdent; see Section 6.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 with two connection phases (Control
(Control and Data). As shown below, exchanges 1 and 2 constitute the and Data). As shown below, exchanges 1 and 2 constitute the Control
Control phase, while exchanges 3 and 4 constitute the Data phase. In phase, while exchanges 3 and 4 constitute the Data phase. In this
this document, the term "message" and the term "Protocol Data Unit", document, the term "message" and the term "Protocol Data Unit", or
or "PDU" [RFC5044], are used interchangeably. "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
identified with a host name that resolves to both IPv4/IPv6 identified with a host name that resolves to both IPv4/IPv6
addresses, it is recommended to use the first address returned in addresses, it is recommended to use the first address returned in
the name resolution response, regardless of whether it's IPv4 or the name resolution response, regardless of whether it is IPv4 or
IPv6. Thus, the decision on the preferred IP address family is IPv6. Thus, the decision on the preferred IP address family is
left to the name resolver's default behavior. Support for left to the name resolver's default behavior. Support for
separate IPv4 and IPv6 measurements or an IPv4 and IPv6 multi- separate IPv4 and IPv6 measurements or an IPv4 and IPv6 multi-
connection setup are left for future improvement. The client connection setup are left for future improvement. The client
then requests to begin a test by communicating its UDPSTP then requests to begin a test by communicating its UDPSTP
protocol version, intended security mode, and datagram size protocol version, intended security mode, and datagram size
support. The server either confirms matching a configuration or support. The server either confirms matching a configuration or
rejects the connection request. If the request is accepted, the rejects the connection request. If the request is accepted, the
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-
skipping to change at line 382 skipping to change at line 382
<----- Status Feedback PDUs <----- Status Feedback PDUs
After expiry of server's test duration timer... After expiry of server's test duration timer...
<----- Status Feedback PDU (TEST_ACT_STOP) <----- Status Feedback PDU (TEST_ACT_STOP)
Load PDU (TEST_ACT_STOP) -----> Load PDU (TEST_ACT_STOP) ----->
Figure 1: Successful UDPSTP Message Exchanges Figure 1: Successful UDPSTP Message Exchanges
3.1. Fixed-Rate Testing 4.1. Fixed-Rate Testing
A network operator who is certain of the IP-Layer Capacity to be A network operator who is certain of the IP-Layer Capacity to be
validated can execute a fixed-rate test of the IP-Layer Capacity and validated can execute a fixed-rate test of the IP-Layer Capacity and
avoid activating the measurement load rate adjustment algorithm (see avoid activating the measurement load rate adjustment algorithm (see
Section 8.1 of [RFC9097]). Fixed-rate testing SHOULD only be Section 8.1 of [RFC9097]). Fixed-rate testing SHOULD only be
activated for operation and maintenance purposes by operators within activated for operation and maintenance purposes by operators within
their local network domain. their local network domain.
If a subscriber requests a diagnostic test from the network operator, If a subscriber requests a diagnostic test from the network operator,
it strongly implies that there is no certainty on the bottleneck it strongly implies that there is no certainty on the bottleneck
capacity and initiating a UDP Speed Test based on the load adjustment capacity and initiating a UDP Speed Test based on the load adjustment
algorithm is RECOMMENDED. To protect against misuse, a client (and algorithm is RECOMMENDED. To protect against misuse, a client (and
in general, a consumer) MUST NOT be able to initiate a fixed-rate in general, a consumer) MUST NOT be able to initiate a fixed-rate
test. A network operator may conduct a fixed-rate test for a stable test. A network operator may conduct a fixed-rate test for a stable
measurement at or near the maximum determined by the load rate measurement at or near the maximum determined by the load rate
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 4.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 UDPSTP 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
skipping to change at line 428 skipping to change at line 428
other flows has been considered, testing could be extended to include other flows has been considered, testing could be extended to include
adjacent operational domains for which there is also a testing adjacent operational domains for which there is also a testing
agreement. agreement.
Concurrent tests that congest a common bottleneck will impair the Concurrent tests that congest a common bottleneck will impair the
measurement and result in additional congestion. Concurrent measurement and result in additional congestion. Concurrent
measurements to measure the maximum capacity on a single path are measurements to measure the maximum capacity on a single path are
counterproductive. The number of concurrent independent tests of a counterproductive. The number of concurrent independent tests of a
path SHALL be limited to one, regardless of the number of flows. path SHALL be limited to one, regardless of the number of flows.
A load rate adjustment algorithm (see Section 4.1) is required to A load rate adjustment algorithm (see Section 5.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 5. 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 the optional operational specification related to security and the optional
checksum. Due to the additional complexities, and loss of the direct checksum. Due to the additional complexities, and loss of the direct
mapping of packets to datagrams between Layer 3 and Layer 4, it is mapping of packets to datagrams between Layer 3 and Layer 4, it is
recommended that Layer 3 fragmentation be avoided. A simplified recommended that Layer 3 fragmentation be avoided. A simplified
approach is to choose the default datagram size that is small enough approach is to choose the default datagram size that is small enough
to prevent fragmentation. This version of the specification does not to prevent fragmentation. This version of the specification does not
support Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) support Datagram Packetization Layer Path MTU Discovery (DPLPMTUD)
skipping to change at line 458 skipping to change at line 458
bit 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 5.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 listed in this
the currently standardized load rate adjustment algorithms B section and the currently standardized load rate adjustment
[Y.1540Amd2] and C [TR-471] result from years of experiments and algorithms B [Y.1540Amd2] and C [TR-471] result from years of
testing by the original authors. These tests were performed in labs, experiments and testing by the original authors. These tests were
and also in the Internet, and covered a set of different fixed, performed in labs, and also in the Internet, and covered a set of
broadband, mobile, and wireless access types and technologies in different fixed, broadband, mobile, and wireless access types and
different countries and continents. Further, the load rate technologies in different countries and continents. Further, the
adjustment algorithm requirements listed below reflect feedback from load rate adjustment algorithm requirements listed below reflect
performance measurement experts, as well as changes resulting from feedback from performance measurement experts, as well as changes
the standardization of [RFC9097] (reflected also in algorithm B resulting from the standardization of [RFC9097] (reflected also in
[Y.1540Amd2], which updates a prior version of this algorithm). algorithm B [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
requirements is as follows: requirements are as follows:
1. The measurement load rate adjustment algorithm described in this 1. The measurement load rate adjustment algorithm described in this
section MUST NOT be used as a general CCA. section MUST NOT be used as a general CCA.
2. This specification MUST only be used in the application of 2. This specification MUST only be used in the application of
diagnostic and operations measurements. diagnostic and operations measurements.
3. Both Load PDU messages and Status Feedback PDU messages MUST 3. Both Load PDU messages and Status Feedback PDU messages MUST
contain sequence numbers. contain sequence numbers.
skipping to change at line 550 skipping to change at line 551
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 5.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 12.3.5.
4.3. Security Mode Operations 5.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
preferred for large-scale servers or low-end client devices where preferred for large-scale servers or low-end client devices where
processing power is a consideration (see Section 2). processing power is a consideration (see Section 3).
2. An OPTIONAL mode with the additional authentication of the Status 2. An OPTIONAL mode with the additional authentication of the Status
Feedback messages during the Data phase. This mode may be Feedback messages during the Data phase. This mode may be
preferred for environments that desire an additional level of preferred for environments that desire an additional level of
message integrity verification throughout the test (see message integrity verification throughout the test (see
Section 2). Section 3).
The requirements discussed hereafter refer to the PDUs in Sections 5 The requirements discussed hereafter refer to the PDUs in Sections 6
and 6 below, primarily the authMode, keyId, authUnixTime, and and 7 below, primarily the authMode, keyId, authUnixTime, and
authDigest fields. The roles in this section have been generalized authDigest fields. The roles in this section have been generalized
so that the requirements for the PDU sender and receiver can be re- so that the requirements for the PDU sender and receiver can be re-
used and referred to by other sections within this document. Each used and referred to by other sections within this document. Each
successive mode increases security but comes with additional successive mode increases security but comes with additional
performance impacts and complexity. The protocol is used with performance impacts and complexity. The protocol is used with
unsubstantial payload, and it may operate on very low-end devices. unsubstantial payload, and it may operate on very low-end devices.
Offering the flexibility of various security operation modes allows Offering the flexibility of various security operation modes allows
for accommodation of available end-device resources. In general, an for accommodation of available end-device resources. In general, an
active measurement technique as the one defined by this document is active measurement technique as the one defined by this document is
better suited to protect the privacy of those involved in better suited to protect the privacy of those involved in
measurements [RFC7594]. measurements [RFC7594].
A load rate adjustment method needs to satisfy the requirements A load rate adjustment method needs to satisfy the requirements
listed in Section 4.1. This is necessary also to avoid potentially listed in Section 5.1. This is necessary also to avoid potentially
inducing congestion after there is an overload or loss (including inducing congestion after there is an overload or loss (including
loss on the control path). loss on the control path).
4.3.1. Mode 1: Required Authenticated Mode 5.3.1. Mode 1: Required Authenticated Mode
In this mode, the client and the server SHALL be configured to use In this mode, the client and the server SHALL be configured to use
one of a number of shared secret keys, designated via the numeric one of a number of shared secret keys, designated via the numeric
keyId field (see Section 4.4). This key SHALL be used as input to keyId field (see Section 5.4). This key SHALL be used as input to
the KDF, as specified in Section 4.4.1, to obtain the actual keys the KDF, as specified in Section 5.4.1, to obtain the actual keys
used by the client and server for authentication. used by the client and server for authentication.
During the Control phase, the sender SHALL read the current system During the Control phase, the sender SHALL read the current system
(wall-clock) time and populate the authUnixTime field and next (wall-clock) time and populate the authUnixTime field and next
calculate the 32-octet HMAC-SHA-256 hash of the entire PDU according calculate the 32-octet HMAC-SHA-256 hash of the entire PDU according
to Section 6 of [RFC6234] (with the authDigest and checkSum preset to to Section 6 of [RFC6234] (with the authDigest and checkSum preset to
all zeroes). The authDigest field is filled by the result, then the all zeroes). The authDigest field is filled by the result, then the
packet is sent to the receiver. The value in the authUnixTime field packet is sent to the receiver. The value in the authUnixTime field
is a 32-bit timestamp, and a 10-second tolerance window (+/- 5 is a 32-bit timestamp, and a 10-second tolerance window (+/- 5
seconds) SHALL be used by the receiver to distinguish a subsequent seconds) SHALL be used by the receiver to distinguish a subsequent
skipping to change at line 629 skipping to change at line 630
Control phase and SHOULD implement silent rejection (no further Control phase and SHOULD implement silent rejection (no further
packets sent on the address/port pairs). The exception is when the packets sent on the address/port pairs). The exception is when the
testing hosts have been configured for troubleshooting Control phase testing hosts have been configured for troubleshooting Control phase
failures and 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 6) and the
Test Activation exchange (Section 6). Test Activation exchange (Section 7).
4.3.2. Mode 2: Optional Authenticated Mode for Data Phase 5.3.2. Mode 2: Optional Authenticated Mode for Data Phase
This mode incorporates Authenticated mode 1. When using the optional This mode incorporates Authenticated mode 1. When using the optional
authentication during the Data phase, authentication SHALL also be authentication during the Data phase, authentication SHALL also be
applied to the Status Feedback PDU (see Section 7.2). The client applied to the Status Feedback PDU (see Section 8.2). The client
sends the Status PDU in a downstream test, and the server sends it in sends the Status PDU in a downstream test, and the server sends it in
an upstream test. an upstream test.
The Status PDU sender SHALL 1) read the current system (wall-clock) The Status PDU sender SHALL 1) read the current system (wall-clock)
time and populate the authUnixTime field, 2) calculate the authDigest time and populate the authUnixTime field, 2) calculate the authDigest
field of the entire Status PDU (with the authDigest and checkSum field of the entire Status PDU (with the authDigest and checkSum
preset to all zeroes), and 3) send the packet to the receiver. The preset to all zeroes), and 3) send the packet to the receiver. The
values of authUnixTime field and authDigest field are determined as values of authUnixTime field and authDigest field are determined as
defined by Section 4.3.1. defined by Section 5.3.1.
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 will require that as protocol version). Validation of the authDigest will require that
it be extracted from the PDU and the field, along with the checkSum it be extracted from the PDU and the field, along with the checkSum
field, zeroed prior to the HMAC calculation used for comparison. field, zeroed prior to the HMAC calculation used for comparison.
If the authentication validation fails, the receiver SHALL ignore the If the authentication validation fails, the receiver SHALL ignore the
message. If the watchdog timer expires (due to successive failed message. If the watchdog timer expires (due to successive failed
validations), the test session will prematurely terminate (and no validations), the test session will prematurely terminate (and no
further load traffic SHALL be transmitted). This is necessary also further load traffic SHALL be transmitted). This is necessary also
to avoid potentially inducing congestion after there is an overload to avoid potentially inducing congestion after there is an overload
or loss on the control path. or loss on the control path.
If this optional mode has not been selected, then the keyId, If this optional mode has not been selected, then the keyId,
authUnixTime, and authDigest fields of the Status PDU (see authUnixTime, and authDigest fields of the Status PDU (see
Section 7.2) SHALL be set to all zeroes. Section 8.2) SHALL be set to all zeroes.
4.4. Key Management 5.4. Key Management
Section 2 of [RFC7210] specifies a conceptual database for long-lived Section 2 of [RFC7210] specifies a conceptual database for long-lived
cryptographic keys. The key table SHALL be used with the REQUIRED cryptographic keys. The key table SHALL be used with the REQUIRED
authentication mode and the OPTIONAL authentication mode (using the authentication mode and the OPTIONAL authentication mode (using the
same key). For authentication, this key SHALL only be used as input same key). For authentication, this key SHALL only be used as input
to the KDF, as specified in Section 4.4.1, to derive the actual keys to the KDF, as specified in Section 5.4.1, to derive the actual keys
used for authentication processing. Key rotation and related used for authentication processing. Key rotation and related
management specifics are beyond the scope of this document. management specifics are beyond the scope of this document.
The key table SHALL have (at least) the following fields per The key table SHALL have (at least) the following fields per
Section 2 of [RFC7210]: Section 2 of [RFC7210]:
* AdminKeyName * AdminKeyName
* LocalKeyName * LocalKeyName
skipping to change at line 699 skipping to change at line 700
* 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) 5.4.1. Key Derivation Function (KDF)
A Key Derivation Function (KDF) is a one-way function that provides A KDF is a one-way function that provides cryptographic separation of
cryptographic separation of key material. The protocol requires a key material. The protocol requires a KDF to securely derive
KDF to securely derive cryptographic keys used for authentication of cryptographic keys used for authentication of protocol messages. The
protocol messages. The inclusion of a KDF ensures that keys are inclusion of a KDF ensures that keys are generated in a standardized,
generated in a standardized, cryptographically secure manner, cryptographically secure manner, reducing the risk of key compromise
reducing the risk of key compromise and enabling interoperability and enabling interoperability across implementations. The benefits
across implementations. The benefits of using a KDF include: of using a KDF include:
* Security: A KDF produces keys with high entropy, resistant to * Security: A KDF produces keys with high entropy, resistant to
brute-force and related-key attacks, ensuring robust protection brute-force and related-key attacks, ensuring robust protection
for protocol communications. for protocol communications.
* Flexibility: The KDF allows derivation of multiple keys from a * Flexibility: The KDF allows derivation of multiple keys from a
single shared secret, supporting distinct keys for client and single shared secret, supporting distinct keys for client and
server authentication. server authentication.
* Standardization: By adhering to established cryptographic * Standardization: By adhering to established cryptographic
skipping to change at line 731 skipping to change at line 732
* Efficiency: The KDF enables efficient key generation without * Efficiency: The KDF enables efficient key generation without
requiring additional key exchange mechanisms, minimizing protocol requiring additional key exchange mechanisms, minimizing protocol
overhead. overhead.
The KDF algorithm SHALL be a Key Derivation Function in Counter Mode, The KDF algorithm SHALL be a Key Derivation Function in Counter Mode,
as specified in Section 4.1 of [NIST800-108]. This algorithm uses a as specified in Section 4.1 of [NIST800-108]. This algorithm uses a
counter-based mechanism to generate key material from a shared counter-based mechanism to generate key material from a shared
secret, ensuring deterministic and secure key derivation. The secret, ensuring deterministic and secure key derivation. The
Pseudorandom Function (PRF) used in the KDF SHALL be HMAC-SHA-256, as Pseudorandom Function (PRF) used in the KDF SHALL be HMAC-SHA-256, as
defined in Section 6 of [RFC6234]. IANA has assigned "HMAC-SHA-256" defined in Section 6 of [RFC6234]. IANA has assigned "HMAC-SHA-256"
as a new KeyTable KDF (Section 11.2). as a new KeyTable KDF (Section 12.2).
The KDF SHALL use the following parameters: The KDF SHALL use the following parameters:
* Kin (key-derivation key): The shared key as identified by the * Kin (key-derivation key): The shared key as identified by the
keyId field in the PDU. keyId field in the PDU.
* Label: The fixed string "UDPSTP" (without quotes), encoded as a * Label: The fixed string "UDPSTP" (without quotes), encoded as a
UTF-8 string, used to bind the derived keys to this specific UTF-8 string, used to bind the derived keys to this specific
protocol. protocol.
skipping to change at line 783 skipping to change at line 784
SHALL be used for all subsequent PDUs sent between them for that test SHALL be used for all subsequent PDUs sent between them for that test
connection. As such, the KDF is only required to be executed once by connection. As such, the KDF is only required to be executed once by
the client and server for each test connection. the client and server for each test connection.
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 5.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 unique source and destination addresses as well as port numbers
(i.e., a 4-tuple) by sending a packet using that 4-tuple for a given (i.e., a 4-tuple) by sending a packet using that 4-tuple for a given
transport protocol. The client's interaction with its firewall transport protocol. The client's interaction with its firewall
depends on this 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 number of the server.
messages sent by the client to the server use this standard UDP port. All messages sent by the client to the server use this standard UDP
port number.
The server uses one ephemeral UDP port per test connection. Assuming The server uses one ephemeral UDP port number per test connection.
that the firewall administration at the server does not allow an open Assuming that the firewall administration at the server does not
UDP ephemeral port range, then the server MUST send a Null Request to allow an open UDP ephemeral port range, then the server MUST send a
the client from the ephemeral port communicated to the client in the Null Request to the client from the ephemeral port number
Test Setup Response. The Null Request may not reach the client: it communicated to the client in the Test Setup Response. The Null
may be discarded by the client's firewall. Request may not reach the client: it may be discarded by the client's
firewall.
If the server firewall administration allows an open UDP ephemeral If the server firewall administration allows an open UDP ephemeral
port range, then the Null Request is not strictly necessary. port range, then the Null Request is not strictly necessary.
However, the availability of an open port range policy cannot be However, the availability of an open port range policy cannot be
assumed. assumed.
Network Address Translators (NATs) are expected to offer support of a Network Address Translators (NATs) are expected to offer support of a
wider set of operational configurations as compared to firewalls. wider set of operational configurations as compared to firewalls.
Specifications covering NAT behavior, apart from the above, are out Specifications covering NAT behavior, apart from the above, are out
of the scope of this document, as are combined implementations of NAT of the scope of this document, as are combined implementations of NAT
and firewalls too. and firewalls too.
4.6. Optional Checksum 5.6. Optional Checksum
The protocol MUST utilize the standard UDP checksum for all IPv4 and The protocol MUST utilize the standard UDP checksum for all IPv4 and
IPv6 datagrams it sends. The purpose of this checksum is to protect IPv6 datagrams it sends. The purpose of this checksum is to protect
the intended recipient as well as other recipients to whom a the intended recipient as well as other recipients to whom a
corrupted packet may be delivered. This provides: corrupted packet may be delivered. This provides:
* Protection of the endpoint transport state from unnecessary extra * Protection of the endpoint transport state from unnecessary extra
state (e.g., Invalid state from rogue packets). state (e.g., Invalid state from rogue packets).
* Protection of the endpoint transport state from corruption of * Protection of the endpoint transport state from corruption of
skipping to change at line 865 skipping to change at line 868
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
checkSum field. However, because authentication is not applicable to checkSum field. However, because authentication is not applicable to
the Load PDU, the checkSum field SHALL be utilized by the sender the Load PDU, the checkSum field SHALL be utilized by the sender
whenever UDP data integrity may be uncertain (as outlined above). whenever UDP data integrity may be uncertain (as outlined above).
5. Test Setup Request and Response 6. Test Setup Request and Response
The client source IP address and the server destination IP address The client source IP address and the server destination IP address
MUST NOT be a broadcast or multicast address. Any Test Setup Request MUST NOT be a broadcast or multicast address. Any Test Setup Request
or Test Setup Response packet containing a multicast or broadcast or Test Setup Response packet containing a multicast or broadcast
source or destination IP address MUST be silently dropped and source or destination IP address MUST be silently dropped and
ignored. ignored.
The measurement method and the protocol specified by this document The measurement method and the protocol specified by this document
are expected to function with unicast and anycast IP addresses. are expected to function with unicast and anycast IP addresses.
5.1. Client Generates Test Setup Request 6.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
(i.e., the UDP socket will be closed and an error message will be (i.e., the UDP socket will be closed and an error message will be
skipping to change at line 928 skipping to change at line 931
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| keyId | reservedAuth1 | checkSum | | keyId | reservedAuth1 | checkSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Test Setup PDU Layout Figure 2: Test Setup PDU Layout
Additional details regarding the Setup Request and Response fields Additional details regarding the Setup Request and Response fields
are as follows: are as follows:
pduId: A two-octet field. IANA has assigned the hex value 0xACE1 pduId: A two-octet field. IANA has assigned the hex value 0xACE1
(Section 11.3.1). (Section 12.3.1).
protocolVer: A two-octet field identifying the actual protocol protocolVer: A two-octet field identifying the actual protocol
version. IANA has assigned 20 as the value (Section 11.3.2). version. IANA has assigned 20 as the value (Section 12.3.2).
mcIndex: A one-octet field indicating the index of a connection mcIndex: A one-octet field indicating the index of a connection
relative to all connections that make up a single test (starting relative to all connections that make up a single test (starting
at 0, incremented by 1 per connection). It is used to at 0, incremented by 1 per connection). It is used to
differentiate separate connections within a multi-connection test. differentiate separate connections within a multi-connection test.
An implementation may restrict the number of connections supported An implementation may restrict the number of connections supported
for a single test to a value less than or equal to 255. for a single test to a value less than or equal to 255.
mcCount: A one-octet field indicating the total count of connections mcCount: A one-octet field indicating the total count of connections
that the client is attempting to set up. that the client is attempting to set up.
skipping to change at line 972 skipping to change at line 975
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
and populated by the server in the Test Setup Response. It and populated by the server in the Test Setup Response. It
contains the UDP ephemeral port number on the server that the contains the UDP ephemeral port number on the server that the
client has to use for the Test Activation Request and subsequent client has to use for the Test Activation Request and subsequent
Load or Status PDUs. Load or Status PDUs.
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.3: bits in this bitmap; see Section 12.3.3:
CHSR_JUMBO_STATUS: This bit SHALL be set by default. By default, CHSR_JUMBO_STATUS: This bit SHALL be set by default. By default,
sending rates up to 1 Gbps SHALL NOT produce IP packet sizes sending rates up to 1 Gbps SHALL NOT produce IP packet sizes
greater than 1250 bytes (unless CHSR_TRADITIONAL_MTU is set), greater than 1250 bytes (unless CHSR_TRADITIONAL_MTU is set),
while rates above 1 Gbps MAY produce IP packet sizes up to 9000 while rates above 1 Gbps MAY produce IP packet sizes up to 9000
bytes. When CHSR_JUMBO_STATUS is not set, all sending rates bytes. When CHSR_JUMBO_STATUS is not set, all sending rates
SHALL NOT produce IP packet sizes greater than 1250 bytes SHALL NOT produce IP packet sizes greater than 1250 bytes
(unless CHSR_TRADITIONAL_MTU is set). (unless CHSR_TRADITIONAL_MTU is set).
CHSR_TRADITIONAL_MTU: This bit SHALL NOT be set by default. If CHSR_TRADITIONAL_MTU: This bit SHALL NOT be set by default. If
set, sending rates up to 1 Gbps MAY produce IP packets up to set, sending rates up to 1 Gbps MAY produce IP packets up to
the traditional size of 1500 bytes. If CHSR_JUMBO_STATUS is the traditional size of 1500 bytes. If CHSR_JUMBO_STATUS is
simultaneously not set, all sending rates SHALL NOT produce IP simultaneously not set, all sending rates SHALL NOT produce IP
packets greater than the traditional size of 1500 bytes. packets greater than the traditional size of 1500 bytes.
Other bit positions are left unassigned per this document. Other bit positions are left unassigned per this document.
authMode: A one-octet field. The authMode field currently has two authMode: A one-octet field. The authMode field currently has two
values assigned (see Section 11.3.4). One of the following has to values assigned (see Section 12.3.4). One of the following has to
be set (see Section 4.3 for requirements and details of be set (see Section 5.3 for requirements and details of
operation): operation):
AUTHMODE_1: Required Authentication for Control phase. AUTHMODE_1: Required Authentication for Control phase.
AUTHMODE_2: Optional Authentication for Control and Data phase AUTHMODE_2: Optional Authentication for Control and Data phase
(Status Feedback PDU only). (Status Feedback PDU only).
A range of 60 through 63 is reserved for experimentation. IANA has A range of 60 through 63 is reserved for experimentation. IANA has
created a registry for the assigned values; see the IANA created a registry for the assigned values; see the IANA
Considerations section. Considerations section.
skipping to change at line 1023 skipping to change at line 1026
keyId: A one-octet field carrying localKeyName, the numeric key keyId: A one-octet field carrying localKeyName, the numeric key
identifier for a key in the shared key table. identifier for a key in the shared key table.
reservedAuth1: A one-octet field. This field MUST be set to 0 and reservedAuth1: A one-octet field. This field MUST be set to 0 and
MUST be ignored upon receipt. Consistent naming and placement of MUST be ignored upon receipt. Consistent naming and placement of
the reservedAuth1 field across all PDUs is done to minimize the reservedAuth1 field across all PDUs is done to minimize
authentication-related changes in future UDPSTP versions. authentication-related changes in future UDPSTP versions.
checkSum: A two-octet field containing an optional checksum of the checkSum: A two-octet field containing an optional checksum of the
entire PDU (see Section 4.6 for guidance). The calculation is entire PDU (see Section 5.6 for guidance). The calculation is
done as the very last step of building the PDU, with the checkSum done as the very last step of building the PDU, with the checkSum
field set to zero. field set to zero.
5.2. Server Test Setup Request Processing and Response Generation 6.2. Server Test Setup Request Processing and Response Generation
This section describes the processes at the server that are used to This section describes the processes at the server that are used to
evaluate the Test Setup Request and determine the next steps. When evaluate the Test Setup Request and determine the next steps. When
the server receives the Setup Request, it SHALL first perform the the server receives the Setup Request, it SHALL first perform the
following: following:
Message Verification Procedure: Message Verification Procedure:
1. Verify that the size of the message is correct. 1. Verify that the size of the message is correct.
2. If the optional checkSum field is being utilized, validate the 2. If the optional checkSum field is being utilized, validate the
checksum as described in Section 4.6 and (if valid) zero the checksum as described in Section 5.6 and (if valid) zero the
checkSum field prior to authentication verification. checkSum field prior to authentication verification.
3. Verify that the authMode value is valid and appropriate (per 3. Verify that the authMode value is valid and appropriate (per
Section 4.3) for the message type. Section 5.3) for the message type.
4. If the authMode is valid and appropriate, authenticate the 4. If the authMode is valid and appropriate, authenticate the
message by checking the authDigest as prescribed in Section 4.3. message by checking the authDigest as prescribed in Section 5.3.
5. If the message is authentic, check the authUnixTime field for 5. If the message is authentic, check the authUnixTime field for
acceptable immediacy. acceptable immediacy.
Note: If any of the above checks fail, the message SHALL be Note: If any of the above checks fail, the message SHALL be
considered invalid. considered invalid.
5.2.1. Test Setup Request Processing -- Rejection 6.2.1. Test Setup Request Processing -- Rejection
The server SHALL then evaluate the other fields in the protocol The server SHALL then evaluate the other fields in the protocol
header, such as the protocol version, the PDU ID (to validate the header, such as the protocol version, the PDU ID (to validate the
type of message), the maximum bandwidth requested for the test, and type of message), the maximum bandwidth requested for the test, and
the modifierBitmap for use of options such as Jumbo datagram status the modifierBitmap for use of options such as Jumbo datagram status
and Traditional MTU (1500 bytes). and Traditional MTU (1500 bytes).
If the client has selected options for If the client has selected options for
* Jumbo datagram support (modifierBitmap), * Jumbo datagram support (modifierBitmap),
skipping to change at line 1109 skipping to change at line 1112
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 Test Setup Setup Response PDU is structured identically to the Test Setup
Request PDU and SHALL retain the original values received in it, with Request PDU and SHALL retain the original values received in it, with
the following 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 12.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.
* The authUnixTime field is updated to the current system (wall- * The authUnixTime field is updated to the current system (wall-
clock) time and, after the authDigest and checkSum fields are clock) time and, after the authDigest and checkSum fields are
zeroed, the authDigest is recalculated and inserted. If the zeroed, the authDigest is recalculated and inserted. If the
optional checkSum field is being utilized, it is then also optional checkSum field is being utilized, it is then also
calculated and inserted. calculated and inserted.
skipping to change at line 1177 skipping to change at line 1180
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
}; };
#define SHA256_KEY_LEN 32 // Authentication key length #define SHA256_KEY_LEN 32 // Authentication key length
<CODE ENDS> <CODE ENDS>
Figure 3: Test Setup PDU Figure 3: Test Setup PDU
5.2.2. Test Setup Request Processing -- Acceptance 6.2.2. Test Setup Request Processing -- Acceptance
If the server finds that the Setup Request matches its configuration If the server finds that the Setup Request matches its configuration
and is otherwise acceptable, the server SHALL initiate a new and is otherwise acceptable, the server SHALL initiate a new
connection to receive the Test Activation Request from the client, connection to receive the Test Activation Request from the client,
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 6)
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 Test Setup Setup Response PDU is structured identically to the Test Setup
Request PDU and SHALL retain the original values received in it, with Request PDU and SHALL retain the original values received in it, with
the following 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
skipping to change at line 1213 skipping to change at line 1216
for the client's Test Activation Request and all subsequent for the client's Test Activation Request and all subsequent
communication. communication.
* The authUnixTime field is updated to the current system (wall- * The authUnixTime field is updated to the current system (wall-
clock) time and, after the authDigest and checkSum fields are clock) time and, after the authDigest and checkSum fields are
zeroed, the authDigest is recalculated and inserted. If the zeroed, the authDigest is recalculated and inserted. If the
optional checkSum field is being utilized, it is then also optional checkSum field is being utilized, it is then also
calculated and inserted. calculated and inserted.
Finally, the new UDP connection associated with the new socket and Finally, the new UDP connection associated with the new socket and
port are made ready, and the server awaits further communication port number are made ready, and the server awaits further
there. communication there.
To ensure that a server's local firewall will successfully allow To ensure that a server's local firewall will successfully allow
packets received for the new ephemeral port, the server SHALL packets received for the new ephemeral port number, the server SHALL
immediately send a Null Request with the corresponding values immediately send a Null Request with the corresponding values
including the source and destination IP addresses and port numbers. including the source and destination IP addresses and port numbers.
The source port SHALL be the new ephemeral port. This operation The source port SHALL be the new ephemeral port. This operation
allows communication to the server even when the server's local allows communication to the server even when the server's local
firewall prohibits open ranges of ephemeral ports. The packet is not firewall prohibits open ranges of ephemeral ports. The packet is not
expected to arrive successfully at the client if the client-side expected to arrive successfully at the client if the client-side
firewall blocks unexpected traffic. If the Null Request arrives at firewall blocks unexpected traffic. If the Null Request arrives at
the client, it is a confirmation that further exchanges are possible the client, it is a confirmation that further exchanges are possible
on the new port-pair (but this is not strictly necessary). If on the new port-pair (but this is not strictly necessary). If
received, the client SHALL follow the Message Verification Procedure received, the client SHALL follow the Message Verification Procedure
listed in Section 5.2, Paragraph 2. Note that there is no response listed in Section 6.2, Paragraph 2. Note that there is no response
to a Null Request. to a Null 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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmdRequest | cmdResponse | reserved1 | authMode | | cmdRequest | cmdResponse | reserved1 | authMode |
skipping to change at line 1254 skipping to change at line 1257
| keyId | reservedAuth1 | checkSum | | keyId | reservedAuth1 | checkSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Null Request PDU Layout Figure 4: Null Request PDU Layout
The authentication and checkSum fields follow the same methodology as The authentication and checkSum fields follow the same methodology as
with the Setup Request and Response. with the Setup Request and Response.
Additional details regarding the Null Request fields are as follows: Additional details regarding the Null Request fields are as follows:
pduId: IANA has assigned the hex value 0xDEAD (Section 11.3.1). pduId: IANA has assigned the hex value 0xDEAD (Section 12.3.1).
cmdRequest: Set to CHNR_CREQ_NULLREQ to indicate a Null Request cmdRequest: Set to CHNR_CREQ_NULLREQ to indicate a Null Request
message. message.
cmdResponse: Set to CHNR_CRSP_NONE. cmdResponse: Set to CHNR_CRSP_NONE.
authMode: Same as in Section 5.1. authMode: Same as in Section 6.1.
authUnixTime: Same as in Section 5.1. authUnixTime: Same as in Section 6.1.
authDigest: Same as in Section 5.1. authDigest: Same as in Section 6.1.
keyId: Same as in Section 5.1. keyId: Same as in Section 6.1.
reservedAuth1: Same as in Section 5.1. reservedAuth1: Same as in Section 6.1.
checkSum: Same as in Section 5.1. checkSum: Same as in Section 6.1.
If a Test Activation Request is not subsequently received from the If a Test Activation Request is not subsequently received from the
client on the new ephemeral port number before the watchdog timer client on the new ephemeral port number before the watchdog timer
expires, the server SHALL close the socket and deallocate the expires, the server SHALL close the socket and deallocate the
associated resources. associated resources.
The Null Request message PDU SHALL be organized as follows: The Null Request message PDU SHALL be organized as follows:
<CODE BEGINS> <CODE BEGINS>
// //
skipping to change at line 1306 skipping to change at line 1309
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>
Figure 5: Null Request PDU Figure 5: Null Request PDU
5.3. Setup Response Processing at the Client 6.3. Setup Response Processing at the Client
When the client receives the Test Setup Response message, it SHALL When the client receives the Test Setup Response message, it SHALL
first follow the Message Verification Procedure listed in first follow the Message Verification Procedure listed in
Section 5.2, Paragraph 2. Section 6.2, Paragraph 2.
The client SHALL then proceed to evaluate the other fields in the The client SHALL then proceed to evaluate the other fields in the
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 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 7. 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 7.1. Client Generates Test Activation Request
Upon a successful setup exchange, the client SHALL compose and send Upon a successful setup exchange, the client SHALL compose and send
the Test Activation Request to the UDP port number the server the Test Activation Request to the UDP port number the server
communicated in the Test Setup Response (the new ephemeral port, and communicated in the Test Setup Response (the new ephemeral port, and
not the standard UDPSTP port). not the standard UDPSTP port).
The UDP PDU format layout is as follows (big-endian AB): The UDP PDU format layout is as follows (big-endian AB):
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
skipping to change at line 1396 skipping to change at line 1399
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| keyId | reservedAuth1 | checkSum | | keyId | reservedAuth1 | checkSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Test Activation PDU Layout Figure 6: Test Activation PDU Layout
Fields are populated based on default values or command-line options. Fields are populated based on default values or command-line options.
The authentication and checkSum fields follow the same methodology as The authentication and checkSum fields follow the same methodology as
with the Setup Request and Response. with the Setup Request and Response.
pduId: IANA has assigned the hex value 0xACE2 (Section 11.3.1). pduId: IANA has assigned the hex value 0xACE2 (Section 12.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 12.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: A two-octet field. The lower threshold on the range of lowThresh: A two-octet field. The lower threshold on the range of
Round-Trip Time (RTT) variation (the range is composed of values Round-Trip Time (RTT) variation (the range is composed of values
above the minimum RTT); see also Table 3 [TR-471]. above the minimum RTT); see also Table 3 [TR-471].
upperThresh: A two-octet field. The upper threshold on the range of upperThresh: A two-octet field. The upper threshold on the range of
RTT variation (the range is composed of values above the minimum RTT variation (the range is composed of values above the minimum
skipping to change at line 1460 skipping to change at line 1463
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, out-of-order, and sequence number errors. When False, loss, out-of-order, and
duplicate totals are all counted as sequence number errors. duplicate totals are all counted as sequence number errors.
Default is 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 12.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 12.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 Activation Response for an upstream test to communicate the
(initial) Load PDU transmission parameters the client SHALL use. (initial) Load PDU transmission parameters the client SHALL use.
For a Test Activation Request or a downstream test, this structure For a Test Activation Request or a downstream test, this structure
SHALL be zeroed. Two sets of periodic transmission parameters are SHALL be zeroed. Two sets of periodic transmission parameters are
available, allowing for dual independent transmitters (to support available, allowing for dual independent transmitters (to support
a high degree of rate granularity). The fields are defined as a high degree of rate granularity). The fields are defined as
follows: follows:
skipping to change at line 1502 skipping to change at line 1505
udpAddon2: A four-octet field indicating the size of a single udpAddon2: A four-octet field indicating the size of a single
Load PDU to be sent at the end of the txInterval2 send Load PDU to be sent at the end of the txInterval2 send
sequence, even when udpPayload2 or burstSize2 are zero and sequence, even when udpPayload2 or burstSize2 are zero and
result in no 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 6.1.
authUnixTime: Same as in Section 5.1. authUnixTime: Same as in Section 6.1.
authDigest: Same as in Section 5.1. authDigest: Same as in Section 6.1.
keyId: Same as in Section 5.1. keyId: Same as in Section 6.1.
reservedAuth1: Same as in Section 5.1. reservedAuth1: Same as in Section 6.1.
checkSum: Same as in Section 5.1. checkSum: Same as in Section 6.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)
skipping to change at line 1582 skipping to change at line 1585
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>
Figure 7: Test Activation PDU Figure 7: Test Activation PDU
6.2. Server Processes Test Activation Request and Generates Response 7.2. Server Processes Test Activation Request and Generates Response
After the server receives the Test Activation Request on the new After the server receives the Test Activation Request on the new
connection, it chooses to accept, ignore, or modify any of the test connection, it chooses to accept, ignore, or modify any of the test
parameters. When the server replies to the Test Activation Request parameters. When the server replies to the Test Activation Request
message, the Test Activation Response PDU is structured identically message, the Test Activation Response PDU is structured identically
to the Request PDU and SHALL retain the original values received in to the Request PDU and SHALL retain the original values received in
it unless they are explicitly coerced to a server-acceptable value. it unless they are explicitly coerced to a server-acceptable value.
When the server receives the Test Activation Request message, it When the server receives the Test Activation Request 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 6.2, Paragraph 2.
6.2.1. Server Rejects or Modifies Request 7.2.1. Server Rejects or Modifies Request
When evaluating the Test Activation Request, the server MAY allow the When evaluating the Test Activation Request, the server MAY allow the
client to specify its own fixed or starting send rate via client to specify its own fixed or starting send rate via
srIndexConf. srIndexConf.
Alternatively, the server MAY enforce a maximum limit of the fixed or Alternatively, the server MAY enforce a maximum limit of the fixed or
starting send rate, which the client can successfully request. If starting send rate, which the client can successfully request. If
the client's Test Activation Request exceeds the server's configured the client's Test Activation Request exceeds the server's configured
maximum, the server MUST either reject the request or coerce the maximum, the server MUST either reject the request or coerce the
value to the configured maximum bit rate, and communicate that value to the configured maximum bit rate, and communicate that
maximum to the client in the Test Activation Response. The client maximum to the client in the Test Activation Response. The client
can of course choose to end the test, as appropriate. can of course choose to end the test, as appropriate.
Other parameters where the server has the OPTION to coerce the client Other parameters where the server has the OPTION to coerce the client
to use values other than those in the Test Activation Request are to use values other than those in the Test Activation Request are
(grouped by role): (grouped by role):
* Load rate adjustment algorithm: lowThresh, upperThresh, * Load rate adjustment algorithm: lowThresh, upperThresh,
useOwDelayVar, highSpeedDelta, slowAdjThresh, seqErrThresh, useOwDelayVar, highSpeedDelta, slowAdjThresh, seqErrThresh,
highSpeedDelta, ignoreOooDup, rateAdjAlgo highSpeedDelta, ignoreOooDup, and rateAdjAlgo
* Test duration/intervals: trialInt, testIntTime, subIntPeriod * Test duration/intervals: trialInt, testIntTime, and subIntPeriod
* Packet marking: dscpEcn * Packet marking: dscpEcn
Coercion is a step towards performing a test with the server- Coercion is a step towards performing a test with the server-
configured values; even though the client might prefer certain configured values; even though the client might prefer certain
values, the server gives the client an opportunity to run a test with values, the server gives the client an opportunity to run a test with
different values than the preferred set. In these cases, the Command different values than the preferred set. In these cases, the Command
Response value SHALL be CHTA_CRSP_ACKOK. Response value SHALL be CHTA_CRSP_ACKOK.
Note that the server also has the option of completely rejecting the Note that the server also has the option of completely rejecting the
request and sending back an appropriate cmdResponse field value request and sending back an appropriate cmdResponse field value
(currently only CHTA_CRSP_BADPARAM; see Section 11.3.9). (currently only CHTA_CRSP_BADPARAM; see Section 12.3.9).
Whether this error response is sent or not depends on the security Whether this error response is sent or not depends on the security
mode of operation and the outcome of authDigest validation. mode of operation and the outcome of authDigest validation.
If the Test Activation Request must be rejected (due to the Command If the Test Activation Request must be rejected (due to the Command
Response value being CHTA_CRSP_BADPARAM), and Response value being CHTA_CRSP_BADPARAM), and
* If the authDigest is valid, a Test Activation Response SHALL be * If the authDigest is valid, a Test Activation Response SHALL be
sent back to the client with a corresponding Command Response sent back to the client with a corresponding Command Response
value indicating the reason for the rejection. value indicating the reason for the rejection.
skipping to change at line 1661 skipping to change at line 1664
controlHdrTA' size shown in Figure 7, controlHdrTA' size shown in Figure 7,
* the PDU ID is not 0xACE2 (Test Activation PDU), or * the PDU ID is not 0xACE2 (Test Activation PDU), or
* a directed attack has been detected. * a directed attack has been detected.
In this case, the server will allow Test Activation Requests to In this case, the server will allow Test Activation Requests to
terminate silently. Attack detection is beyond the scope of this terminate silently. Attack detection is beyond the scope of this
specification. specification.
6.2.2. Server Accepts Request and Generates Response 7.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 12.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
setting srIndexConf to a value of 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
skipping to change at line 1704 skipping to change at line 1707
* the transmission parameters from the designated Configured Sending * the transmission parameters from the designated Configured Sending
Rate Table index (srIndexConf) of the Sending Rate Table where, if Rate Table index (srIndexConf) of the Sending Rate Table where, if
CHTA_SRIDX_ISSTART is set in modifierBitmap, this will be used as CHTA_SRIDX_ISSTART is set in modifierBitmap, this will be used as
the starting rate for the load rate adjustment algorithm; else, it the starting rate for the load rate adjustment algorithm; else, it
will be considered a fixed-rate test. will be considered a fixed-rate test.
The server SHALL then send the Test Activation Response back to the The server SHALL then send the Test Activation Response back to the
client, update the watchdog timer with a new timeout value, and set a client, update the watchdog timer with a new timeout value, and set a
test duration timer to eventually stop the test. test duration timer to eventually stop the test.
6.3. Client Processes Test Activation Response 7.3. Client Processes Test Activation Response
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 6.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 measurement system 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 12.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 12.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
server are not acceptable to the client, the client ends the test. server are not acceptable to the client, the client ends the test.
To finalize an accepted test activation, the client SHALL prepare its To finalize an accepted test activation, the client SHALL prepare its
connection for either an upstream test with dual timers set to send connection for either an upstream test with dual timers set to send
Load PDUs (based on the starting transmission parameters sent by the Load PDUs (based on the starting transmission parameters sent by the
server) OR a downstream test with a single timer to send Status PDUs server) OR a downstream test with a single timer to send Status PDUs
at the specified interval. at the specified interval.
Then, the client SHALL stop the test initiation timer and start a Then, the client SHALL stop the test initiation timer and start a
watchdog timer to detect if the server goes quiet. watchdog timer to detect if the server goes quiet.
The connection is now ready for testing. The connection is now ready for testing.
7. Test Load Stream Transmission and Measurement Status Feedback 8. Test Load Stream Transmission and Measurement Status Feedback
Messages Messages
This section describes the Data phase of the protocol. The roles of This section describes the Data phase of the protocol. The roles of
sender and receiver vary depending on whether the direction of sender and receiver vary depending on whether the direction of
testing is from server to client, or the reverse. testing is from server to client, or the reverse.
7.1. Load PDU and Roles 8.1. Load PDU and Roles
Testing proceeds with one endpoint sending Load PDUs, based on Testing proceeds with one endpoint sending Load PDUs, based on
transmission parameters from the Sending Rate Table, and the other transmission parameters from the Sending Rate Table, and the other
endpoint sending Status Feedback messages to communicate the traffic endpoint sending Status Feedback messages to communicate the traffic
conditions at the receiver. When the server is sending Status conditions at the receiver. When the server is sending Status
Feedback messages, they will also contain the latest transmission Feedback messages, they will also contain the latest transmission
parameters from the Sending Rate Table that the client SHALL use. parameters from the Sending Rate Table that the client SHALL use.
When a Load PDU is received, the receiver SHALL do the following: When a Load PDU is received, the receiver SHALL do the following:
1. Verify that the size of the message is greater than or equal to 1. Verify that the size of the message is greater than or equal to
the 'struct loadHdr' size shown in Figure 9. the 'struct loadHdr' size shown in Figure 9.
2. Validate the checksum for the Load PDU header portion of the 2. Validate the checksum for the Load PDU header portion of the
total message (as described in Section 4.6) if the optional total message (as described in Section 5.6) if the optional
checkSum field is being utilized. checkSum field is being utilized.
3. Confirm that the PDU ID is 0xBEEF (Load PDU). 3. Confirm that the PDU ID is 0xBEEF (Load PDU).
Note: If any of the above checks fail, the message SHALL be If any of the above checks fail, the message SHALL be considered
considered invalid. invalid.
The watchdog timer at the receiver SHALL be reset each time a valid The watchdog timer at the receiver SHALL be reset each time a valid
Load PDU is received (which includes verification of the checkSum, if Load PDU is received (which includes verification of the checkSum, if
in use). See non-graceful test stop in Section 8 for handling the in use). See non-graceful test stop in Section 9 for handling the
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,
skipping to change at line 1871 skipping to change at line 1874
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rttRespDelay | checkSum | | rttRespDelay | checkSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Payload Content... . . Payload Content... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Load PDU Layout Figure 8: Load PDU Layout
Specific details regarding Load PDU fields are as follows: Specific details regarding Load PDU fields are as follows:
pduId: IANA has assigned the hex value 0xBEEF (Section 11.3.1). pduId: IANA has assigned the hex value 0xBEEF (Section 12.3.1).
testAction: A one-octet field designating the current test action as testAction: A one-octet field designating the current test action as
either TEST_ACT_TEST (testing in progress), TEST_ACT_STOP1 (first either TEST_ACT_TEST (testing in progress), TEST_ACT_STOP1 (first
phase of graceful termination, used locally by server), or phase of graceful termination, used locally by server), or
TEST_ACT_STOP2 (second phase of graceful termination, sent by TEST_ACT_STOP2 (second phase of graceful termination, sent by
server and reciprocated by client). See Section 8 for additional server and reciprocated by client). See Section 9 for additional
information on test termination. information on test termination.
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).
skipping to change at line 1927 skipping to change at line 1930
number of ms from reception of the most recent Status PDU (when number of ms from reception of the most recent Status PDU (when
the latest spduTime_sec/spduTime_nsec was obtained) to the the latest spduTime_sec/spduTime_nsec was obtained) to 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 5.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.
Payload Content: All zeroes, all ones, or a pseudorandom binary Payload Content: All zeroes, all ones, or a pseudorandom binary
sequence. sequence.
The Load PDU SHALL be organized as follows (followed by any payload The Load PDU SHALL be organized as follows (followed by any payload
content): content):
<CODE BEGINS> <CODE BEGINS>
skipping to change at line 1963 skipping to change at line 1966
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 8.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
test at the configured feedback interval, after at least one Load PDU test at the configured feedback interval, after at least one Load PDU
has been received (when there is something to provide status on). In has been received (when there is something to provide status on). In
test scenarios with long delays between client and server, it is test scenarios with long delays between client and server, it is
possible for the Status PDU send timer to fire before the first Load possible for the Status PDU send timer to fire before the first Load
PDU arrives. In these cases, the Status PDU SHALL NOT be sent. PDU arrives. In these cases, the Status PDU SHALL NOT be sent.
When the Load PDU sender receives a Status PDU message, it SHALL When the Load PDU sender receives a Status PDU message, it SHALL
first follow the Message Verification Procedure listed in first follow the Message Verification Procedure listed in
Section 5.2, Paragraph 2. Section 6.2, Paragraph 2.
The watchdog timer at the Load PDU sender SHALL be reset each time a The watchdog timer at the Load PDU sender SHALL be reset each time a
valid Status PDU is received (which includes verification of the valid Status PDU is received (which includes verification of the
checkSum and/or authDigest, if in use). See non-graceful test stop checkSum and/or authDigest, if in use). See non-graceful test stop
in Section 8 for handling the watchdog timeout expiration at each in Section 9 for handling the watchdog timeout expiration at each
endpoint. endpoint.
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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rxDatagrams | | rxDatagrams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rxBytes | | rxBytes |
skipping to change at line 2071 skipping to change at line 2074
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authUnixTime | | authUnixTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. authDigest (32 octets) . . authDigest (32 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 7.
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 saved (sisSav) structure covers the While the Sub-Interval statistics saved (sisSav) structure covers the
most recently saved (completed) Sub-Interval, similar fields directly most recently saved (completed) Sub-Interval, similar fields directly
in the Status PDU itself cover the most recent trial interval (the in the Status PDU itself cover the most recent trial interval (the
time period between Status Feedback messages, completed by this time period between Status Feedback messages, completed by this
Status PDU). Both sets of statistics SHALL always be populated by Status PDU). Both sets of statistics SHALL always be populated by
the Load 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 12.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.
skipping to change at line 2166 skipping to change at line 2169
sufficiently synchronized, this will be the minimum one-way delay sufficiently synchronized, this will be the minimum one-way delay
in ms. Otherwise, this value may be negative but still valid for in ms. Otherwise, this value may be negative but still valid for
one-way delay variation measurements for the default test duration one-way delay variation measurements for the default test duration
(default is 10 seconds). If the test duration is extended to a (default is 10 seconds). If the test duration is extended to a
range of minutes, where significant clock drift can occur, range of minutes, where significant clock drift can occur,
synchronized (or at least well-disciplined) clocks may be synchronized (or at least well-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 test. minimum "adjusted" RTT measured since the beginning of the test.
See rttRespDelay (Section 7.1) regarding "adjusted" measurements. See rttRespDelay (Section 8.1) regarding "adjusted" measurements.
RTT is obtained by subtracting the copied spduTime_sec/ RTT is obtained by subtracting the copied spduTime_sec/
spduTime_nsec in the received Load PDU from the local time at spduTime_nsec in the received Load PDU from the local time at
which it was received. This minimum SHALL be kept current (and which it was received. This minimum SHALL be kept current (and
continuously updated) via each Load PDU received with an updated continuously updated) via each Load PDU received with an updated
spduTime_sec/spduTime_nsec. This value MUST be positive. Before spduTime_sec/spduTime_nsec. This value MUST be positive. Before
an initial value can be established, and because zero is itself an initial value can be established, and because zero is itself
valid, it SHALL be set to STATUS_NODEL when communicated in the valid, it SHALL be set 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 8.1) regarding "adjusted" measurements. RTT delay
variation is obtained by subtracting the current (and continuously variation is obtained by subtracting the current (and continuously
updated) "adjusted" RTT minimum, communicated as rttMinimum (in updated) "adjusted" RTT minimum, communicated as rttMinimum (in
Status PDU), from each "adjusted" RTT measurement (which is itself Status PDU), from each "adjusted" RTT measurement (which is itself
obtained by subtracting the copied spduTime_sec/spduTime_nsec in obtained by subtracting the copied spduTime_sec/spduTime_nsec in
the received Load PDU from the local time at which it was the received Load PDU from the local time at which it was
received). Note that while one-way delay variation is measured received). Note that while one-way delay variation is measured
for every Load PDU received, RTT delay variation is only sampled for every Load PDU received, RTT delay variation is only sampled
via the Status PDU sent and the very next Load PDU received with via the Status PDU sent and the very next Load PDU received with
the corresponding updated spduTime_sec/spduTime_nsec. When a new the corresponding updated spduTime_sec/spduTime_nsec. When a new
value is unavailable (possibly due to packet loss), and because value is unavailable (possibly due to packet loss), and because
skipping to change at line 2206 skipping to change at line 2209
tiDeltaTime/tiRxDatagrams/tiRxBytes: Three four-octet fields tiDeltaTime/tiRxDatagrams/tiRxBytes: Three four-octet fields
populated by the trial interval time in us, along with the populated by the trial interval time in us, along with the
received datagram and byte counts. Used to calculate the received received datagram and byte counts. Used to calculate 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 into local transmit time of the Status PDU. Expected to be copied into
spduTime_sec/spduTime_nsec in subsequent Load PDUs after being spduTime_sec/spduTime_nsec in subsequent Load PDUs after being
received by the Load PDU sender. Used for RTT measurements. received by the Load PDU sender. Used for RTT measurements.
authMode: Same as in Section 5.1. authMode: Same as in Section 6.1.
authUnixTime: Same as in Section 5.1. authUnixTime: Same as in Section 6.1.
authDigest: Same as in Section 5.1. authDigest: Same as in Section 6.1.
keyId: Same as in Section 5.1. keyId: Same as in Section 6.1.
reservedAuth1: Same as in Section 5.1. reservedAuth1: Same as in Section 6.1.
checkSum: Same as in Section 5.1. checkSum: Same as in Section 6.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) #pragma pack(push, 1)
struct subIntStats { struct subIntStats {
skipping to change at line 2287 skipping to change at line 2290
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>
Figure 11: Status PDU Figure 11: Status PDU
8. Stopping a Test 9. Stopping a Test
When the test duration timer (testIntTime) on the server expires, it When the test duration timer (testIntTime) on the server expires, it
SHALL set the local connection test action to TEST_ACT_STOP1 (phase 1 SHALL set the local connection test action to TEST_ACT_STOP1 (phase 1
of graceful termination). This is simply a non-reversible state of graceful termination). This is simply a non-reversible state
awaiting the next message(s) to be sent from the server. During this awaiting the next message(s) to be sent from the server. During this
time, any received Load or Status PDUs are processed normally. time, any received Load or Status PDUs are processed normally.
Upon transmission of the next Load or Status PDUs, the server SHALL Upon transmission of the next Load or Status PDUs, the server SHALL
set the local connection test action to TEST_ACT_STOP2 (phase 2 of set the local connection test action to TEST_ACT_STOP2 (phase 2 of
graceful termination) and mark any outgoing PDUs with a testAction graceful termination) and mark any outgoing PDUs with a testAction
skipping to change at line 2331 skipping to change at line 2334
timeouts at each endpoint will expire (sometimes at one endpoint timeouts at each endpoint will expire (sometimes at one endpoint
first); notifications in logs, STDOUT, and/or formatted output SHALL first); notifications in logs, STDOUT, and/or formatted output SHALL
be made; and the endpoint SHALL schedule an immediate end time for be made; and the endpoint SHALL schedule an immediate end time for
the connection. the connection.
If an attacker clears the TEST_ACT_STOP2 indication, then the If an attacker clears the TEST_ACT_STOP2 indication, then the
configured test duration timer (testIntTime) at the server and client configured test duration timer (testIntTime) at the server and client
SHALL take precedence and the endpoint SHALL schedule an immediate SHALL take precedence and the endpoint SHALL schedule an immediate
end time for the connection. end time for the connection.
9. Operational Considerations for the Measurement Method 10. Operational Considerations for the Measurement Method
The architecture of the method requires two cooperating hosts The architecture of the method requires two cooperating hosts
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.
skipping to change at line 2364 skipping to change at line 2367
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
infrequent, diagnostic, short-term measurement. It is RECOMMENDED to infrequent, diagnostic, short-term measurement. It is RECOMMENDED to
discontinue non-measurement traffic that shares a subscriber's discontinue non-measurement traffic that shares a subscriber's
dedicated resources while testing: measurements may not be accurate, dedicated resources while testing: measurements may not be accurate,
and throughput of competing elastic traffic may be greatly reduced. and throughput of competing elastic traffic may be greatly reduced.
See Section 8 of [RFC9097] for a discussion of the Method of See Section 8 of [RFC9097] for a discussion of the Method of
Measurement beyond purely operational aspects. Measurement beyond purely operational aspects.
9.1. Notes on Interface Measurements 10.1. Notes on Interface Measurements
Additional measurements may be useful in specific circumstances. For Additional measurements may be useful in specific circumstances. For
example, interface byte counters measured by a client at a example, interface byte counters measured by a client at a
residential gateway are possible when the client application has residential gateway are possible when the client application has
access to an interface that sees all traffic to/from a service access to an interface that sees all traffic to/from a service
subscriber's location. Adding a byte counter at the client for subscriber's location. Adding a byte counter at the client for
download or upload directions could be used to measure total traffic download or upload directions could be used to measure total traffic
and possibly detect when non-test traffic is present (and using and possibly detect when non-test traffic is present (and using
capacity). The client may not have the CPU cycles available to count capacity). The client may not have the CPU cycles available to count
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 11. 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 users activating measurements as a When considering privacy of users activating measurements as a
service or users whose traffic is measured, the sensitive information service or users whose traffic is measured, the sensitive information
available to potential observers is greatly reduced when using active available to potential observers is greatly reduced when using active
techniques that are within this scope of work. Passive observations techniques that are within this scope of work. Passive observations
skipping to change at line 2415 skipping to change at line 2418
between cooperating hosts that allows firewalls to control between cooperating hosts that allows firewalls to control
inbound unsolicited UDP traffic that goes to either a control inbound unsolicited UDP traffic that goes to either a control
port or ephemeral ports that are only created as needed. port or ephemeral ports that are only created as needed.
Firewalls protecting each host can continue to do their jobs Firewalls protecting each host can continue to do their jobs
normally. normally.
3. Client-server authentication and integrity protection for 3. Client-server authentication and integrity protection for
feedback messages conveying measurements is RECOMMENDED. To feedback messages conveying measurements is RECOMMENDED. To
accommodate different host limitations and testing circumstances, accommodate different host limitations and testing circumstances,
different modes of operation are available, as described in different modes of operation are available, as described in
Section 4. Section 5.
4. Hosts MUST limit the number of simultaneous tests to avoid 4. Hosts MUST limit the number of simultaneous tests to avoid
resource exhaustion and inaccurate results. resource exhaustion and inaccurate results.
5. Senders MUST be rate-limited. This can be accomplished using a 5. Senders MUST be rate-limited. This can be accomplished using a
pre-built table defining all the offered sending rates that will pre-built table defining all the offered sending rates that will
be supported. The default and optional load rate adjustment be supported. The default and optional load rate adjustment
algorithm results in "ramp up" from the lowest rate in the table. algorithm results in "ramp up" from the lowest rate in the table.
Optionally, the server could utilize the maxBandwidth field (and Optionally, the server could utilize the maxBandwidth field (and
the CHSR_USDIR_BIT bit) in the Setup Request from the client to the CHSR_USDIR_BIT bit) in the Setup Request from the client to
skipping to change at line 2447 skipping to change at line 2450
indication. Setting the indication in successive packets terminates indication. Setting the indication in successive packets terminates
the test prematurely, with no threat to the Internet but annoyance the test prematurely, with no threat to the Internet but annoyance
for the testers. If an attacker clears the STOP indication, the for the testers. If an attacker clears the STOP indication, the
mitigation relies on knowledge of the test duration at the client and mitigation relies on knowledge of the test duration at the client and
server, where these hosts cease all traffic when the specified test server, where these hosts cease all traffic when the specified test
duration is complete. duration is complete.
Authentication methods and requirements steadily evolve. Alternate Authentication methods and requirements steadily evolve. Alternate
authentication modes provide for algorithm agility by defining a new authentication modes provide for algorithm agility by defining a new
mode, whose support is indicated by assigning a suitable "Test Setup mode, whose support is indicated by assigning a suitable "Test Setup
PDU Authentication Mode" registry value (see Section 11.3.4 ). PDU Authentication Mode" registry value (see Section 12.3.4 ).
11. IANA Considerations 12. IANA Considerations
Per this document, IANA has assigned a UDP port for the Test Setup Per this document, IANA has assigned a UDP port number for the Test
exchange in the Control phase of protocol operation and has created a Setup exchange in the Control phase of protocol operation and has
new registry group for the UDPSTP. created a new registry group for the UDPSTP.
11.1. New User Port Number Assignment 12.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.
11.2. New KeyTable KDF 12.2. New KeyTable KDF
IANA has added the following KDF entry to the "KeyTable KDFs" IANA has added the following KDF entry to the "KeyTable KDFs"
registry (see <https://www.iana.org/assignments/keytable>): registry (see <https://www.iana.org/assignments/keytable>):
+==============+=============================+===========+ +==============+=============================+===========+
| KDF | Description | Reference | | KDF | Description | Reference |
+==============+=============================+===========+ +==============+=============================+===========+
| HMAC-SHA-256 | HMAC using the SHA-256 hash | [RFC6234] | | HMAC-SHA-256 | HMAC using the SHA-256 hash | [RFC6234] |
+--------------+-----------------------------+-----------+ +--------------+-----------------------------+-----------+
Table 1: KeyTable KDFs Registry Table 1: KeyTable KDFs Registry
11.3. New UDPSTP Registry Group 12.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 are expected to be used for experiments | used on the Internet but are expected to be used for experiments
| that are confined to closed environments. | that are confined to closed environments.
11.3.1. PDU Identifier Registry 12.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 |
+===============+=========================+ +===============+=========================+
skipping to change at line 2552 skipping to change at line 2555
+---------------+-------------------------------+-----------+ +---------------+-------------------------------+-----------+
| 0xDEAD | Null PDU | RFC 9946 | | 0xDEAD | Null PDU | RFC 9946 |
+---------------+-------------------------------+-----------+ +---------------+-------------------------------+-----------+
| 0xFEED | Status Feedback PDU | RFC 9946 | | 0xFEED | Status Feedback PDU | RFC 9946 |
+---------------+-------------------------------+-----------+ +---------------+-------------------------------+-----------+
| 0xFFFF | Reserved | RFC 9946 | | 0xFFFF | Reserved | RFC 9946 |
+---------------+-------------------------------+-----------+ +---------------+-------------------------------+-----------+
Table 3: Initial Values of the PDU Identifier Registry Table 3: Initial Values of the PDU Identifier Registry
11.3.2. Protocol Version Registry 12.3.2. Protocol Version Registry
IANA has created the "Protocol Version" registry under the "UDP Speed IANA has created the "Protocol Version" registry under the "UDP Speed
Test Protocol (UDPSTP)" registry group. UDPSTP Test Setup Request, Test Protocol (UDPSTP)" registry group. UDPSTP Test Setup Request,
Test Setup Response, and Test Activation Request PDUs contain a two- Test Setup Response, and Test Activation Request PDUs contain a two-
octet protocolVer field, identifying the version of the protocol in octet protocolVer field, identifying the version of the protocol in
use. The code points in this registry are allocated according to the use. The code points in this registry are allocated according to the
registration procedures [RFC8126] described in Table 4. registration procedures [RFC8126] described in Table 4.
+================+=========================+ +================+=========================+
| Range(Decimal) | Registration Procedures | | Range(Decimal) | Registration Procedures |
skipping to change at line 2591 skipping to change at line 2594
+=======+===========+ +=======+===========+
| Value | Reference | | Value | Reference |
+=======+===========+ +=======+===========+
| 20 | RFC 9946 | | 20 | RFC 9946 |
+-------+-----------+ +-------+-----------+
Table 5: Initial Value Table 5: Initial Value
of the Protocol of the Protocol
Version Registry Version Registry
11.3.3. Test Setup PDU Modifier Bitmap Registry 12.3.3. Test Setup PDU Modifier Bitmap Registry
IANA has created the "Test Setup PDU Modifier Bitmap" registry under IANA has created the "Test Setup PDU Modifier Bitmap" registry under
the "UDP Speed Test Protocol (UDPSTP)" registry group. The Test the "UDP Speed Test Protocol (UDPSTP)" registry group. The Test
Setup PDU layout contains a modifierBitmap field. The bitmaps in Setup PDU layout contains a modifierBitmap field. The bitmaps in
this registry are allocated according to the registration procedures this registry are allocated according to the registration procedures
[RFC8126] described in Table 6. [RFC8126] described in Table 6.
+===================+=========================+ +===================+=========================+
| Range(Bitmap) | Registration Procedures | | Range(Bitmap) | Registration Procedures |
+===================+=========================+ +===================+=========================+
skipping to change at line 2628 skipping to change at line 2631
| 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 an 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 12.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
this registry are allocated according to the registration procedures this registry are allocated according to the registration procedures
[RFC8126] described in Table 8. [RFC8126] described in Table 8.
+================+=========================+ +================+=========================+
| Range(Decimal) | Registration Procedures | | Range(Decimal) | Registration Procedures |
+================+=========================+ +================+=========================+
skipping to change at line 2668 skipping to change at line 2671
| 1 | Required authentication for the Control | RFC 9946 | | 1 | Required authentication for the Control | RFC 9946 |
| | phase | | | | phase | |
+-------+-----------------------------------------------+-----------+ +-------+-----------------------------------------------+-----------+
| 2 | Optional authentication for the Data | RFC 9946 | | 2 | Optional authentication for the Data | RFC 9946 |
| | phase, in addition to the Control phase | | | | phase, in addition to the Control phase | |
+-------+-----------------------------------------------+-----------+ +-------+-----------------------------------------------+-----------+
Table 9: Initial Values of the Test Setup PDU Authentication Mode Table 9: Initial Values of the Test Setup PDU Authentication Mode
Registry Registry
11.3.5. Test Setup PDU Command Response Field Registry 12.3.5. Test Setup PDU Command Response Field Registry
IANA has created the "Test Setup PDU Command Response Field" registry IANA has created the "Test Setup PDU Command Response Field" 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 a cmdResponse field. The code points Test Setup PDU layout contains a cmdResponse field. The code points
in this registry are allocated according to the registration in this registry are allocated according to the registration
procedures [RFC8126] described in Table 10. procedures [RFC8126] described in Table 10.
+================+=========================+ +================+=========================+
| Range(Decimal) | Registration Procedures | | Range(Decimal) | Registration Procedures |
+================+=========================+ +================+=========================+
skipping to change at line 2745 skipping to change at line 2748
+---------+--------------------------------------------+-----------+ +---------+--------------------------------------------+-----------+
Table 11: Initial Values of the Test Setup PDU Command Response Table 11: Initial Values of the Test Setup PDU Command Response
Field Registry Field Registry
Note that value 4 is required for backward compatibility with Note that value 4 is required for backward compatibility with
previous experimental versions of software already in use. Further, previous experimental versions of software already in use. Further,
value 6 signals that a client erroneously used an authMode that value 6 signals that a client erroneously used an authMode that
hasn't been standardized yet (i.e., authMode is greater than 1 or 2). hasn't been standardized yet (i.e., authMode is greater than 1 or 2).
11.3.6. Test Activation PDU Command Request Registry 12.3.6. Test Activation PDU Command Request Registry
IANA has created the "Test Activation PDU Command Request" registry IANA has created the "Test Activation PDU Command Request" 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 a cmdRequest field. The code points Test Setup PDU layout contains a cmdRequest field. The code points
in this registry are allocated according to the registration in this registry are allocated according to the registration
procedures [RFC8126] described in Table 12. procedures [RFC8126] described in Table 12.
+================+=========================+ +================+=========================+
| Range(Decimal) | Registration Procedures | | Range(Decimal) | Registration Procedures |
+================+=========================+ +================+=========================+
skipping to change at line 2796 skipping to change at line 2799
| | Use | | | | Use | |
+---------+------------------------------+-----------+ +---------+------------------------------+-----------+
| 250-254 | Reserved for Private Use | RFC 9946 | | 250-254 | Reserved for Private Use | RFC 9946 |
+---------+------------------------------+-----------+ +---------+------------------------------+-----------+
| 255 | Reserved | RFC 9946 | | 255 | Reserved | RFC 9946 |
+---------+------------------------------+-----------+ +---------+------------------------------+-----------+
Table 13: Initial Values of the Test Activation Table 13: Initial Values of the Test Activation
PDU Command Request Registry PDU Command Request Registry
11.3.7. Test Activation PDU Modifier Bitmap Registry 12.3.7. Test Activation PDU Modifier Bitmap Registry
IANA has created the "Test Activation PDU Modifier Bitmap" registry IANA has created the "Test Activation PDU Modifier Bitmap" registry
under the "UDP Speed Test Protocol (UDPSTP)" registry group. The under the "UDP Speed Test Protocol (UDPSTP)" registry group. The
Test Activation PDU layout (also) contains a modifierBitmap field. Test Activation PDU layout (also) contains a modifierBitmap field.
The bitmaps in this registry are allocated according to the The bitmaps in this registry are allocated according to the
registration procedures [RFC8126] described in Table 14. registration procedures [RFC8126] described in Table 14.
+===================+=========================+ +===================+=========================+
| Range(Bitmap) | Registration Procedures | | Range(Bitmap) | Registration Procedures |
+===================+=========================+ +===================+=========================+
skipping to change at line 2834 skipping to change at line 2837
| 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 12.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 |
+=================================+=========================+ +=================================+=========================+
skipping to change at line 2870 skipping to change at line 2873
| 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 12.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.
+================+=========================+ +================+=========================+
| Range(Decimal) | Registration Procedures | | Range(Decimal) | Registration Procedures |
+================+=========================+ +================+=========================+
skipping to change at line 2918 skipping to change at line 2921
| 240-249 | Reserved for Experimental Use | RFC 9946 | | 240-249 | Reserved for Experimental Use | RFC 9946 |
+---------+----------------------------------+-----------+ +---------+----------------------------------+-----------+
| 250-254 | Reserved for Private Use | RFC 9946 | | 250-254 | Reserved for Private Use | RFC 9946 |
+---------+----------------------------------+-----------+ +---------+----------------------------------+-----------+
| 255 | Reserved | RFC 9946 | | 255 | Reserved | RFC 9946 |
+---------+----------------------------------+-----------+ +---------+----------------------------------+-----------+
Table 19: Initial Values of the Test Activation PDU Table 19: Initial Values of the Test Activation PDU
Command Response Field Registry Command Response Field Registry
11.4. Guidelines for Designated Experts 12.4. Guidelines for Designated Experts
It is suggested that multiple designated experts be appointed for It is suggested that multiple designated experts be appointed for
registry change requests. registry change requests.
Criteria that should be applied by the designated experts include Criteria that should be applied by the designated experts include
determining whether the proposed registration duplicates existing determining whether the proposed registration duplicates existing
entries and whether the registration description is clear and fits entries and whether the registration description is clear and fits
the purpose of this registry. the purpose of this registry.
Registration requests are evaluated within a two-week review period Registration requests are evaluated within a two-week review period
on the advice of one or more designated experts. Within the review on the advice of one or more designated experts. Within the review
period, the designated experts will either approve or deny the period, the designated experts will either approve or deny the
registration request, communicating this decision to IANA. Denials registration request, communicating this decision to IANA. Denials
should include an explanation and, if applicable, suggestions as to should include an explanation and, if applicable, suggestions as to
how to make the request successful. how to make the request successful.
12. References 13. References
12.1. Normative References 13.1. Normative References
[C-Prog] ISO/IEC, "Programming languages -- C", ISO/IEC 9899:1999, [C-Prog] ISO/IEC, "Programming languages -- C", ISO/IEC 9899:1999,
1999, <https://www.iso.org/standard/29237.html>. 1999, <https://www.iso.org/standard/29237.html>.
[NIST800-108] [NIST800-108]
Chen, L., "Recommendation for Key Derivation Using Chen, L., "Recommendation for Key Derivation Using
Pseudorandom Functions", Pseudorandom Functions",
DOI 10.6028/NIST.SP.800-108r1-upd1, NIST DOI 10.6028/NIST.SP.800-108r1-upd1, NIST
SP 800-108r1-upd1, August 2022, SP 800-108r1-upd1, August 2022,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
skipping to change at line 3020 skipping to change at line 3023
[Y.1540Amd2] [Y.1540Amd2]
ITU-T, "Internet protocol data communication service - IP ITU-T, "Internet protocol data communication service - IP
packet transfer and availability performance parameters, packet transfer and availability performance parameters,
Amendment 2 - Revised Annex B: Additional search Amendment 2 - Revised Annex B: Additional search
algorithms for IP-based capacity parameters and methods of algorithms for IP-based capacity parameters and methods of
measurement", ITU-T Recommendation Y.1540 Amd. 2, March measurement", ITU-T Recommendation Y.1540 Amd. 2, March
2023, 2023,
<https://www.itu.int/rec/T-REC-Y.1540-202303-I!Amd2/en>. <https://www.itu.int/rec/T-REC-Y.1540-202303-I!Amd2/en>.
12.2. Informative References 13.2. Informative References
[EVP_KDF-KB] [EVP_KDF-KB]
"EVP_KDF-KB - The Key-Based EVP_KDF implementation", "EVP_KDF-KB - The Key-Based EVP_KDF implementation",
OpenSSL Documentation, OpenSSL Documentation,
<https://docs.openssl.org/master/man7/EVP_KDF-KB/>. <https://docs.openssl.org/master/man7/EVP_KDF-KB/>.
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining
Empirical Bulk Transfer Capacity Metrics", RFC 3148, Empirical Bulk Transfer Capacity Metrics", RFC 3148,
DOI 10.17487/RFC3148, July 2001, DOI 10.17487/RFC3148, July 2001,
<https://www.rfc-editor.org/info/rfc3148>. <https://www.rfc-editor.org/info/rfc3148>.
 End of changes. 146 change blocks. 
247 lines changed or deleted 250 lines changed or added

This html diff was produced by rfcdiff 1.48.