rfc9946.original   rfc9946.txt 
Network Working Group L. Ciavattone Internet Engineering Task Force (IETF) A. Morton
Internet-Draft AT&T Labs Request for Comments: 9946
Intended status: Standards Track R. Geib Category: Standards Track L. Ciavattone
Expires: 20 March 2026 Deutsche Telekom ISSN: 2070-1721 AT&T Labs
16 September 2025 R. Geib, Ed.
Deutsche Telekom
March 2026
UDP Speed Test Protocol for One-way IP Capacity Metric Measurement The UDP Speed Test Protocol for One-Way IP Capacity Metric Measurement
draft-ietf-ippm-capacity-protocol-25
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 there requires a feedback channel from the Measurement discussed in that RFC requires a feedback channel from
receiver to control the sender's transmission rate in near-real-time. the receiver to control the sender's transmission rate in near real-
This document defines the UDP Speed Test Protocol for conducting RFC time. This document defines the UDP Speed Test Protocol (UDPSTP) for
9097 and other related measurements. conducting RFC 9097 and other related measurements.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 20 March 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9946.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language
2. Scope, Goals, and Applicability . . . . . . . . . . . . . . . 4 2. Scope, Goals, and Applicability
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview
3.1. Fixed-Rate Testing . . . . . . . . . . . . . . . . . . . 10 3.1. Fixed-Rate Testing
3.2. Handling of and Safeguards required by Self-Induced 3.2. Handling of and Safeguards Required by Self-Induced
Congestion . . . . . . . . . . . . . . . . . . . . . . . 10 Congestion
4. Requirements, Security Operations, and Optional Checksum . . 11 4. Requirements, Security Operations, and Optional Checksum
4.1. Load Rate Adjustment Algorithm Requirements . . . . . . . 11 4.1. Load Rate Adjustment Algorithm Requirements
4.2. Parameters and Definitions . . . . . . . . . . . . . . . 13 4.2. Parameters and Definitions
4.3. Security Mode Operations . . . . . . . . . . . . . . . . 13 4.3. Security Mode Operations
4.3.1. Mode 1: Required Authenticated Mode . . . . . . . . . 14 4.3.1. Mode 1: Required Authenticated Mode
4.3.2. Mode 2: Optional Authenticated Mode for Data Phase . 15 4.3.2. Mode 2: Optional Authenticated Mode for Data Phase
4.4. Key Management . . . . . . . . . . . . . . . . . . . . . 16 4.4. Key Management
4.4.1. Key Derivation Function (KDF) . . . . . . . . . . . . 16 4.4.1. Key Derivation Function (KDF)
4.5. Configuration of Network Functions with Stateful 4.5. Configuration of Network Functions with Stateful Filtering
Filtering . . . . . . . . . . . . . . . . . . . . . . . . 18 4.6. Optional Checksum
4.6. Optional Checksum . . . . . . . . . . . . . . . . . . . . 19 5. Test Setup Request and Response
5. Test Setup Request and Response . . . . . . . . . . . . . . . 20 5.1. Client Generates Test Setup Request
5.1. Client Generates Test Setup Request . . . . . . . . . . . 20
5.2. Server Test Setup Request Processing and Response 5.2. Server Test Setup Request Processing and Response
Generation . . . . . . . . . . . . . . . . . . . . . . . 23 Generation
5.2.1. Test Setup Request Processing - Rejection . . . . . . 24 5.2.1. Test Setup Request Processing -- Rejection
5.2.2. Test Setup Request Processing - Acceptance . . . . . 27 5.2.2. Test Setup Request Processing -- Acceptance
5.3. Setup Response Processing at the Client . . . . . . . . . 29 5.3. Setup Response Processing at the Client
6. Test Activation Request and Response . . . . . . . . . . . . 30 6. Test Activation Request and Response
6.1. Client Generates Test Activation Request . . . . . . . . 30 6.1. Client Generates Test Activation Request
6.2. Server Processes Test Activation Request and Generates 6.2. Server Processes Test Activation Request and Generates
Response . . . . . . . . . . . . . . . . . . . . . . . . 36 Response
6.2.1. Server Rejects or Modifies Request . . . . . . . . . 36 6.2.1. Server Rejects or Modifies Request
6.2.2. Server Accepts Request and Generates Response . . . . 37 6.2.2. Server Accepts Request and Generates Response
6.3. Client Processes Test Activation Response . . . . . . . . 38 6.3. Client Processes Test Activation Response
7. Test Load Stream Transmission and Measurement Status Feedback 7. Test Load Stream Transmission and Measurement Status Feedback
Messages . . . . . . . . . . . . . . . . . . . . . . . . 39 Messages
7.1. Load PDU and Roles . . . . . . . . . . . . . . . . . . . 39 7.1. Load PDU and Roles
7.2. Status PDU . . . . . . . . . . . . . . . . . . . . . . . 44 7.2. Status PDU
8. Stopping a Test
8. Stopping a Test . . . . . . . . . . . . . . . . . . . . . . . 51 9. Operational Considerations for the Measurement Method
9. Operational considerations for the Measurement Method . . . . 52 9.1. Notes on Interface Measurements
9.1. Notes on Interface Measurements . . . . . . . . . . . . . 53 10. Security Considerations
10. Security Considerations . . . . . . . . . . . . . . . . . . . 53 11. IANA Considerations
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 11.1. New User Port Number Assignment
11.1. New User Port Number Assignment . . . . . . . . . . . . 55 11.2. New KeyTable KDF
11.2. New KeyTable KDF . . . . . . . . . . . . . . . . . . . . 55 11.3. New UDPSTP Registry Group
11.3. New UDPSTP Registry Group . . . . . . . . . . . . . . . 55 11.3.1. PDU Identifier Registry
11.3.1. PDU Identifier Registry . . . . . . . . . . . . . . 56 11.3.2. Protocol Version Registry
11.3.2. Protocol Version Registry . . . . . . . . . . . . . 57 11.3.3. Test Setup PDU Modifier Bitmap Registry
11.3.3. Test Setup PDU Modifier Bitmap Registry . . . . . . 57 11.3.4. Test Setup PDU Authentication Mode Registry
11.3.4. Test Setup PDU Authentication Mode Registry . . . . 58 11.3.5. Test Setup PDU Command Response Field Registry
11.3.5. Test Setup PDU Command Response Field Registry . . . 59 11.3.6. Test Activation PDU Command Request Registry
11.3.6. Test Activation PDU Command Request Registry . . . . 61 11.3.7. Test Activation PDU Modifier Bitmap Registry
11.3.7. Test Activation PDU Modifier Bitmap Registry . . . . 61 11.3.8. Test Activation PDU Rate Adjustment Algo. Registry
11.3.8. Test Activation PDU Rate Adjustment Algo. 11.3.9. Test Activation PDU Command Response Field Registry
Registry . . . . . . . . . . . . . . . . . . . . . . 62 11.4. Guidelines for Designated Experts
11.3.9. Test Activation PDU Command Response Field 12. References
Registry . . . . . . . . . . . . . . . . . . . . . . 63 12.1. Normative References
11.4. Guidelines for the Designated Experts . . . . . . . . . 64 12.2. Informative References
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 64 Appendix A. KDF Example (OpenSSL)
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 Acknowledgments
13.1. Normative References . . . . . . . . . . . . . . . . . . 64 Authors' Addresses
13.2. Informative References . . . . . . . . . . . . . . . . . 66
Appendix A. KDF Example (OpenSSL) . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69
1. Introduction 1. Introduction
The performance community has seen development of Informative Bulk The performance community has seen the development of Informative
Transport Capacity definitions in the "Framework for Bulk Transport Bulk Transport Capacity (BTC) definitions in "A Framework for
Capacity" (BTC, see [RFC3148]) and for "Network Capacity and Maximum Defining Empirical Bulk Transfer Capacity Metrics" [RFC3148] and
IP-layer Capacity" [RFC5136]. "Model-Based Metrics for BTC" add "Defining Network Capacity" [RFC5136] as well as experimental metric
experimental metric definitions and methods in [RFC8337]. definitions and methods in "Model-Based Metrics for Bulk Transport
Capacity" [RFC8337].
This document specifies the UDP Speed Test Protocol (UDPSTP) enabling This document specifies the UDP Speed Test Protocol (UDPSTP) to
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 there 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.
This protocol supports measurement features which weren't available UDPSTP supports measurement features that weren't available via TCP-
by TCP based speed tests and standard measurement protocols like One based speed tests and standard measurement protocols, such as the
Way Active Measurement Protocol (OWAMP) [RFC4656], Two-Way Active One-Way Active Measurement Protocol (OWAMP) [RFC4656], Two-Way Active
Measurement Protocol (TWAMP) [RFC5357] and Simple Two-Way Active Measurement Protocol (TWAMP) [RFC5357], and Simple Two-Way Active
Measurement Protocol (STAMP) [RFC8762] prior to this work. The Measurement Protocol (STAMP) [RFC8762], prior to this work. The
controlled Bulk Capacity measurement or Speed Test, respectively, is controlled Bulk Capacity measurement or Speed Test, respectively, is
based on UDP rather than TCP. The bulk measurement load is based on UDP rather than TCP. The bulk measurement load is
unidirectional. These specifications did support creation of unidirectional. These specifications did support the creation of
asymmetric traffic in combination with some two-way communication, as asymmetric traffic in combination with some two-way communication, as
supported by TWAMP and STAMP, when work on UDPSTP started. Further, supported by TWAMP and STAMP, when work on UDPSTP started. Further,
two-way communications of TWAMP and STAMP are limited to reflection two-way communications of TWAMP and STAMP are limited to reflection
or unidirectional load properties, but lack support for closed loop or unidirectional load properties, but they lack support for closed
feedback operation. The latter enables limiting congestion of a loop feedback operation. The latter enables limiting congestion of a
bottleneck, whose capacity is measured, to a short time range. bottleneck, whose capacity is measured, to a short time range.
Support of such a control loop is the main purpose of UDPSTP. Support of such a control loop is the main purpose of UDPSTP.
Apart from measurement functionality, a Key Derivation Function has Apart from measurement functionality, a Key Derivation Function (KDF)
been added providing cryptographic separation of key material for has been added to provide cryptographic separation of key material
authentication of protocol messages in a standardized and for authentication of protocol messages in a standardized and
cryptographically secure manner. This is a secondary improvement cryptographically secure manner. This is a secondary improvement
reached by UDPSTP and may simplify its reuse for other measurement reached by UDPSTP and may simplify its reuse for other measurement
purposes. Additionally, because the protocol uses synthetic payload purposes. Additionally, because the protocol uses synthetic payload
data and contains no direct user information, a decision was made to data and contains no direct user information, a decision was made to
forgo encryption support. Secondarily, this is also expected to forgo encryption support. Secondarily, this is also expected to
increase the number of low-end devices that can support the test increase the number of low-end devices that can support the test
methodology. methodology.
1.1. Terminology 1.1. Terminology
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 as measurement between a server acting as sender and a client acting
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 as measurement between a client acting as sender and a server acting
receiver. as receiver.
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119], [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Scope, Goals, and Applicability 2. 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
algorithm. Per [RFC9097], that algorithm must not be used as a algorithm. Per [RFC9097], that algorithm must not be used as a
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 ([RFC9097]) and other Standards Development specifications of IETF (see [RFC9097]) and other Standards
Organizations (SDO's; 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 the protocol described here is the same as
in Section 2 of [RFC7497] where: in Section 2 of [RFC7497] where:
* The access portion of the network is the focus of this problem | The access portion of the network is the focus of this problem
statement. The user typically subscribes to a service with | statement. The user typically subscribes to a service with
bidirectional access partly described by rates in bits per second. | bidirectional access partly described by rates in bits per second.
UDPSTP is a client-based protocol. It may be applied by consumers to UDPSTP is a client-based protocol. It may be applied by consumers to
measure their own access bandwidth. Consumers may prefer an measure their own access bandwidth. Consumers may prefer an
independent 3rd party domain hosting the measurement server for this independent third-party domain hosting the measurement server for
purpose. UDPSTP may be deployed in Large-Scale Measurement of this purpose. UDPSTP may be deployed in a Large-scale Measurement of
Broadband Performance environments (LMAP, see [RFC7497]), another Broadband Performance (LMAP) environment (see [RFC7497]), another
independent 3rd party domain measurement server deployment. A independent third-party domain measurement server deployment. A
network operator may support operation and maintenance by UDPSTP, a network operator may support operation and maintenance by UDPSTP, a
typical intra-domain deployment. All these deployments require or typical intra-domain deployment. All these deployments require or
benefit from trust into the results, which are ensured by benefit from trust into the results, which are ensured by
authenticated communication. authenticated communication.
3. Protocol Overview 3. Protocol Overview
All messages defined by this document SHALL use UDP transport. All messages defined by this document SHALL use UDP transport.
The remainder of this section gives an informative overview of the The remainder of this section gives an informative overview of the
skipping to change at page 6, line 19 skipping to change at line 245
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 shall be the responsibility of the client process to
manage the inter-related connections: handling the individual manage the inter-related connections such as handling the individual
connection setup successes and failures, cleaning up connections connection setup successes and failures, cleaning up connections
during a test (should some fail) as well as aggregate the individual during a test (should some fail), and aggregating the individual test
test results into an overall set of performance statistics. Fields results into an overall set of performance statistics. Fields in the
in the Setup Request (mcIndex, mcCount, and mcIdent, see Section 6.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 [RFC0768] with two connection phases
(Control and Data). The exchanges 1 and 2 (see below) constitute the (Control and Data). As shown below, exchanges 1 and 2 constitute the
Control phase, while exchanges 3 and 4 constitute the Data phase. In Control phase, while exchanges 3 and 4 constitute the Data phase. In
this document, the term message and the term Protocol Data Unit, or this document, the term "message" and the term "Protocol Data Unit",
PDU ([RFC5044]) are used interchangeably. or "PDU" [RFC5044], are used interchangeably.
1. Test Setup Request and Response: If a server instance is 1. Test Setup Request and Response: If a server instance is
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, whether it's IPv4 or the name resolution response, regardless of whether it's 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-
connection setup, distinct UDP port numbers may be assigned with connection setup, distinct UDP port numbers may be assigned with
each Setup Response from a server instance. Distinct UDP port each Setup Response from a server instance. Distinct UDP port
numbers will be assigned if all Setup Response messages originate numbers will be assigned if all Setup Response messages originate
from the same server in that case. from the same server in that case.
2. Test Activation Request and Response: After having received a 2. Test Activation Request and Response: After having received a
confirmation of the configuration by a server, the client confirmation of the configuration by a server, the client
composes a request conveying parameters such as the testing composes a request conveying parameters such as the testing
direction, the duration of the test interval and test sub- direction, the duration of the test interval and test sub-
intervals, and various thresholds (for a detailed discussion, see intervals, and various thresholds (for a detailed discussion, see
[RFC9097] and [TR-471]). The server then chooses to accept, [RFC9097] and [TR-471]). The server then chooses to accept,
ignore or modify any of the test parameters, and communicates the ignore, or modify any of the test parameters and communicates the
set that will be used unless the client rejects the set that will be used unless the client rejects the
modifications. Note that the client assumes that the Test modifications. Note that the client assumes that the Test
Activation exchange has opened any co-located firewalls and Activation exchange has opened any co-located firewalls and
network address/port translators for the test connection (in network address/port translators for the test connection (in
response to the Request packet on the ephemeral port number) and response to the Request packet on the ephemeral port number) and
the traffic that follows. See [RFC9097] for a more detailed the traffic that follows. See [RFC9097] for a more detailed
discussion of firewall and NAT related features. If the Test discussion of firewall and NAT-related features. If the Test
Activation Request is rejected or fails, the client assumes that Activation Request is rejected or fails, the client assumes that
the firewall will close the address/port number pinhole entry the firewall will close the address/port number pinhole entry
after the firewall's configured idle traffic timeout. after the firewall's configured idle traffic timeout.
3. Test Stream Transmission and Measurement Feedback Messages: 3. Test Stream Transmission and Measurement Feedback Messages:
Testing proceeds with one endpoint sending Load PDUs and the Testing proceeds with one endpoint sending the Load PDUs and the
other endpoint receiving the Load PDUs and sending frequent other endpoint receiving the Load PDUs and sending frequent
status messages to communicate status and reception conditions status messages to communicate the status and reception
there. The data in the feedback messages, whether received from conditions. The data in the feedback messages, whether received
the client or when being sent to the client, is input to a load from the client or when being sent to the client, is input to a
rate adjustment algorithm at the server which controls future load rate adjustment algorithm at the server, which controls
sending rates at either end. The choice to locate the load rate future sending rates at either end. The choice to locate the
adjustment algorithm at the server, regardless of transmission load rate adjustment algorithm at the server, regardless of
direction, means that the algorithm can be updated more easily at transmission direction, means that the algorithm can be updated
a host within the network, and at a fewer number of hosts than more easily at a host within the network and at a fewer number of
the number of clients. Note that the status messages also help hosts than the number of clients. Note that the status messages
keep the pinhole (or mapping, respecitvely) active at on-path also help keep the pinhole (or mapping, respectively) active at
stateful devices. UDPSTP is at least partially compliant to on-path stateful devices. UDPSTP is at least partially compliant
section 3.1 of [RFC8085]: if the bottleneck is congested, but to Section 3.1 of [RFC8085] if the bottleneck is congested, but
pending congestion is avoided by limiting the duration of that pending congestion is avoided by limiting the duration of that
congestion to the minimum required to determine the bottleneck congestion to the minimum required to determine the bottleneck
capacity. capacity.
4. Stopping the Test: When the specified test duration has been 4. Stopping the Test: When the specified test duration has been
reached, the server initiates the exchange to stop the test by reached, the server initiates the exchange to stop the test by
setting a STOP indication in its outgoing Load PDUs or Status setting a STOP indication in its outgoing Load PDUs or Status
Feedback messages. After being received, the client acknowledges Feedback messages. After being received, the client acknowledges
it by also setting a STOP indication in its outgoing Load PDUs or it by also setting a STOP indication in its outgoing Load PDUs or
Status Feedback messages. A graceful connection termination at Status Feedback messages. A graceful connection termination at
each end then follows. Since the Load PDUs and Status Feedback each end then follows. Since the Load PDUs and Status Feedback
messages are used, this exchange is considered a sub-exchange of messages are used, this exchange is considered a sub-exchange of
3. If the Test traffic stops or the communication path fails, 3 above. If the test traffic stops or the communication path
the client assumes that the firewall will close the address/port fails, the client assumes that the firewall will close the
number combination after the firewall's configured idle traffic address/port number combination after the firewall's configured
timeout. idle traffic timeout.
5. Both the client and server react to unexpected interruptions in 5. Both the client and server react to unexpected interruptions in
the Control or Data phase, respectively. Watchdog timers limit the Control or Data phase, respectively. Watchdog timers limit
the time a server or client will wait before stopping all traffic the time a server or client will wait before stopping all traffic
and terminating a test. and terminating a test.
Figure 1 provides an example exchange of control and measurement PDUs Figure 1 provides an example exchange of control and measurement PDUs
for both a downstream and upstream UDP Speed Tests (always client for both downstream and upstream UDP Speed Tests (always client
initiated): initiated):
=========== Downstream Test =========== =========== Downstream Test ===========
+---------+ +---------+ +---------+ +---------+
| Client | Test Setup Request -----> | Server | | Client | Test Setup Request -----> | Server |
+---------+ +---------+ +---------+ +---------+
<----- Test Setup Response (Accept) <----- Test Setup Response (Accept)
<----- Null Request PDU <----- Null Request PDU
Test Activation Request -----> Test Activation Request ----->
skipping to change at page 10, line 8 skipping to change at line 384
<----- 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 3.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,
this 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 3.2. Handling of and Safeguards Required by Self-Induced Congestion
Active capacity measurement requires inducing intentional congestion. Active capacity measurement requires inducing intentional congestion.
On paths where the capacity bottleneck is not shared with other On paths where the capacity bottleneck is not shared with other
flows, this self-congestion will be observed as loss and/or delay. flows, this self-congestion will be observed as loss and/or delay.
However, when a path is shared by other flows, the measurment traffic However, when a path is shared by other flows, the measurement
can congest the bottleneck on the path and therefore can degrade the traffic can congest the bottleneck on the path and therefore degrade
performance of other flows. Unrestricted use of the tool could lead the performance of other flows. Unrestricted use of the tool could
to traffic starvation and significant issues. lead to traffic starvation and significant issues.
Measurements that generate traffic on shared paths (including WiFi Measurements that generate traffic on shared paths (including Wi-Fi
and Internet paths) need to consider the impact on other traffic. and Internet paths) need to consider the impact on other traffic.
Fixed-rate testing operates without congestion control and therefore Fixed-rate testing operates without congestion control and therefore
must not be executed over other operators network segments. Fixed- must not be executed over other operators' network segments. Fixed-
rate testing therefore is limited to paths within a domain entirely rate testing, therefore, is limited to paths within a domain entirely
managed and operated section-wise and end-to-end by the network managed and operated section-wise and end-to-end by the network
operator performing the measurement. When the risks of disruption to operator performing the measurement. When the risks of disruption to
other flows has been considered, testing could be extended to include other flows has been considered, testing could be extended to include
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 4.1) is required to
mitigate the impact of this congestion and to limit the duration of mitigate the impact of this congestion and to limit the duration of
any congestion by terminating the test when sudden impairments or a any congestion by terminating the test when sudden impairments or a
loss of connectivity is detected. loss of connectivity is detected.
4. Requirements, Security Operations, and Optional Checksum 4. Requirements, Security Operations, and Optional Checksum
Security and checksum operation aren't covered by [RFC9097], which Security and checksum operations aren't covered by [RFC9097], which
only defines the Method of Measurement. This section adds the only defines the Method of Measurement. This section adds the
operational specification related to security and optional checksum. operational specification related to security and optional checksum.
Due to the additional complexities, and loss of the direct Layer 3 to Due to the additional complexities, and loss of the direct Layer 3 to
Layer 4 mapping of packets to datagrams, it is recommended that Layer Layer 4 mapping of packets to datagrams, it is recommended that Layer
3 fragmentation be avoided. A simplified approach is to choose the 3 fragmentation be avoided. A simplified approach is to choose the
default datagram size small enough to prevent fragmentation. This default datagram size that is small enough to prevent fragmentation.
version of the specification does not support Packetization Layer This version of the specification does not support Datagram
Path MTU Discovery for Datagram Transports (DPLPMTUD) [RFC8899]. A Packetization Layer Path MTU Discovery (DPLPMTUD) [RFC8899]. A
future version could specify how to support this. DPLPMTUD support future version could specify how to support this. DPLPMTUD support
will require a carefully adapted protocol design to ensure will require a carefully adapted protocol design to ensure
interoperability. Unless IP fragmentation is expected, and is one of interoperability. Unless IP fragmentation is expected, and is one of
the attributes being measured, the IPv4 DF bit SHOULD be set for all the attributes being measured, the IPv4 Don't Fragment (DF) bit
tests. SHOULD be set for all tests.
Note: When this specification is used for network debugging, it may Note: When this specification is used for network debugging, it may
be useful for fragmentation to be under the control of the test be useful for fragmentation to be under the control of the test
administrator. administrator.
This section specifies generic requirements which a measurement load This section specifies generic requirements, which a measurement load
rate adjustment algorithm conforming to this specification MUST rate adjustment algorithm conforming to this specification MUST
fulfill. fulfill.
4.1. Load Rate Adjustment Algorithm Requirements 4.1. Load Rate Adjustment Algorithm Requirements
This document specifies an active capacity measurement method using a This document specifies an active capacity measurement method using a
load rate adjustment algorithm. The requirements following below and load rate adjustment algorithm. The requirements following below and
the currently standardised load rate adjustment algorithms B the currently standardized load rate adjustment algorithms B
[Y.1540Amd2] and C [TR-471] result from years of experiments and [Y.1540Amd2] and C [TR-471] result from years of experiments and
testing by the original authors. These tests were performed in Labs, testing by the original authors. These tests were performed in labs,
but also in the Internet and covered a set of different fixed, and also in the Internet, and covered a set of different fixed,
broadband, mobile and wireless access types and technologies in broadband, mobile, and wireless access types and technologies in
different countries and continents. Feedback received by performance different countries and continents. Feedback received by performance
measurement experts was included, as well as changes resulting from measurement experts was included, as well as changes resulting from
the standardisation of [RFC9097] (reflected also in algorithm B the standardization of [RFC9097] (reflected also in algorithm B
[Y.1540Amd2], which updates a prior version of this algorithm). [Y.1540Amd2], which updates a prior version of this algorithm).
Load rate adjustment algorithms for capacity measurement MUST comply Load rate adjustment algorithms for capacity measurement MUST comply
with the requirements specified by this section. New standard load with the requirements specified by this section. New standard load
rate adjustment algorithms for capacity measurement MUST be reviewed rate adjustment algorithms for capacity measurement MUST be reviewed
by IETF designated experts prior to assignment of a codepoint in the by IETF designated experts prior to assignment of a code point in the
IETF Test Activation PDU Rate Adjustment Algorithm Registry. "Test Activation PDU Rate Adjustment Algorithm" registry.
Load rate adjustment algorithm for capacity measurement requirements: The load rate adjustment algorithm for capacity measurement
requirements is 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 Congestion Control section MUST NOT be used as a general CCA.
Algorithm (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.
4. The nominal duration of a measurement interval at the 4. The nominal duration of a measurement interval at the
Destination, testIntTime (I in [RFC9097]), MUST default to a Destination, parameter testIntTime ("I" in [RFC9097]), MUST
value of no more than 10 seconds. default to a value of no more than 10 seconds.
5. A high-speed mode to achieve high sending rates quickly MUST 5. A high-speed mode to achieve high sending rates quickly MUST
reduce the measurement load below a level for which the first reduce the measurement load below a level for which the first
feedback interval inferred "congestion" from the measurements. feedback interval inferred "congestion" from the measurements.
Consecutive feedback intervals that have a supra-threshold count Consecutive feedback intervals that have a supra-threshold count
of sequence number anomalies and/or contain an upper delay of sequence number anomalies and/or contain an upper delay
variation threshold exception in all of the consecutive variation threshold exception in all of the consecutive
intervals, indicate "congestion" within a test. The threshold intervals indicate "congestion" within a test. The threshold of
of consecutive feedback intervals SHALL be configurable with a consecutive feedback intervals SHALL be configurable with a
default of 3 intervals and a maximum duration to infer default of 3 intervals and a maximum duration to infer
congestion of 500 ms. congestion of 500 ms.
6. Congestion MUST be indicated, if the Status Feedback PDUs either 6. Congestion MUST be indicated if the Status Feedback PDUs
indicate that sequence number anomalies were detected OR the indicate that either sequence number anomalies were detected OR
delay range was above the upper delay variation threshold. The the delay range was above the upper delay variation threshold.
RECOMMENDED threshold values are 10 for sequence number gaps and The RECOMMENDED threshold values are 10 for sequence number gaps
30 ms for lower and 90 ms for upper delay variation thresholds, and 30 ms for lower and 90 ms for upper delay variation
respectively. thresholds, respectively.
7. The load rate adjustment algorithm MUST include a Load PDU 7. The load rate adjustment algorithm MUST include a Load PDU
timeout and a Status PDU timeout which both stop the test when timeout and a Status PDU timeout, which both stop the test when
received PDU streams cease unexpectedly. received PDU streams cease unexpectedly.
8. The Load PDU timeout SHALL be reset to the configured value each 8. The Load PDU timeout SHALL be reset to the configured value each
time a Load PDU is received. If the Load PDU timeout expires, time a Load PDU is received. If the Load PDU timeout expires,
the receiver SHALL be closed and no further Status PDU feedback the receiver SHALL be closed and no further Status PDU feedback
sent. The default Load PDU timeout MUST be no more than 1 sec. sent. The default Load PDU timeout MUST be no more than 1
second.
9. The Status PDU timeout SHALL be reset to the configured value 9. The Status PDU timeout SHALL be reset to the configured value
each time a feedback message is received. If the Status PDU each time a feedback message is received. If the Status PDU
timeout expires, the sender SHALL be closed and no further load timeout expires, the sender SHALL be closed and no further load
packets sent. The default Status PDU timeout timeout MUST be no packets sent. The default Status PDU timeout MUST be no more
more than 1 second. than 1 second.
10. If a network operator is certain of the IP-Layer Capacity to be 10. If a network operator is certain of the IP-Layer Capacity to be
validated, then testing MAY start with a fixed-rate test at the validated, then testing MAY start with a fixed-rate test at the
IP-Layer Capacity and avoid activating the measurement load rate IP-Layer Capacity and avoid activating the measurement load rate
adjustment algorithm (see section 8.1 of [RFC9097]). However, adjustment algorithm (see Section 8.1 of [RFC9097]). However,
the stimulus for a diagnostic test (such as a subscriber the stimulus for a diagnostic test (such as a subscriber
request) strongly implies that there is no certainty, and the request) strongly implies that there is no certainty, and the
load adjustment algorithm is RECOMMENDED. load adjustment algorithm is RECOMMENDED.
11. This specification MUST only be used in circumstances consistent 11. This specification MUST only be used in circumstances consistent
with Section 10 of [RFC9097] ("Security Considerations"). with Section 10 (Security Considerations) of [RFC9097].
12. Further measurement load rate adjustment algorithm requirements 12. Further measurement load rate adjustment algorithm requirements
are specified by [RFC9097]. are specified by [RFC9097].
The following measurement load rate adjustment algorithms are subject The following measurement load rate adjustment algorithms are subject
to these requirements: to these requirements:
* Measurement load rate adjustment algorithm B [Y.1540Amd2]. * Measurement load rate adjustment algorithm B [Y.1540Amd2].
* Measurement load rate adjustment algorithm C [TR-471]. * Measurement load rate adjustment algorithm C [TR-471].
4.2. Parameters and Definitions 4.2. Parameters and Definitions
Please refer to Section 4 of [RFC9097] for an overview of Parameters Please refer to Section 4 of [RFC9097] for an overview of Parameters
related to the Maximum IP-Layer Capacity Metric and Method. A set of related to the Maximum IP-Layer Capacity Metric and Method. A set of
error-codes to support debugging are provided in Section 11.3.5. error codes to support debugging are provided in Section 11.3.5.
4.3. Security Mode Operations 4.3. Security Mode Operations
There are two security modes of operation that perform authentication There are two security modes of operation that perform authentication
of the client/server messaging. The two modes are: of the client/server messaging. The two modes are:
1. A REQUIRED mode with authentication during the Control phase 1. A REQUIRED mode with authentication during the Control phase
(Test Setup and Test Activation exchanges). This mode may be (Test Setup and Test Activation exchanges). This mode may be
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 2).
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 2).
The requirements discussed hereafter refer to the PDUs in sections 5 The requirements discussed hereafter refer to the PDUs in Sections 5
and 6 below, primarily the authMode, keyId, authUnixTime, and and 6 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 4.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 4.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 4.4). This key SHALL be used as input to
the KDF (Key Derivation Function), as specified in Section 4.4.1, to the KDF, as specified in Section 4.4.1, to obtain the actual keys
obtain the actual keys used by the client and server for used by the client and server for authentication.
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
replay of a PDU. See Table 2 of [TR-471] for a recommended timestamp replay of a PDU. See Table 2 of [TR-471] for a recommended timestamp
resolution. resolution.
Upon reception, the receiver SHALL validate the message PDU for Upon reception, the receiver SHALL validate the message PDU for
correct length, validity of authDigest, immediacy of authUnixTime, correct length, validity of authDigest, immediacy of authUnixTime,
and expected formatting (PDU-specific fields are also checked, such and expected formatting (PDU-specific fields are also checked, such
as protocol version). Validation of the authDigest requires that it as protocol version). Validation of the authDigest requires that it
will be extracted from the PDU and the field, along with the checkSum be extracted from the PDU and the field, along with the checkSum
field, zeroed prior to the HMAC calculation used for comparison (see field, zeroed prior to the Hashed Message Authentication Code (HMAC)
section 7.2 of [RFC9145]). calculation used for comparison (see Section 7.2 of [RFC9145]).
If the validation fails, the receiver SHOULD NOT continue with the If the validation fails, the receiver SHOULD NOT continue with the
Control phase and implement silent rejection (no further packets sent Control phase and implement silent rejection (no further packets sent
on the address/port pairs). The exception is when the testing hosts on the address/port pairs). The exception is when the testing hosts
have been configured for troubleshooting Control phase failures and have been configured for troubleshooting Control phase failures and
rejection messages will aid in the process. 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).
skipping to change at page 15, line 27 skipping to change at line 638
Test Activation exchange (Section 6). Test Activation exchange (Section 6).
4.3.2. Mode 2: Optional Authenticated Mode for Data Phase 4.3.2. Mode 2: Optional Authenticated Mode for Data Phase
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 7.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 read the current system (wall-clock) time The Status PDU sender SHALL 1) read the current system (wall-clock)
and populate the authUnixTime field, then 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 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 4.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 (no further validations), the test session will prematurely terminate (and no
load traffic SHALL be transmitted). This is necessary also to avoid further load traffic SHALL be transmitted). This is necessary also
potentially inducing congestion after there is an overload or loss on to avoid potentially inducing congestion after there is an overload
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 7.2) SHALL be set to all zeroes.
4.4. Key Management 4.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, specified in Section 4.4.1, to derive the actual keys to the KDF, as specified in Section 4.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, referring The key table SHALL have (at least) the following fields per
to Section 2 of [RFC7210]: Section 2 of [RFC7210]:
* AdminKeyName * AdminKeyName
* LocalKeyName * LocalKeyName
* KDF * KDF
* AlgID * AlgID
* Key * Key
skipping to change at page 17, line 22 skipping to change at line 728
* 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 is asked to assign “HMAC- defined in Section 6 of [RFC6234]. IANA has assigned "HMAC-SHA-256"
SHA-256” as a new KeyTable KDF (Section 11.2). as a new KeyTable KDF (Section 11.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.
* Context: The UTF-8 string representation of the authUnixTime field * Context: The UTF-8 string representation of the authUnixTime field
received in the very first Setup Request PDU sent from the client received in the very first Setup Request PDU sent from the client
to the server. This ensures that the derived keys are unique to to the server. This ensures that the derived keys are unique to
the session and tied to the temporal context of the initial setup the session and tied to the temporal context of the initial setup
skipping to change at page 17, line 49 skipping to change at line 755
protected from modification by the HMAC-SHA-256 hash present in protected from modification by the HMAC-SHA-256 hash present in
the authDigest field. the authDigest field.
* r: The length of the binary encoding of the counter SHALL be 32 * r: The length of the binary encoding of the counter SHALL be 32
(bits). (bits).
The total derived key material SHALL be 512 bits (64 octets) in The total derived key material SHALL be 512 bits (64 octets) in
length. The key material SHALL be structured as follows, from most length. The key material SHALL be structured as follows, from most
significant bit (MSB) to least significant bit (LSB): significant bit (MSB) to least significant bit (LSB):
* Client Authentication Key: 256 bits (32 octets), used for * Client Authentication Key: 256 bits (32 octets); used for
authenticating messages sent by the client. authenticating messages sent by the client.
* Server Authentication Key: 256 bits (32 octets), used for * Server Authentication Key: 256 bits (32 octets); used for
authenticating messages sent by the server. authenticating messages sent by the server.
This structure ensures that the derived keys are sufficient for This structure ensures that the derived keys are sufficient for
securing authentication operations within the protocol, while securing authentication operations within the protocol, while
maintaining clear separation of function and directionality. maintaining clear separation of function and directionality.
If authentication of the initial Setup Request PDU received by the If authentication of the initial Setup Request PDU received by the
server fails, due to an invalid authDigest field, any and all derived server fails, due to an invalid authDigest field, any and all derived
keying material and keys SHALL be considered invalid. keying material and keys SHALL be considered invalid.
The key material derived from the initial Setup Request PDU, either The key material derived from the initial Setup Request PDU, either
at the client prior to transmission or at the server upon reception, at the client prior to transmission or at the server upon reception,
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 cryptographic library, specifically the high-level Key-Based EVP_KDF
EVP_KDF implementation (Key-Based Envelope Key Derivation Function, implementation (Key-Based Envelope Key Derivation Function); see
see [EVP_KDF-KB] for details). [EVP_KDF-KB] for details.
4.5. Configuration of Network Functions with Stateful Filtering 4.5. Configuration of Network Functions with Stateful Filtering
Successful interaction with a local firewall assumes the firewall is Successful interaction with a local firewall assumes the firewall is
configured to allow a host to open a bidirectional connection using configured to allow a host to open a bidirectional connection using
unique source and destination addresses as well as port numbers by unique source and destination addresses as well as port numbers by
sending a packet using that 4-tuple for a given transport protocol. sending a packet using that 4-tuple for a given transport protocol.
The client's interaction with its firewall depends on this The client's interaction with its firewall depends on this
configuration. configuration.
skipping to change at page 19, line 6 skipping to change at line 807
the client from the ephemeral port communicated to the client in the the client from the ephemeral port communicated to the client in the
Test Setup Response. The Null Request may not reach the client: it Test Setup Response. The Null Request may not reach the client: it
may be discarded by the client's firewall. 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 behaviour apart from the above are out of Specifications covering NAT behavior, apart from the above, are out
scope of this document, as are combined implementations of NAT and of the scope of this document, as are combined implementations of NAT
firewalls too. and firewalls too.
4.6. Optional Checksum 4.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
internal state. internal state.
* Pre-filtering by the endpoint of erroneous data, to protect the * Pre-filtering by the endpoint of erroneous data, to protect the
transport from unnecessary processing and from corruption that it transport from unnecessary processing and from corruption that it
can not itself reject. cannot itself reject.
* Pre-filtering of incorrectly addressed destination packets, before * Pre-filtering of incorrectly addressed destination packets, before
responding to a source address. responding to a source address.
All of the PDUs exchanged between the client and server support an All of the PDUs exchanged between the client and server support an
optional header checksum that covers the various fields in the UDPSTP optional header checksum that covers the various fields in the UDPSTP
PDU (excluding the Payload Content of the Load PDU and, to be clear, PDU (excluding the payload content of the Load PDU and, to be clear,
also the IP- and UDP-header). The calculation is the same as the also the IP and UDP headers). The calculation is the same as the
16-bit one's complement Internet checksum used in the IPv4 packet 16-bit one's complement Internet checksum used in the IPv4 packet
header (see section 3.1 of [RFC0791]). This checksum is intended for header (see Section 3.1 of [RFC0791]). This checksum is intended for
environments where UDP data integrity may be uncertain. This environments where UDP data integrity may be uncertain. This
includes situations where the standard UDP checksum is not verified includes situations where the standard UDP checksum is not verified
upon reception or a nonstandard network API is in use (things upon reception or a nonstandard network API is in use (things
typically done to improve performance on low-end devices). However, typically done to improve performance on low-end devices). However,
all UDPSTP datagrams transmitted via IPv4 or IPv6 SHALL include a all UDPSTP datagrams transmitted via IPv4 or IPv6 SHALL include a
standard UDP checksum to protect other potential recipients to whom a standard UDP checksum to protect other potential recipients to whom a
corrupted packet may be delivered. In the case of a nonstandard corrupted packet may be delivered. In the case of a nonstandard
network API, one option to reduce processing overhead may be to network API, one option to reduce processing overhead may be to
restrict testing to only utilize a Payload Content of all zeros so restrict testing to only utilize a payload content of all zeros so
that the UDP checksum calculation need not include it for Load PDUs. that the UDP checksum calculation need not include it for Load PDUs.
If a PDU sender is populating the checkSum field, it SHALL do so as If a PDU sender is populating the checkSum field, it SHALL do so as
the last step after the PDU is built in all other respects (with the the last step after the PDU is built in all other respects (with the
checkSum field set to zero prior to the calculation). The PDU checkSum field set to zero prior to the calculation). The PDU
receiver SHALL subsequently verify the PDU checksum whenever checksum receiver SHALL subsequently verify the PDU checksum whenever checksum
processing has been configured and the field is populated. If PDU processing has been configured and the field is populated. If PDU
checksum validation fails, the PDU SHALL be discarded. checksum validation fails, the PDU SHALL be discarded.
Because of the redundancy when used in conjunction with Because of the redundancy when used in conjunction with
skipping to change at page 20, line 46 skipping to change at line 890
The client SHALL simultaneously start a test initiation timer so that The client SHALL simultaneously start a test initiation timer so that
if the Control phase fails to complete Test Setup and Test Activation if the Control phase fails to complete Test Setup and Test Activation
exchanges in the allocated time, the client software SHALL exit exchanges in the allocated time, the client software SHALL exit
(close the UDP socket and indicate an error message to the user). (close the UDP socket and indicate an error message to the user).
Lost messages result in a Test Setup and Test Activation failure. Lost messages result in a Test Setup and Test Activation failure.
The test initiation timer MAY reuse the test termination timeout The test initiation timer MAY reuse the test termination timeout
value. value.
The watchdog timeout is configured as a 1-second interval to trigger The watchdog timeout is configured as a 1-second interval to trigger
a warning message that the received traffic has stopped. The test a warning message that the received traffic has stopped. The test
termination timeout is based on the watchdog interval, and implements termination timeout is based on the watchdog interval and implements
a wait time of 2 additional seconds before triggering a non-graceful a wait time of 2 additional seconds before triggering a non-graceful
termination. termination.
Note: Any field labeled as 'reserved for alignment', in any PDU, MUST Note: Any field labeled as 'reserved for alignment', in any PDU, MUST
be set to 0 and MUST be ignored upon receipt. be set to 0 and MUST be ignored upon receipt.
The UDP PDU format layout SHALL be as follows (big-endian AB, The UDP PDU format layout SHALL be as follows (big-endian AB,
starting by most significant byte ending by least significant byte): starting by most significant byte and ending by least significant
byte):
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pduId | protocolVer | | pduId | protocolVer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mcIndex | mcCount | mcIdent | | mcIndex | mcCount | mcIdent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmdRequest | cmdResponse | maxBandwidth | | cmdRequest | cmdResponse | maxBandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| testPort |modifierBitmap | authMode | | testPort |modifierBitmap | authMode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authUnixTime | | authUnixTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. authDigest (32-octet) . . authDigest (32 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 is asked to assign the value hex pduId: A two-octet field. IANA has assigned the hex value 0xACE1
0xACE1 (Section 11.3.1). (Section 11.3.1).
protocolVer: A two-octet field, identifying the actual protocol protocolVer: A two-octet field identifying the actual protocol
version. IANA is asked to assign only one initial value, 20 version. IANA has assigned 20 as the value (Section 11.3.2).
(Section 11.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 at relative to all connections that make up a single test (starting
0, incremented by 1 per connection). It is used to differentiate at 0, incremented by 1 per connection). It is used to
separate connections within a multi-connection test. An differentiate separate connections within a multi-connection test.
implementation may restrict the number of connections supported for a An implementation may restrict the number of connections supported
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 setup. that the client is attempting to set up.
mcIdent: A two-octet field containing a pseudorandom non-zero mcIdent: A two-octet field containing a pseudorandom non-zero
identifier (via a Random Number Generator, source port number,...) identifier (via a Random Number Generator, source port number,
that is common to all connections of a single test. It is used by ...) that is common to all connections of a single test. It is
clients/servers to associate separate connections with a single used by clients/servers to associate separate connections with a
multi-connection test. single multi-connection test.
cmdRequest: A one-octet field set to CHSR_CREQ_SETUPREQ to indicate a cmdRequest: A one-octet field set to CHSR_CREQ_SETUPREQ to indicate
Setup request message. Note that CHSR_CREQ_NONE remains unused. a Setup Request message. Note that CHSR_CREQ_NONE remains unused.
cmdResponse: A one-octet field. All Request PDUs always have a cmdResponse: A one-octet field. All Request PDUs always have a
Command Response of XXXX_CRSP_NONE. Command Response of XXXX_CRSP_NONE.
maxBandwith: A two-octet field. A non-zero value of this field maxBandwith: A two-octet field. A non-zero value of this field
specifies the maximum bit rate the client expects to send or receive specifies the maximum bit rate the client expects to send or
during the requested test in Mbps. The server compares this value to receive during the requested test in Mbps. The server compares
its currently available configured limit for test admission control. this value to its currently available configured limit for test
This field MAY be used for rate-limiting the maximum rate the server admission control. This field MAY be used to rate-limit the
should attempt. The maxBandwidth field's most significant bit, the maximum rate the server should attempt. The maxBandwidth field's
CHSR_USDIR_BIT, is set to 0 by default to indicate "downstream" and most significant bit, the CHSR_USDIR_BIT, is set to 0 by default
has to be set to 1 to indicate "upstream". to indicate "downstream" and has to be set to 1 to indicate
"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 contains and populated by the server in the Test Setup Response. It
the UDP ephemeral port number on the server that the client has to contains the UDP ephemeral port number on the server that the
use for the Test Activation Request and subsequent Load or Status client has to use for the Test Activation Request and subsequent
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 11.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) while greater than 1250 bytes (unless CHSR_TRADITIONAL_MTU is set),
rates above 1 Gbps MAY produce IP packet sizes up to 9000 bytes. while rates above 1 Gbps MAY produce IP packet sizes up to 9000
When CHSR_JUMBO_STATUS is not set, all sending rates SHALL NOT bytes. When CHSR_JUMBO_STATUS is not set, all sending rates
produce IP packet sizes greater than 1250 bytes (unless SHALL NOT produce IP packet sizes greater than 1250 bytes
CHSR_TRADITIONAL_MTU is set). (unless CHSR_TRADITIONAL_MTU is set).
CHSR_TRADITIONAL_MTU This bit SHALL NOT be set by default. If set, CHSR_TRADITIONAL_MTU: This bit SHALL NOT be set by default. If
sending rates up to 1 Gbps MAY produce IP packets up to the set, sending rates up to 1 Gbps MAY produce IP packets up to
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 by 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 be values assigned (see Section 11.3.4). One of the following has to
set (see Section 4.3 for requirements and details of operation): be set (see Section 4.3 for requirements and details of
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 is A range of 60 through 63 is reserved for experimentation. IANA has
asked to create a registry for the assigned values; see the IANA created a registry for the assigned values; see the IANA
Considerations Section. Considerations section.
authUnixTime: A 32-bit timestamp of the current system (wall-clock) authUnixTime: A 32-bit timestamp of the current system (wall-clock)
time since the Unix Epoch on January 1st, 1970 at 00:00:00 UTC. time since the Unix Epoch on January 1, 1970 at 00:00:00 UTC.
authDigest: This field contains the 32-octet HMAC-SHA-256 hash that authDigest: This field contains the 32-octet HMAC-SHA-256 hash that
covers the entire PDU. Normally, the calculation is done as the last covers the entire PDU. Normally, the calculation is done as the
step of building the PDU. However, if the optional checkSum field is last step of building the PDU. However, if the optional checkSum
being utilized, it becomes the penultimate step and is done just field is being utilized, it becomes the penultimate step and is
prior to the checksum calculation (with the checkSum field set to done just prior to the checksum calculation (with the checkSum
zero). field set to zero).
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 the MUST be ignored upon receipt. Consistent naming and placement of
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 done entire PDU (see Section 4.6 for guidance). The calculation is
as the very last step of building the PDU, with the checkSum field done as the very last step of building the PDU, with the checkSum
set to zero. field set to zero.
5.2. Server Test Setup Request Processing and Response Generation 5.2. Server Test Setup Request Processing and Response Generation
This section describes the processes at the server to evaluate the This section describes the processes at the server that are used to
Test Setup Request and determine the next steps. When the server evaluate the Test Setup Request and determine the next steps. When
receives the Setup Request, it SHALL first perform the following: the server receives the Setup Request, it SHALL first perform the
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 4.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 4.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 4.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 5.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),
* Traditional MTU (modifierBitmap), * Traditional MTU (modifierBitmap), and
* Authentication mode (authMode) * Authentication mode (authMode)
that do not match the server configuration, the server MUST reject that do not match the server configuration, the server MUST reject
the Setup Request. the Setup Request.
If the Setup Request must be rejected, the conditions below determine If the Setup Request must be rejected, the conditions below determine
whether the server sends a response: whether the server sends a response:
* If the authDigest is valid, a Test Setup Response SHALL be sent * If the authDigest is valid, a Test Setup Response SHALL be sent
back to the client with a corresponding command response value back to the client with a corresponding Command Response value
indicating the reason for the rejection. indicating the reason for the rejection.
* If the authDigest is invalid, then the Test Setup Request SHOULD * If the authDigest is invalid, then the Test Setup Request SHOULD
fail silently. The exception is for operations support: server fail silently. The exception is for operations support: server
administrators are permitted to send a Setup Response to support administrators are permitted to send a Setup Response to support
operations and troubleshooting. operations and troubleshooting.
The additional circumstances when a server SHALL NOT communicate the The additional circumstances when a server SHALL NOT communicate the
appropriate Command Response code for an error condition (fail appropriate Command Response code for an error condition (fail
silently) are when: silently) are when:
1. the Setup Request PDU size is not equal to the 'struct * the Setup Request PDU size is not equal to the 'struct
controlHdrSR' size shown in Figure 3, controlHdrSR' size shown in Figure 3,
2. the PDU ID is not 0xACE1 (Test Setup PDU), or * the PDU ID is not 0xACE1 (Test Setup PDU), or
3. a directed attack has been detected, * a directed attack has been detected.
in which case the server will allow setup attempts to terminate In this case, the server will allow setup attempts to terminate
silently. Attack detection is beyond the scope of this silently. Attack detection is beyond the scope of this
specification. specification.
When the server replies to a Test Setup Request message, the Test When the server replies to a Test Setup Request message, the Test
Setup Response PDU is structured identically to the Request PDU and Setup Response PDU is structured identically to the Request PDU and
SHALL retain the original values received in it, with the following SHALL retain the original values received in it, with the following
exceptions: exceptions:
* The cmdRequest field is set to CHSR_CREQ_SETUPRSP, indicating a * The cmdRequest field is set to CHSR_CREQ_SETUPRSP, indicating a
response. response.
* The cmdResponse field is set to an error code (starting at * The cmdResponse field is set to an error code (starting at
cmdResponse 2, Bad Protocol Version, see Section 11.3.5), cmdResponse 2, Bad Protocol Version; see Section 11.3.5),
indicating the reason for rejection. If cmdResponse indicates a indicating the reason for rejection. If cmdResponse indicates a
bad protocol version (CHSR_CRSP_BADVER), the protocolVer field is bad protocol version (CHSR_CRSP_BADVER), the protocolVer field is
also updated to indicate the current expected version. also updated to indicate the current expected version.
* 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 page 27, line 5 skipping to change at line 1174
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 5.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 5)
When the server replies to the Test Setup Request message, the Test When the server replies to the Test Setup Request message, the Test
Setup Response PDU is structured identically to the Request PDU and Setup Response PDU is structured identically to the Request PDU and
SHALL retain the original values received in it, with the following SHALL retain the original values received in it, with the following
exceptions: 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 page 28, line 6 skipping to change at line 1224
packets received for the new ephemeral port, the server SHALL packets received for the new ephemeral port, 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 5.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authUnixTime | | authUnixTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. authDigest (32-octet) . . authDigest (32 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| keyId | reservedAuth1 | checkSum | | keyId | reservedAuth1 | checkSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Null Request PDU Layout Figure 4: Null Request PDU Layout
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 is asked to assign the value hex 0xDEAD (Section 11.3.1). pduId: IANA has assigned the hex value 0xDEAD (Section 11.3.1).
cmdRequest: Is set to CHNR_CREQ_NULLREQ indicating a Null Request cmdRequest: Set to CHNR_CREQ_NULLREQ to indicate a Null Request
message. message.
cmdResponse: Is set to CHNR_CRSP_NONE. cmdResponse: Set to CHNR_CRSP_NONE.
authMode: Same as Section 5.1 authMode: Same as in Section 5.1.
authUnixTime: Same as Section 5.1 authUnixTime: Same as in Section 5.1.
authDigest: Same as Section 5.1 authDigest: Same as in Section 5.1.
keyId: Same as Section 5.1 keyId: Same as in Section 5.1.
reservedAuth1: Same as Section 5.1 reservedAuth1: Same as in Section 5.1.
checkSum: Same as in Section 5.1.
checkSum: Same as Section 5.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>
// //
// Control header for UDP payload of Null Request PDU // Control header for UDP payload of Null Request PDU
skipping to change at page 29, line 43 skipping to change at line 1309
<CODE ENDS> <CODE ENDS>
Figure 5: Null Request PDU Figure 5: Null Request PDU
5.3. Setup Response Processing at the Client 5.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 5.2, Paragraph 2.
It SHALL then proceed to evaluate the other fields in the protocol, The client SHALL then proceed to evaluate the other fields in the
beginning with the protocol version, PDU ID (to validate the type of protocol, beginning with the protocol version, PDU ID (to validate
message), and cmdRequest for the role of the message, which MUST be the type of message), and cmdRequest for the role of the message,
Test Setup Response, CHSR_CREQ_SETUPRSP, as indicated by Figure 3. which MUST be Test Setup Response, CHSR_CREQ_SETUPRSP, as indicated
by Figure 3.
If the cmdResponse value indicates an error (values greater than If the cmdResponse value indicates an error (values greater than
CHSR_CRSP_ACKOK) the client SHALL display/report a relevant message CHSR_CRSP_ACKOK), the client SHALL display/report a relevant message
to the user or management process and exit. If the client receives a to the user or management process and exit. If the client receives a
Command Response code that is not equal to one of the codes defined, Command Response code that is not equal to one of the codes defined,
the client MUST terminate the connection and terminate operation of the client MUST terminate the connection and terminate operation of
the current Setup Request. If the Command Server Response code value the current Setup Request. If the Command Server Response code value
indicates success (CHSR_CRSP_ACKOK), the client SHALL compose a Test indicates success (CHSR_CRSP_ACKOK), the client SHALL compose a Test
Activation Request with all the test parameters it desires, such as Activation Request with all the test parameters it desires, such as
the test direction, the test duration, etc., as described below. the test direction, the test duration, etc., as described below.
6. Test Activation Request and Response 6. Test Activation Request and Response
This section is divided according to the sending and processing of This section is divided according to the sending and processing of
the client, server, and again at the client. the client and server and again at the client.
6.1. Client Generates Test Activation Request 6.1. Client Generates Test Activation Request
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| txInterval1 | | txInterval1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| udpPayload1 | | udpPayload1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burstSize1 | | burstSize1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| txInterval2 | | txInterval2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| udpPayload2 | | udpPayload2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burstSize2 | | burstSize2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| udpAddon2 | | udpAddon2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | lowThresh | | cmdRequest | cmdResponse | lowThresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| upperThresh | trialInt | | upperThresh | trialInt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| testIntTime | reserved1 | dscpEcn | | testIntTime | reserved1 | dscpEcn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| srIndexConf | useOwDelVar |highSpeedDelta | | srIndexConf | useOwDelVar |highSpeedDelta |
skipping to change at page 31, line 48 skipping to change at line 1382
| ignoreOooDup |modifierBitmap | rateAdjAlgo | reserved2 | | ignoreOooDup |modifierBitmap | rateAdjAlgo | reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. srStruct (28 octets) . . srStruct (28 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subIntPeriod | reserved3 | | subIntPeriod | reserved3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved4 | reserved5 | authMode | | reserved4 | reserved5 | authMode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authUnixTime | | authUnixTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. authDigest (32-octet) . . authDigest (32 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
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 is asked to assign the value hex 0xACE2 (Section 11.3.1). pduId: IANA has assigned the hex value 0xACE2 (Section 11.3.1).
cmdRequest: Is set to CHTA_CREQ_TESTACTUS to indicate an upstream cmdRequest: Set to CHTA_CREQ_TESTACTUS to indicate an upstream test
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 unused. downstream test activation. Note that CHTA_CREQ_NONE remains
See Section 11.3.6. unused. See Section 11.3.6.
cmdResponse: three CHTA_CRSP_<Indication> values are defined, see cmdResponse: Three CHTA_CRSP_<Indication> values are defined; see
Figure 7. Figure 7.
lowThresh: Two two-octet field, low threshold Low on the Range of lowThresh: Two two-octet fields, low threshold Low on the Range of
Round Trip Time variation, RTT (Range is values above minimum RTT, Round Trip Time variation, RTT (Range is values above minimum
see also Table 3 [TR-471]. RTT); see also Table 3 [TR-471].
upperThresh: Two two-octet field, upper threshold Low on the Range of upperThresh: Two two-octet fields, upper threshold Low on the Range
Round Trip Time variation, RTT (Range is values above minimum RTT, of Round Trip Time variation, RTT (Range is values above minimum
see also Table 3 of [TR-471]. RTT); see also Table 3 of [TR-471].
trialInt: A two-octet field, indicating the Status Feedback / trial trialInt: A two-octet field indicating the Status Feedback / trial
interval [ms]. The test interval Delta_t is subdivided into a number interval [ms]. The test interval Delta_t is subdivided into a
of sub-intervals dt, and each sub-interval is further divided into a number of sub-intervals dt, and each sub-interval is further
number of trial intervals (see [TR-471]). Starts by 1 and is divided into a number of trial intervals (see [TR-471]). Starts
continuously incremented during a single test interval (testIntTime). by 1 and is continuously incremented during a single test interval
(testIntTime).
testIntTime: A two-octet field. Duration of the test (either testIntTime: A two-octet field. Duration of the test (either
downlink or uplink) with search algorithm in use, which serves as the downlink or uplink) with search algorithm in use, which serves as
maximum duration of the search process in Seconds (see also the maximum duration of the search process in seconds (see also
TestInterval, Table 3 of [TR-471]. TestInterval in Table 3 of [TR-471]).
dscpEcn: Diffserv code point and ECN field, see also the DSCP field dscpEcn: Diffserv code point and ECN field; see also the DSCP field
specified by [TR-471]. This specification does not provide an ECN- specified by [TR-471]. This specification does not provide an
capable transport, therefore the sender SHALL set the ECN field to ECN-capable transport; therefore, the sender SHALL set the ECN
not_ECT. field to not_ECT.
srIndexConf: A two-octet field. The requested Configured Sending srIndexConf: A two-octet field. The requested Configured Sending
Rate Table index, used in a Test Activation Request, of the desired Rate Table index, used in a Test Activation Request, of the
fixed or starting sending rate (depending on whether desired fixed or starting sending rate (depending on whether
CHTA_SRIDX_ISSTART is cleared or set respectively). Because a value CHTA_SRIDX_ISSTART is cleared or set, respectively). Because a
of zero is a valid fixed or starting sending rate index, the field value of zero is a valid fixed or starting sending rate index, the
SHALL be set to its maximum (CHTA_SRIDX_DEF) when requesting the field SHALL be set to its maximum (CHTA_SRIDX_DEF) when requesting
default behavior of the server (starting the selected load rate the default behavior of the server (starting with the selected
adjustment algorithm at its minimum/zero index). This SHALL be load rate adjustment algorithm at its minimum/zero index). This
equivalent to setting srIndexConf to zero and setting the SHALL be equivalent to setting srIndexConf to zero and setting the
CHTA_SRIDX_ISSTART bit. CHTA_SRIDX_ISSTART bit.
useOwDelVar: A one-octet field. Boolean, default True (False: Use useOwDelVar: A one-octet field. Boolean, default True (if False,
RTT=round-trip delay variation in the load rate adjustment use RTT=round-trip delay variation in the load rate adjustment
algorithm)(True: EnableIPDV which uses one-way delay variation for algorithm; if True, use EnableIPDV, which uses one-way delay
the load rate adjustment algorithm), see EnableIPDV in Table 1 of variation for the load rate adjustment algorithm). See EnableIPDV
[TR-471]. in Table 1 of [TR-471].
highSpeedDelta: A one-octet field, see Appendix A of [RFC9097]. highSpeedDelta: A one-octet field; see Appendix A of [RFC9097].
slowAdjThresh, seqErrThresh: Two two-octet fields, see Appendix A of slowAdjThresh and seqErrThresh: Two two-octet fields; see Appendix A
[RFC9097]. of [RFC9097].
ignoreOooDup: A one-octet field. Ignore out of oder duplicates, ignoreOooDup: A one-octet field. Ignore out-of-order duplicates,
Boolean. When True only Loss counts toward received packet sequence Boolean. When True, only Loss counts toward received packet
number errors. When False, Loss, Reordering and Duplication are all sequence number errors. When False, Loss, Reordering, and
counted as sequence number errors, default True (see also Table 3 of Duplication are all counted as sequence number errors; default
[TR-471]). True (see also Table 3 of [TR-471]).
modifierBitmap: A one-octet field. This document only assigns two modifierBitmap: A one-octet field. This document only assigns two
bits in this bitmap, see Section 11.3.7: bits in this bitmap; see Section 11.3.7:
CHTA_SRIDX_ISSTART Treat srIndexConf as the starting sending rate to CHTA_SRIDX_ISSTART: Treat srIndexConf as the starting sending
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 PDU CHTA_RAND_PAYLOAD: Randomize the payload content beyond the Load
header PDU header.
Other bit positions are left unassigned by this document. Other bit positions are left unassigned per this document.
rateAdjAlgo: A one-octet field. The applied Load Rate Adjustment rateAdjAlgo: A one-octet field. The applied load rate adjustment
Algorithm, see Section 11.3.8. algorithm; see Section 11.3.8.
Sending Rate structure (srStruct), 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)
(initial) Load PDU transmission parameters the client SHALL use. For Load PDU transmission parameters the client SHALL use. For a Test
a Test Activation Request or a downstream test, this structure SHALL Activation Request or a downstream test, this structure SHALL be
be zeroed. Two sets of periodic transmission parameters are zeroed. Two sets of periodic transmission parameters are available,
available, allowing for dual independent transmitters (to support a allowing for dual independent transmitters (to support a high degree
high degree of rate granularity). The fields are defined as follows: of rate granularity). The fields are defined as follows:
txInterval1 and txInterval2: Two four-octet fields indicating the txInterval1 and txInterval2: Two four-octet fields indicating the
load rate transmit interval in [us]. A 100 us granularity is load rate transmit interval in [us]. A 100 us granularity is
recommended for optimal rate selection. recommended for optimal rate selection.
udpPayload1 and udpPayload2: Two four-octet fields indicating the UDP udpPayload1 and udpPayload2: Two four-octet fields indicating the
payload at load rate in [byte]. UDP payload at load rate in [byte].
burstSize1 and burstSize2: Two four-octet fields indicating the burst burstSize1 and burstSize2: Two four-octet fields indicating the
size at load rate by a dimensionless number (of datagrams). burst size at load rate by a dimensionless number (of datagrams).
udpAddon2: A four-octet field indicating the size of a single Load udpAddon2: A four-octet field indicating the size of a single Load
PDU to be sent at the end of the txInterval2 send sequence, even when PDU to be sent at the end of the txInterval2 send sequence, even
udpPayload2 or burstSize2 are zero and result in no transmission of when udpPayload2 or burstSize2 are zero and result in no
their own. 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 range (see also Table 3 of [TR-471]). Trials with subIntPeriod in a
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 Section 5.1 authMode: Same as in Section 5.1.
authUnixTime: Same as Section 5.1 authUnixTime: Same as in Section 5.1.
authDigest: Same as Section 5.1 authDigest: Same as in Section 5.1.
keyId: Same as Section 5.1 keyId: Same as in Section 5.1.
reservedAuth1: Same as Section 5.1 reservedAuth1: Same as in Section 5.1.
checkSum: Same as Section 5.1 checkSum: Same as in Section 5.1.
The Test Activation Request/Response message PDU (as well as the The Test Activation Request/Response message PDU (as well as the
included Sending Rate structure) SHALL be organized as follows: included Sending Rate structure) SHALL be organized as follows:
<CODE BEGINS> <CODE BEGINS>
// //
// Sending rate structure for a single row of transmission parameters // Sending rate structure for a single row of transmission parameters
// //
struct sendingRate { struct sendingRate {
uint32_t txInterval1; // Transmit interval (us) uint32_t txInterval1; // Transmit interval (us)
skipping to change at page 35, line 19 skipping to change at line 1545
uint8_t cmdRequest; // Command request uint8_t cmdRequest; // Command request
#define CHTA_CRSP_NONE 0 // (used with request) #define CHTA_CRSP_NONE 0 // (used with request)
#define CHTA_CRSP_ACKOK 1 // Acknowledgment #define CHTA_CRSP_ACKOK 1 // Acknowledgment
#define CHTA_CRSP_BADPARAM 2 // Bad/invalid test params #define CHTA_CRSP_BADPARAM 2 // Bad/invalid test params
uint8_t cmdResponse; // Command response uint8_t cmdResponse; // Command response
uint16_t lowThresh; // Low delay variation threshold (ms) uint16_t lowThresh; // Low delay variation threshold (ms)
uint16_t upperThresh; // Upper delay variation threshold (ms) uint16_t upperThresh; // Upper delay variation threshold (ms)
uint16_t trialInt; // Status Feedback/trial interval (ms) uint16_t trialInt; // Status Feedback/trial interval (ms)
uint16_t testIntTime; // Test interval time (sec) uint16_t testIntTime; // Test interval time (sec)
uint8_t reserved1; // (reserved for alignment) uint8_t reserved1; // (reserved for alignment)
uint8_t dscpEcn; // DiffServ and ECN field for testing uint8_t dscpEcn; // Diffserv and ECN field for testing
#define CHTA_SRIDX_DEF UINT16_MAX // Request default server search #define CHTA_SRIDX_DEF UINT16_MAX // Request default server search
uint16_t srIndexConf; // Configured Sending Rate Table index uint16_t srIndexConf; // Configured Sending Rate Table index
uint8_t useOwDelVar; // Use one-way delay, not RTT (BOOL) uint8_t useOwDelVar; // Use one-way delay, not RTT (BOOL)
uint8_t highSpeedDelta; // High-speed row adjustment delta uint8_t highSpeedDelta; // High-speed row adjustment delta
uint16_t slowAdjThresh; // Slow rate adjustment threshold uint16_t slowAdjThresh; // Slow rate adjustment threshold
uint16_t seqErrThresh; // Sequence error threshold uint16_t seqErrThresh; // Sequence error threshold
uint8_t ignoreOooDup; // Ignore Out-of-Order/Dup (BOOL) uint8_t ignoreOooDup; // Ignore Out-of-Order/Dup (BOOL)
#define CHTA_SRIDX_ISSTART 0x01 // Use srIndexConf as starting index #define CHTA_SRIDX_ISSTART 0x01 // Use srIndexConf as starting index
#define CHTA_RAND_PAYLOAD 0x02 // Randomize payload #define CHTA_RAND_PAYLOAD 0x02 // Randomize payload
uint8_t modifierBitmap; // Modifier bitmap uint8_t modifierBitmap; // Modifier bitmap
skipping to change at page 36, line 8 skipping to change at line 1580
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 6.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 5.2, Paragraph 2.
6.2.1. Server Rejects or Modifies Request 6.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 the starting send rate, which the client can successfully request. If
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, rateAdjAlgo
* Test duration/intervals: trialInt, testIntTime, subIntPeriod * Test duration/intervals: trialInt, testIntTime, 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 11.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.
* If the authDigest is invalid, then the Test Activation Request * If the authDigest is invalid, the Test Activation Request SHOULD
SHOULD fail silently. The exception is for operations support: fail silently. The exception is for operations support: server
server administrators are permitted to send a Activation Response administrators are permitted to send an Activation Response to
to support operations and troubleshooting. support operations and troubleshooting.
The additional circumstances when a server SHALL NOT communicate the The additional circumstances when a server SHALL NOT communicate the
appropriate Command Response code for an error condition (fail appropriate Command Response code for an error condition (fail
silently) are when: silently) are when:
1. the Test Activation Request PDU size is not equal to the 'struct * the Test Activation Request PDU size is not equal to the 'struct
controlHdrTA' size shown in Figure 7, controlHdrTA' size shown in Figure 7,
2. the PDU ID is not 0xACE2 (Test Activation PDU), or * the PDU ID is not 0xACE2 (Test Activation PDU), or
3. a directed attack has been detected, * a directed attack has been detected.
in which 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 6.2.2. Server Accepts Request and Generates Response
When the server sends the Test Activation Response, it SHALL set the When the server sends the Test Activation Response, it SHALL set the
cmdResponse field to CHTA_CRSP_ACKOK (see Section 11.3.9) cmdResponse field to CHTA_CRSP_ACKOK (see Section 11.3.9).
If the client has requested an upstream test, the server SHALL: If the client has requested an upstream test, the server SHALL:
* include the transmission parameters from the first row of the * include the transmission parameters from the first row of the
Sending Rate Table in the Sending Rate structure (if requested by Sending Rate Table in the Sending Rate structure (if requested by
srIndexConf having been set to CHTA_SRIDX_DEF), or srIndexConf having been set to CHTA_SRIDX_DEF), or
* include the transmission parameters from the designated Configured * include the transmission parameters from the designated Configured
Sending Rate Table index (srIndexConf) of the Sending Rate Sending Rate Table index (srIndexConf) of the Sending Rate
Table where, if CHTA_SRIDX_ISSTART is set in modifierBitmap, this Table where, if CHTA_SRIDX_ISSTART is set in modifierBitmap, this
will be used as the starting rate for the load rate adjustment will be used as the starting rate for the load rate adjustment
algorithm, else it will be considered a fixed-rate test. algorithm; else, it will be considered a fixed-rate test.
When generating the Test Activation Response (acceptance) for a When generating the Test Activation Response (acceptance) for a
downstream test, the server SHALL set all octets of the Sending Rate downstream test, the server SHALL set all octets of the Sending Rate
structure to zero. structure to zero.
If activation continues, the server prepares the new connection for If activation continues, the server prepares the new connection for
an upstream OR downstream test. an upstream OR downstream test.
In the case of an upstream test, the server SHALL prepare to use a In the case of an upstream test, the server SHALL prepare to use a
single timer to send Status PDUs at the specified interval. For a single timer to send Status PDUs at the specified interval. For a
downstream test, the server SHALL prepare to utilize dual timers to downstream test, the server SHALL prepare to utilize dual timers to
send Load PDUs based on send Load PDUs based on:
* the transmission parameters directly from the first row of the * the transmission parameters directly from the first row of the
Sending Rate Table (if requested by srIndexConf having been set to Sending Rate Table (if requested by srIndexConf having been set to
CHTA_SRIDX_DEF), or CHTA_SRIDX_DEF), or
* 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 6.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 5.2, Paragraph 2.
After the client receives the (vetted) Test Activation Response, it After the client receives the (vetted) Test Activation Response, it
first checks the command response value. first checks the Command Response value.
If the client receives a Test Activation cmdResponse field value that If the client receives a Test Activation cmdResponse field value that
indicates an error, the client SHALL display/report a relevant indicates an error, the client SHALL display/report a relevant
message to the user or management process and exit. message to the user or management process and exit.
If the client receives a Test Activation cmdResponse field value that If the client receives a Test Activation cmdResponse field value that
is not equal to one of the codes defined in Section 11.3.9, the is not equal to one of the codes defined in Section 11.3.9, the
client MUST terminate the connection and terminate operation of the client MUST terminate the connection and terminate operation of the
current setup procedure. current setup procedure.
If the client receives a Test Activation Command Response value that If the client receives a Test Activation Command Response value that
indicates success (CHTA_CRSP_ACKOK, see Section 11.3.9), the client indicates success (e.g., CHTA_CRSP_ACKOK; see Section 11.3.9), the
SHALL update its configuration to use any test parameters modified by client SHALL update its configuration to use any test parameters
the server. If the setup parameters coerced by the server are not modified by the server. If the setup parameters coerced by the
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 7. 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 7.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 first: 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. If the optional checkSum field is being utilized, validate the 2. Validate the checksum for the Load PDU header portion of the
checksum for the Load PDU header portion of the total message (as total message (as described in Section 4.6) if the optional
described in Section 4.6). 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 Note: If any of the above checks fail, the message SHALL be
considered invalid. considered 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 8 for handling the
watchdog timeout expiration at each endpoint. Note that the watchdog watchdog timeout expiration at each endpoint. Note that the watchdog
skipping to change at page 40, line 24 skipping to change at line 1783
Table via the index that is currently selected (which was indirectly Table via the index that is currently selected (which was indirectly
based on the feedback in its received Status Feedback messages). based on the feedback in its received Status Feedback messages).
However, when the client is sending Load PDUs in the role of sender, However, when the client is sending Load PDUs in the role of sender,
it SHALL use the discreet transmission parameters that were it SHALL use the discreet transmission parameters that were
communicated by the server in its periodic Status Feedback messages communicated by the server in its periodic Status Feedback messages
(and not referencing a Sending Rate Table directly). This approach (and not referencing a Sending Rate Table directly). This approach
allows the server to control the individual sending rates as well as allows the server to control the individual sending rates as well as
the algorithm used to decide when and how to adjust the rate. the algorithm used to decide when and how to adjust the rate.
The server uses a load rate adjustment algorithm which evaluates The server uses a load rate adjustment algorithm that evaluates
measurements taken locally at the Load PDU receiver. When the client measurements taken locally at the Load PDU receiver. When the client
is the receiver, the information is communicated to the server via is the receiver, the information is communicated to the server via
the periodic Status Feedback messages. When the server is the periodic Status Feedback messages. When the server is the receiver,
receiver, the information is used directly (although it is also the information is used directly (although it is also communicated to
communicated to the client via its periodic Status Feedback the client via its periodic Status Feedback messages). This approach
messages). This approach is unique to this protocol; it provides the is unique to this protocol; it provides the ability to search for the
ability to search for the Maximum IP Capacity and specify specific Maximum IP Capacity and specify specific sender behaviors that are
sender behaviors that are absent from other testing tools. Although absent from other testing tools. Although the algorithm depends on
the algorithm depends on the protocol, it is not part of the protocol the protocol, it is not part of the protocol per se.
per se.
The default algorithm (B, see [Y.1540]) has three paths to its The default algorithm (B; see [Y.1540]) has three paths to its
decision on the next sending rate: decision on the next sending rate:
1. When there are no impairments present (no sequence errors and low 1. When there are no impairments present (no sequence errors and low
delay variation), resulting in a sending rate increase. delay variation), resulting in a sending rate increase.
2. When there are low impairments present (no sequence errors but 2. When there are low impairments present (no sequence errors but
higher levels of delay variation), the same sending rate is higher levels of delay variation), the same sending rate is
maintained. maintained.
3. When the impairment levels are above the thresholds set for this 3. When the impairment levels are above the thresholds set for this
purpose and "congestion" is inferred, resulting in a sending rate purpose and "congestion" is inferred, resulting in a sending rate
decrease. decrease.
Algorithm B also has two modes for increasing/decreasing the sending Algorithm B also has two modes for increasing/decreasing the sending
rate: rate:
* A high-speed mode (fast) to achieve high sending rates quickly, * A high-speed mode (fast) to achieve high sending rates quickly but
but also back-off quickly when "congestion" is inferred from the that also backs off quickly when "congestion" is inferred from the
measurements. Consecutive feedback intervals that have a supra- measurements. Consecutive feedback intervals that have a supra-
threshold count of sequence number anomalies and/or contain an threshold count of sequence number anomalies and/or contain an
upper delay variation threshold exception in all of the upper delay variation threshold exception in all of the
consecutive intervals are sufficient to declare "congestion" consecutive intervals are sufficient to declare "congestion"
within a test. The threshold of consecutive feedback intervals within a test. The threshold of consecutive feedback intervals
SHALL be configurable with a default of 3 intervals. SHALL be configurable with a default of 3 intervals.
* A single-step (slow) mode where all rate adjustments use the * A single-step (slow) mode where all rate adjustments use the
minimum increase or decrease of one step in the sending rate minimum increase or decrease of one step in the sending rate
table. The single step mode continues after the first inference table. The single-step mode continues after the first inference
of "congestion" from measured impairments. of "congestion" from measured impairments.
An OPTIONAL load rate adjustment algorithm (designated C) has been An OPTIONAL load rate adjustment algorithm (designated C) has been
defined in [TR-471]. Algorithm C operation and modes are similar to defined in [TR-471]. Algorithm C operation and modes are similar to
B, but C uses multiplicative increases in the fast mode to reach the B, but C uses multiplicative increases in the fast mode to reach the
Gigabit range quickly and adds the possibility to re-try the fast gigabit range quickly and adds the possibility to re-try the fast
mode during a test (which improves the measurement accuracy in mode during a test (which improves the measurement accuracy in
dynamic or error-prone access, such as radio access). dynamic or error-prone access, such as radio access).
On the other hand, the test configuration MAY use a fixed sending On the other hand, the test configuration MAY use a fixed sending
rate requested by the client, using the field srIndexConf. rate requested by the client, using the field srIndexConf.
The client MAY communicate the desired fixed-rate in its test The client MAY communicate the desired fixed rate in its Test
activation request. Activation Request.
The UDP PDU format layout SHALL be as follows (big-endian AB): The UDP PDU format layout SHALL be as follows (big-endian AB):
0 1 2 3 0 1 2 3
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 | testAction | rxStopped | | pduId | testAction | rxStopped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lpduSeqNo | | lpduSeqNo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| udpPayload | spduSeqErr | | udpPayload | spduSeqErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spduTime_sec | | spduTime_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spduTime_nsec | | spduTime_nsec |
skipping to change at page 42, line 31 skipping to change at line 1866
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 is asked to assign the value hex 0xBEEF (Section 11.3.1). pduId: IANA has assigned the hex value 0xBEEF (Section 11.3.1).
testAction: A one-octet fileld 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 server TEST_ACT_STOP2 (second phase of graceful termination, sent by
and reciprocated by client). See Section 8 for additional server and reciprocated by client). See Section 8 for additional
information on test termination. information on test termination.
rxStopped: A one-octet fileld. 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 Status the remote endpoint that local receive traffic (either Load or
PDUs) has stopped. All outgoing Load or Status PDUs SHALL continue Status PDUs) has stopped. All outgoing Load or Status PDUs SHALL
to assert this indication until traffic is received again, or the continue to assert this indication until traffic is received
test is terminated. The time threshold to trigger this condition is again, or the test is terminated. The time threshold to trigger
expected to be a reasonable fraction of the watchdog timeout (a this condition is expected to be a reasonable fraction of the
default of one second is recommended). watchdog timeout (a default of one second is recommended).
lpduSeqNo: A four-octet field indicating the Load PDU sequence number lpduSeqNo: A four-octet field indicating the Load PDU sequence
(starting at 1). Used to determine loss, out-of-order, and number (starting at 1). Used to determine loss, out-of-order, and
duplicates. duplicates.
udpPayload: A two-octet field indicating the total payload size of udpPayload: A two-octet field indicating the total payload size of
the UDP datagram including the Load PDU message header and Payload the UDP datagram including the Load PDU message header and payload
Content (i.e., what the UDP socket read function would return). This content (i.e., what the UDP socket read function would return).
field allows the Load PDU receiver to maintain accurate receive This field allows the Load PDU receiver to maintain accurate
statistics if utilizing receive truncation (only requesting the Load receive statistics if utilizing receive truncation (only
PDU message header octets from the protocol stack). requesting the Load PDU message header octets from the protocol
stack).
spduSeqErr: A two-octet field indicating the Status PDU loss count, spduSeqErr: A two-octet field indicating the Status PDU loss count,
as seen by the Load PDU sender. This is determined by the Status PDU as seen by the Load PDU sender. This is determined by the Status
sequence number (spduSeqNo) in the most recently received Status PDU. PDU sequence number (spduSeqNo) in the most recently received
Used to communicate to the Load PDU receiver that return traffic (in Status PDU. Used to communicate to the Load PDU receiver that
the unloaded direction) is being lost. return traffic (in the unloaded direction) is being lost.
spduTime_sec/spduTime_nsec: Two four-octet fields containing a copy spduTime_sec/spduTime_nsec: Two four-octet fields containing a copy
of the most recent spduTime_sec/spduTime_nsec from the last Status of the most recent spduTime_sec/spduTime_nsec from the last Status
PDU received. Used for RTT measurements made by the Load PDU PDU received. Used for RTT measurements made by the Load PDU
receiver. receiver.
lpduTime_sec/lpduTime_nsec: Two four-octet fields containing the lpduTime_sec/lpduTime_nsec: Two four-octet fields containing the
local send time of the Load PDU. Used for one-way delay variation local send time of the Load PDU. Used for one-way delay variation
measurements made by the Load PDU receiver. measurements made by the Load PDU receiver.
rttRespDelay: A two-octet field indicating the RTT response delay, rttRespDelay: A two-octet field indicating the RTT response delay,
used to "adjust" raw RTT. On the Load PDU sender, it is the number used to "adjust" raw RTT. On the Load PDU sender, it is the
of milliseconds from reception of the most recent Status PDU (when number of milliseconds from reception of the most recent Status
the latest spduTime_sec/spduTime_nsec was obtained) to the PDU (when the latest spduTime_sec/spduTime_nsec was obtained) to
transmission of the Load PDU (where the previously obtained the transmission of the Load PDU (where the previously obtained
spduTime_sec/spduTime_nsec is returned). When the Load PDU receiver spduTime_sec/spduTime_nsec is returned). When the Load PDU
is calculating RTT, by subtracting the copied Status PDU send time receiver is calculating RTT, by subtracting the copied Status PDU
(in the Load PDU) from the local Load PDU receive time, this value is send time (in the Load PDU) from the local Load PDU receive time,
subtracted from the raw RTT to correct for any response delay due to this value is subtracted from the raw RTT to correct for any
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 Payload Section 4.6 for guidance). The checksum does not cover the
Content. The calculation is done as the very last step of building payload content. The calculation is done as the very last step of
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>
// //
// Load header for UDP payload of Load PDUs // Load header for UDP payload of Load PDUs
// //
struct loadHdr { struct loadHdr {
#define LOAD_ID 0xBEEF #define LOAD_ID 0xBEEF
skipping to change at page 45, line 5 skipping to change at line 1979
Section 5.2, Paragraph 2. Section 5.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 8 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 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| deltaTime | | deltaTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqErrLoss | | seqErrLoss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 45, line 36 skipping to change at line 2010
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarCnt | | delayVarCnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rttVarMinimum | | rttVarMinimum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rttVarMaximum | | rttVarMaximum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| accumTime | | accumTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | testAction | rxStopped | | pduId | testAction | rxStopped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spduSeqNo | | spduSeqNo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. srStruct (28 octets) . . srStruct (28 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subIntSeqNo | | subIntSeqNo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. sisSav (56 octets) . . sisSav (56 octets) .
skipping to change at page 46, line 36 skipping to change at line 2059
| tiRxBytes | | tiRxBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spduTime_sec | | spduTime_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spduTime_nsec | | spduTime_nsec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved3 | reserved4 | authMode | | reserved3 | reserved4 | authMode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authUnixTime | | authUnixTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. authDigest (32-octet) . . 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 6.
The primary role of the Status Feedback message is to communicate to The primary role of the Status Feedback message is to communicate the
the Load PDU sender the traffic conditions at the Load PDU receiver. traffic conditions at the Load PDU receiver to the Load PDU sender.
While the Sub-Interval Statistics structure (sisSav) covers the most While the Sub-Interval Statistics structure (sisSav) covers the most
recently saved (completed) sub-interval, similar fields directly in recently saved (completed) sub-interval, similar fields directly in
the Status PDU itself cover the most recent trial interval (the time the Status PDU itself cover the most recent trial interval (the time
period between Status Feedback messages, completed by this Status period between Status Feedback messages, completed by this Status
PDU). Both sets of statistics SHALL always be populated by the Load PDU). Both sets of statistics SHALL always be populated by the Load
PDU receiver, regardless of role (client or server). 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]. 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 is asked to assign the value hex 0xFEED (Section 11.3.1). pduId: IANA has assigned the hex value 0xFEED (Section 11.3.1).
spduSeqNo: A four-octet field containing the Status PDU sequence spduSeqNo: A four-octet field containing the Status PDU sequence
number (starting at 1). Used by the Load PDU sender to detect Status number (starting at 1). Used by the Load PDU sender to detect
PDU loss (in the unloaded direction). The loss count is communicated Status PDU loss (in the unloaded direction). The loss count is
back to the Load PDU receiver via spduSeqErr in subsequent Load PDUs. communicated back to the Load PDU receiver via spduSeqErr in
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 in number (starting at 1) that corresponds to the statistics provided
sisSav, for the last saved (completed) sub-interval. in sisSav, for the last saved (completed) sub-interval.
sisSav: Sub-interval statistics saved (completed) for the most recent sisSav: Sub-interval statistics saved (completed) for the most
sub-interval (as designated by the subIntSeqNo). These consist of recent sub-interval (as designated by the subIntSeqNo). These
the following fields: consist of the following fields:
rxDatagrams: A four-octet field Sub-interval indicating the number of rxDatagrams: A four-octet field Sub-interval indicating the
received datagrams during the Sub-Interval. number of received datagrams during the Sub-Interval.
rxBytes: An eight-octet field indicating the Sub-Interval byte count rxBytes: An eight-octet field indicating the Sub-Interval byte
(eight octets chosen to prevent overflow at high speeds). count (eight octets chosen to prevent overflow at high speeds).
deltaTime: A four-octet field indicating the exact duration of the deltaTime: A four-octet field indicating the exact duration of
Sub-Interval in microseconds. Used to calculate the received traffic the Sub-Interval in microseconds. Used to calculate the
rate together with rxBytes. received traffic rate together with rxBytes.
seqErrLoss/seqErrOoo/seqErrDup: Three four-octet fields, populated by seqErrLoss/seqErrOoo/seqErrDup: Three four-octet fields populated
the Loss, out-of-order, and duplicate totals. Available for both the by the Loss, out-of-order, and duplicate totals. Available for
sub-interval and trial interval, it is a breakout of the SeqErrors both the sub-interval and trial interval; it is a breakout of
count in Table 3 of [TR-471]. seqErrOoo and seqErrDup are realized by the SeqErrors count in Table 3 of [TR-471]. seqErrOoo and
comparing sequence numbers. A lookback list of the last n sequence seqErrDup are realized by comparing sequence numbers. A
numbers received is used as the basis. Each Load PDU sequence number lookback list of the last n sequence numbers received is used
is checked against this lookback. The number n may depend on the as the basis. Each Load PDU sequence number is checked against
implementation and on typical characteristics of environments, where this lookback. The number n may depend on the implementation
UDPST is deployed (like mobile networks or Wi-Fi). Currently, a and on typical characteristics of environments, where UDPSTP is
default sequence number interval of n=32 has been chosen. deployed (like mobile networks or Wi-Fi). Currently, a default
Specifically for seqErrOoo, each successively received higher seqno sequence number interval of n=32 has been chosen. Specifically
sets the next-expected-seqno to seqno+1 and anything below that is for seqErrOoo, each successively received higher seqno sets the
considered out-of-order (i.e., delayed). For example, given the next-expected seqno to seqno+1, and anything below that is
sequence 93, 94, 95, 100, 96, 97, 101, 98, 99, 102, 103, ... considered out of order (i.e., delayed). For example, given
reception of 96, 97, 98, and 99 would not increment the next- the sequence 93, 94, 95, 100, 96, 97, 101, 98, 99, 102, 103,
expected-seqno and would all be considered out-of-order. ... reception of 96, 97, 98, and 99 would not increment the
next-expected seqno and would all be considered out of order.
delayVarMin/delayVarMax/delayVarSum/delayVarCnt: Four four-octet delayVarMin/delayVarMax/delayVarSum/delayVarCnt: Four four-octet
fields populated by the one-way delay variation measurements of all fields populated by the one-way delay variation measurements of
received Load PDUs (where avg = sum/cnt). For each Load PDU all received Load PDUs (where avg = sum/cnt). For each Load
received, the send time (lpduTime_sec/lpduTime_nsec) is subtracted PDU received, the send time (lpduTime_sec/lpduTime_nsec) is
from the local receive time, which is then normalized by subtracting subtracted from the local receive time, which is then
the current clockDeltaMin. Available for both the sub-interval and normalized by subtracting the current clockDeltaMin. Available
trial interval. for both the sub-interval and trial interval.
rttVarMinimum/rttVarMaximum (in sisSav): Two four-octet fields rttVarMinimum/rttVarMaximum (in sisSav): Two four-octet fields
populated by the minimum and maximum RTT delay variation populated by the minimum and maximum RTT delay variation
(rttVarSample) in the sub-interval designated by the subIntSeqNo. (rttVarSample) in the sub-interval designated by the
subIntSeqNo.
accumTime: The accumulated time of the test in milliseconds, based on accumTime: The accumulated time of the test in milliseconds,
the duration of each sub-interval. Equivalent to the sum of each based on the duration of each sub-interval. Equivalent to the
deltaTime (although in ms) sent in each Status PDU during the test. sum of each deltaTime (although in ms) sent in each Status PDU
during the test.
clockDeltaMin: A four-octet field indicating the minimum clock delta clockDeltaMin: A four-octet field indicating the minimum clock
(difference) since the beginning of the test. Obtained by delta (difference) since the beginning of the test. Obtained
subtracting the send time of each Load PDU (lpduTime_sec/ by subtracting the send time of each Load PDU (lpduTime_sec/
lpduTime_nsec) from the local time that it was received. This value lpduTime_nsec) from the local time that it was received. This
is initialized with the first Load PDU received and is updated with value is initialized with the first Load PDU received and is
each subsequent one to maintain a current (and continuously updated) updated with each subsequent one to maintain a current (and
minimum. If the endpoint clocks are sufficiently synchronized, this continuously updated) minimum. If the endpoint clocks are
will be the minimum one-way delay in milliseconds. Otherwise, this sufficiently synchronized, this will be the minimum one-way
value may be negative, but still valid for one-way delay variation delay in milliseconds. Otherwise, this value may be negative
measurements for the default test duration (default is 10 [s]). If but still valid for one-way delay variation measurements for
the test duration is extended to a range of minutes, where the default test duration (default is 10 [s]). If the test
significant clock drift can occur, synchronized (or at least well- duration is extended to a range of minutes, where significant
disciplined) clocks may be required. clock drift can occur, synchronized (or at least well-
disciplined) clocks may be required.
rttMinimum (in Status PDU): A four-octet field indicating the minimum rttMinimum (in Status PDU): A four-octet field indicating the
"adjusted" RTT measured since the beginning of the test. See minimum "adjusted" RTT measured since the beginning of the
rttRespDelay regarding "adjusted" measurements. RTT is obtained by test. See rttRespDelay (Section 7.1) regarding "adjusted"
subtracting the copied spduTime_sec/spduTime_nsec in the received measurements. RTT is obtained by subtracting the copied
Load PDU from the local time at which it was received. This minimum spduTime_sec/spduTime_nsec in the received Load PDU from the
SHALL be kept current (and continuously updated) via each Load PDU local time at which it was received. This minimum SHALL be
received with an updated spduTime_sec/spduTime_nsec. This value MUST kept current (and continuously updated) via each Load PDU
be positive. Before an initial value can be established, and because received with an updated spduTime_sec/spduTime_nsec. This
zero is itself valid, it SHALL be set to STATUS_NODEL when value MUST be positive. Before an initial value can be
communicated in the Status PDU. established, and because zero is itself valid, it SHALL be set
to STATUS_NODEL when communicated in the 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
regarding "adjusted" measurements. RTT delay variation is obtained (Section 7.1) regarding "adjusted" measurements. RTT delay
by subtracting the current (and continuously updated) "adjusted" RTT variation is obtained by subtracting the current (and
minimum, communicated as rttMinimum (in Status PDU), from each continuously updated) "adjusted" RTT minimum, communicated as
"adjusted" RTT measurement (which is itself obtained by subtracting rttMinimum (in Status PDU), from each "adjusted" RTT
the copied spduTime_sec/spduTime_nsec in the received Load PDU from measurement (which is itself obtained by subtracting the copied
the local time at which it was received). Note that while one-way spduTime_sec/spduTime_nsec in the received Load PDU from the
delay variation is measured for every Load PDU received, RTT delay local time at which it was received). Note that while one-way
variation is only sampled via the Status PDU sent and the very next delay variation is measured for every Load PDU received, RTT
Load PDU received with the corresponding updated spduTime_sec/ delay variation is only sampled via the Status PDU sent and the
spduTime_nsec. When a new value is unavailable (possibly due to very next Load PDU received with the corresponding updated
packet loss), and because zero is itself valid, it SHALL be set to spduTime_sec/spduTime_nsec. When a new value is unavailable
STATUS_NODEL when communicated in the Status PDU. (possibly due to packet loss), and because zero is itself
valid, it SHALL be set to STATUS_NODEL when communicated in the
Status PDU.
delayMinUpd: A one-octet field. Boolean, 0 or 1, indicating that the delayMinUpd: A one-octet field. Boolean, 0 or 1, indicating that
clockDeltaMin and/or rttMinimum (in Status PDU), as measured by the the clockDeltaMin and/or rttMinimum (in Status PDU), as
Load PDU receiver, has been updated. measured by the Load PDU receiver, has been updated.
tiDeltaTime/tiRxDatagrams/tiRxBytes: Three four-octet fields, tiDeltaTime/tiRxDatagrams/tiRxBytes: Three four-octet fields
populated by the trial interval time in microseconds, along with the populated by the trial interval time in microseconds, along
received datagram and byte counts. Used to calculate the received with the received datagram and byte counts. Used to calculate
traffic rate for the trial interval. the received 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
spduTime_sec/spduTime_nsec in subsequent Load PDUs after being into spduTime_sec/spduTime_nsec in subsequent Load PDUs after
received by the Load PDU sender. Used for RTT measurements. being received by the Load PDU sender. Used for RTT
measurements.
authMode: Same as Section 5.1 authMode: Same as in Section 5.1.
authUnixTime: Same as Section 5.1 authUnixTime: Same as in Section 5.1.
authDigest: Same as Section 5.1 authDigest: Same as in Section 5.1.
keyId: Same as Section 5.1 keyId: Same as in Section 5.1.
reservedAuth1: Same as Section 5.1 reservedAuth1: Same as in Section 5.1.
checkSum: Same as Section 5.1 checkSum: Same as in Section 5.1.
The Status Feedback message PDU (as well as the included Sub-Interval The Status Feedback message PDU (as well as the included Sub-Interval
Statistics structure) SHALL be organized as follows: Statistics structure) SHALL be organized as follows:
<CODE BEGINS> <CODE BEGINS>
// //
// Sub-interval statistics structure for received traffic information // Sub-interval statistics structure for received traffic information
// //
struct subIntStats { struct subIntStats {
uint32_t rxDatagrams; // Received datagrams uint32_t rxDatagrams; // Received datagrams
skipping to change at page 51, line 36 skipping to change at line 2298
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
value of TEST_ACT_STOP2. While in this state, the server MAY reduce value of TEST_ACT_STOP2. While in this state, the server MAY reduce
any Load PDU bursts to a size of one. any Load PDU bursts to a size of one.
When the client receives a Load or Status PDU with the TEST_ACT_STOP2 When the client receives a Load or Status PDU with the TEST_ACT_STOP2
indication, it SHALL finalize testing, display the test results, and indication, it SHALL finalize testing, display the test results, and
also mark its local connection with a test action of TEST_ACT_STOP2 mark its local connection with a test action of TEST_ACT_STOP2 (so
(so that any PDUs subsequently received can be ignored). that any PDUs subsequently received can be ignored).
With the test action of the client's connection set to With the test action of the client's connection set to
TEST_ACT_STOP2, the very next expiry of a send timer, for either a TEST_ACT_STOP2, the very next expiry of a send timer, for either a
Load or Status PDU, SHALL result in it and any subsequent PDUs to be Load or a Status PDU, SHALL result in it and any subsequent PDUs
sent with a testAction value of TEST_ACT_STOP2 (as confirmation to being sent with a testAction value of TEST_ACT_STOP2 (as confirmation
the server). While in this state, the client MAY reduce any Load PDU to the server). While in this state, the client MAY reduce any Load
bursts to a size of one. The client SHALL then schedule an immediate PDU bursts to a size of one. The client SHALL then schedule an
end time for the connection. immediate end time for the connection.
When the server receives the TEST_ACT_STOP2 confirmation in the Load When the server receives the TEST_ACT_STOP2 confirmation in the Load
or Status PDU, the server SHALL schedule an immediate end time for or Status PDU, the server SHALL schedule an immediate end time for
the connection which closes the socket and deallocates the associated the connection that closes the socket and deallocates the associated
resources. The TEST_ACT_STOP2 exchange constitutes a graceful resources. The TEST_ACT_STOP2 exchange constitutes a graceful
termination of the test. termination of the test.
In a non-graceful test stop due to path failure, the watchdog In a non-graceful test stop due to path failure, the watchdog
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 9. 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.
It is RECOMMENDED to locate test endpoints as close to the intended It is RECOMMENDED to locate test endpoints as close to the intended
measured link(s) as practical. The testing operator MUST set a value measured link(s) as practical. The testing operator MUST set a value
for the MaxHops Parameter, based on the expected path length. This for the MaxHops Parameter, based on the expected path length. This
Parameter can keep measurement traffic from straying too far beyond Parameter can keep measurement traffic from straying too far beyond
the intended path. the intended path.
It is obviously counterproductive to run more than one independent It is obviously counterproductive to run more than one independent
and concurrent test (regardless of the number of flows in the test and concurrent test (regardless of the number of flows in the test
stream) attempting to measure the maximum capacity on a single path. stream) when attempting to measure the maximum capacity on a single
The number of concurrent, independent tests of a path SHALL be path. The number of concurrent, independent tests of a path SHALL be
limited to one. limited to one.
The load rate adjustment algorithm's scope is limited to helping The load rate adjustment algorithm's scope is limited to helping
determine the Maximum IP-Layer Capacity in the context of an determine the Maximum IP-Layer Capacity in the context of an
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 9.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 10. Security Considerations
Active metrics and measurements have a long history of security Active metrics and measurements have a long history of security
considerations. The security considerations that apply to any active considerations. The security considerations that apply to any active
measurement of live paths are relevant here. See [RFC4656] and measurement of live paths are relevant here. See [RFC4656] and
[RFC5357]. [RFC5357].
When considering privacy of those involved in measurement or those When considering privacy of those involved in measurement or those
whose traffic is measured, the sensitive information available to whose traffic is measured, the sensitive information available to
potential observers is greatly reduced when using active techniques potential observers is greatly reduced when using active techniques
which are within this scope of work. Passive observations of user that are within this scope of work. Passive observations of user
traffic for measurement purposes raise many privacy issues. We refer traffic for measurement purposes raise many privacy issues. See the
the reader to the privacy considerations described in the LMAP privacy considerations described in the LMAP Framework [RFC7594],
Framework [RFC7594], which covers active and passive techniques. which covers active and passive techniques.
There are some new considerations for Capacity measurement as Below are some new considerations for capacity measurement as
described in this document. described in this document.
1. Cooperating client and server hosts and agreements to test the 1. Cooperating client and server hosts and agreements to test the
path between the hosts are REQUIRED. Hosts perform in either the path between the hosts are REQUIRED. Hosts perform in either the
server or client roles. One way to assure a cooperative server or the client roles. One way to assure a cooperative
agreement employs the optional Authorization mode through the use agreement employs the optional Authorization mode is through the
of the authDigest field and the known identity associated with use of the authDigest field and the known identity associated
the shared key used to create the authDigest field via the KDF. with the shared key used to create the authDigest field via the
Other means are also possible, such as access control lists at KDF. Other means are also possible, such as access control lists
the server. at the server.
2. It is REQUIRED to have a user client-initiated setup handshake 2. It is REQUIRED to have a user client-initiated setup handshake
between cooperating hosts that allows firewalls to control between cooperating hosts that allows firewalls to control
inbound unsolicited UDP traffic which either goes to a control inbound unsolicited UDP traffic that goes to either a control
port or to ephemeral ports that are only created as needed. port or ephemeral ports that are only created as needed.
Firewalls protecting each host can both continue to do their job 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 above. Section 4.
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
CHSR_USDIR_BIT bit) in the Setup Request from the client to limit the CHSR_USDIR_BIT bit) in the Setup Request from the client to
the maximum that it will attempt to achieve. limit the maximum that it will attempt to achieve.
6. Service subscribers with limited data volumes who conduct 6. Service subscribers with limited data volumes who conduct
extensive capacity testing might experience the effects of extensive capacity testing might experience the effects of
Service Provider controls on their service. Testing with the Service Provider controls on their service. Testing with the
Service Provider's measurement hosts SHOULD be limited in Service Provider's measurement hosts SHOULD be limited in
frequency and/or overall volume of test traffic (for example, the frequency and/or overall volume of test traffic (for example, the
range of test interval duration values should be limited). range of test interval duration values should be limited).
One specific attack that has been recognized is an on-path attack on One specific attack that has been recognized is an on-path attack on
the testAction field where the attacker would set or clear the STOP the testAction field where the attacker would set or clear the STOP
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 an assigning a suitable "Test mode, whose support is indicated by assigning a suitable "Test Setup
Setup PDU Authentication Mode Registry" value (see Section 11.3.4 ). PDU Authentication Mode" registry value (see Section 11.3.4 ).
11. IANA Considerations 11. IANA Considerations
This document requests IANA to assign a User/Registered UDP port for Per this document, IANA has assigned a UDP port for the Test Setup
the Test Setup exchange in the Control phase of protocol operation, exchange in the Control phase of protocol operation and has created a
and to create a new registry group for the UDP Speed Test Protocol new registry group for the UDPSTP.
(UDPSTP).
11.1. New User Port Number Assignment 11.1. New User Port Number Assignment
IANA will allocate the following service name to the "Service Name IANA has registered the following service name in the "Service Name
and Transport Protocol Port Number Registry" registry: and Transport Protocol Port Number Registry":
Service: udpstp
Service Name: udpstp
Port Number: 24601
Transport Protocol: UDP Transport Protocol: UDP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
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>
Contact: IETF Chair <chair@ietf.org>
Reference: RFC 9946
Reference: This RFC, RFCYYYY. The protocol uses IP-Layer Unicast. A single port number was
assigned to help configure firewalls and other port-based systems for
Port Number: <PORTNUM> of the IANA User Port range (1024-49151) access control prior to negotiating dynamic ports between client and
server.
The protocol uses IP-Layer Unicast. The assignment of a single port
number is requested to help configure firewalls and other port-based
systems for access control prior to negotiating dynamic ports between
client and server.
11.2. New KeyTable KDF 11.2. New KeyTable KDF
IANA will allocate the following KDF to the existing list of IANA has added the following KDF entry to the "KeyTable KDFs"
KeyTable KDFs (see https://www.iana.org/assignments/keytable/ registry (see <https://www.iana.org/assignments/keytable>):
keytable.xhtml#kdf).
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
11.3. New UDPSTP Registry Group 11.3. New UDPSTP Registry Group
IANA will create the following registries in a new registry group IANA has created the registries in the subsections that follow under
called "UDP Speed Test Protocol (UDPSTP)". a new registry group called "UDP Speed Test Protocol (UDPSTP)".
IANA is requested to the following note under the "UDP Speed Test IANA has added the following note under the "UDP Speed Test Protocol
Protocol (UDPSTP)" registry group: (UDPSTP)" registry group:
Note: Values reserved for experimental use are not expected to be | Note: Values reserved for experimental use are not expected to be
used on the Internet, but for experiments that are confined to closed | used on the Internet, but for experiments that are confined to
environments. | closed environments.
11.3.1. PDU Identifier Registry 11.3.1. PDU Identifier Registry
IANA will create 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 1. the registration procedures [RFC8126] described in Table 2.
Range(Hex) Registration Procedures
===============================================================
0xFFFF and 0x0000 Reserved
0x8000-0xFFFE IETF Review
0x0001-0x7F00 Specification Required
0x7F01-0x7FE0 Experimental
0x7FE1-0x7FFF Private Use
Table 1: Registration procedures for the PDU Identifier registry
Initially, IANA will assign the "PDU Identifier" registry with the
values in Table 2:
Value Description Reference
===================================================
0xACE1 Test Setup PDU <this RFC>
0xACE2 Test Activation PDU <this RFC> +===================+=========================+
| Range(Hex) | Registration Procedures |
+===================+=========================+
| 0xFFFF and 0x0000 | Reserved |
+-------------------+-------------------------+
| 0x8000-0xFFFE | IETF Review |
+-------------------+-------------------------+
| 0x0001-0x7F00 | Specification Required |
+-------------------+-------------------------+
| 0x7F01-0x7FE0 | Experimental Use |
+-------------------+-------------------------+
| 0x7FE1-0x7FFF | Private Use |
+-------------------+-------------------------+
0xBEEF Load PDU <this RFC> Table 2: Registration Procedures for the
PDU Identifier Registry
0xDEAD Null PDU <this RFC> IANA has assigned values in the "PDU Identifier" registry as follows:
0xFEED Status Feedback PDU <this RFC> +===============+===============================+===========+
| Value | Description | Reference |
+===============+===============================+===========+
| 0x0000 | Reserved | RFC 9946 |
+---------------+-------------------------------+-----------+
| 0x7F01-0x7FE0 | Reserved for Experimental Use | RFC 9946 |
+---------------+-------------------------------+-----------+
| 0x7FE1-0x7FFF | Reserved for Private Use | RFC 9946 |
+---------------+-------------------------------+-----------+
| 0xACE1 | Test Setup PDU | RFC 9946 |
+---------------+-------------------------------+-----------+
| 0xACE2 | Test Activation PDU | RFC 9946 |
+---------------+-------------------------------+-----------+
| 0xBEEF | Load PDU | RFC 9946 |
+---------------+-------------------------------+-----------+
| 0xDEAD | Null PDU | RFC 9946 |
+---------------+-------------------------------+-----------+
| 0xFEED | Status Feedback PDU | RFC 9946 |
+---------------+-------------------------------+-----------+
| 0xFFFF | Reserved | RFC 9946 |
+---------------+-------------------------------+-----------+
Table 2: Initial PDU Identifier Values Table 3: Initial Values of the PDU Identifier Registry
11.3.2. Protocol Version Registry 11.3.2. Protocol Version Registry
IANA will create 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 3. registration procedures [RFC8126] described in Table 4.
Range(Decimal) Registration Procedures
===============================================================
0-19 Reserved
20-40960 IETF Review
40961-53248 Specification Required
53249-65534 Experimental
65535 Reserved +================+=========================+
| Range(Decimal) | Registration Procedures |
+================+=========================+
| 0-19 | Reserved |
+----------------+-------------------------+
| 20-40960 | IETF Review |
+----------------+-------------------------+
| 40961-53248 | Specification Required |
+----------------+-------------------------+
| 53249-65534 | Experimental Use |
+----------------+-------------------------+
| 65535 | Reserved |
+----------------+-------------------------+
Table 3: Registration procedures for the Protocol Version registry Table 4: Registration Procedures for the
Protocol Version Registry
Initially, IANA will assign the decimal value 20 listed in Table 4 in IANA has assigned decimal value 20 in the "Protocol Version" registry
the "Protocol Version" registry: as follows:
Value Reference +=======+===========+
================================================ | Value | Reference |
20 <this RFC> +=======+===========+
| 20 | RFC 9946 |
+-------+-----------+
Table 4: Initial Protocol Version value Table 5: Initial Value
of the Protocol
Version Registry
11.3.3. Test Setup PDU Modifier Bitmap Registry 11.3.3. Test Setup PDU Modifier Bitmap Registry
IANA will create 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 5. [RFC8126] described in Table 6.
Range(Bitmap) Registration Procedures
===============================================================
00000000-01111111 IETF Review
10000000 Reserved
Table 5: Registration procedures for the Test Setup PDU Modifier +===================+=========================+
Bitmap Registry | Range(Bitmap) | Registration Procedures |
Initially, IANA will assign the bitmap values defined by Table 6 in +===================+=========================+
the "Test Setup PDU Modifier Bitmap" registry. | 00000000-01111111 | IETF Review |
+-------------------+-------------------------+
| 10000000 | Reserved |
+-------------------+-------------------------+
Value Description Reference Table 6: Registration Procedures for the
=============================================================== Test Setup PDU Modifier Bitmap Registry
0x00 No modifications <this RFC>
0x01 Allow Jumbo datagram <this RFC> IANA has assigned bitmap values in the "Test Setup PDU Modifier
sizes above sending Bitmap" registry as follows:
rates of 1 Gbps
0x02 Use Traditional MTU <this RFC> +=======+===============================+===========+
(1500 bytes with | Value | Description | Reference |
IP-header) +=======+===============================+===========+
| 0x00 | No modifications | RFC 9946 |
+-------+-------------------------------+-----------+
| 0x01 | Allow Jumbo datagram sizes | RFC 9946 |
| | above sending rates of 1 Gbps | |
+-------+-------------------------------+-----------+
| 0x02 | Use Traditional MTU (1500 | RFC 9946 |
| | bytes with IP-header) | |
+-------+-------------------------------+-----------+
Table 6: Initial Test Setup PDU Modifier Bitmap values Table 7: Initial Values of the Test Setup PDU
Modifier Bitmap Registry
11.3.4. Test Setup PDU Authentication Mode Registry 11.3.4. Test Setup PDU Authentication Mode Registry
IANA will create 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 7. [RFC8126] described in Table 8.
Range(Decimal) Registration Procedures
===============================================================
0-59 IETF Review
60-63 Experimental
64-255 Reserved
Table 7: Registration procedures for the Test Setup PDU
Authentication Mode registry
Initially, IANA will assign the decimal values defined by Table 8 in +================+=========================+
the "Test Setup PDU Authentication Mode" registry. | Range(Decimal) | Registration Procedures |
+================+=========================+
| 0-59 | IETF Review |
+----------------+-------------------------+
| 60-63 | Experimental Use |
+----------------+-------------------------+
| 64-255 | Reserved |
+----------------+-------------------------+
Value Description Reference Table 8: Registration Procedures for the
=============================================================== Test Setup PDU Authentication Mode
0 Not used <this RFC> Registry
1 Required authentication <this RFC> IANA has assigned decimal values in the "Test Setup PDU
for the Control phase Authentication Mode" registry as follows:
2 Optional authentication for <this RFC> +=======+===============================================+===========+
the Data phase, in addition | Value | Description | Reference |
to the Control phase +=======+===============================================+===========+
| 0 | Not used | RFC 9946 |
+-------+-----------------------------------------------+-----------+
| 1 | Required authentication for the Control | RFC 9946 |
| | phase | |
+-------+-----------------------------------------------+-----------+
| 2 | Optional authentication for the Data | RFC 9946 |
| | phase, in addition to the Control phase | |
+-------+-----------------------------------------------+-----------+
Table 8: Initial Test Setup PDU Authentication Mode values Table 9: Initial Values of the Test Setup PDU Authentication Mode
Registry
11.3.5. Test Setup PDU Command Response Field Registry 11.3.5. Test Setup PDU Command Response Field Registry
IANA will create 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 9. procedures [RFC8126] described in Table 10.
Range(Decimal) Registration Procedures
===============================================================
0-127 IETF Review
128-239 Specification Required
240-249 Experimental
250-254 Private Use
255 Reserved
Table 9: Registration procedures for the Test Setup PDU Command
Response Field Registry
Initially, IANA will assign the decimal values defined by Table 10 in
the "Test Setup PDU Command Response Field" registry.
Value Description Reference
===============================================================
0 None (used by <this RFC>
client in Request)
1 Acknowledgment <this RFC>
2 Bad Protocol Version <this RFC>
3 Invalid Jumbo datagram <this RFC>
option
4 Unexpected Authentication <this RFC>
in Setup Request
5 Authentication missing <this RFC>
in Setup Request
6 Invalid authentication <this RFC>
method
7 Authentication failure <this RFC>
8 Authentication time is <this RFC>
invalid in Setup Request
9 No Maximum test Bit rate <this RFC>
specified
10 Server Maximum Bit rate <this RFC> +================+=========================+
exceeded | Range(Decimal) | Registration Procedures |
+================+=========================+
| 0-127 | IETF Review |
+----------------+-------------------------+
| 128-239 | Specification Required |
+----------------+-------------------------+
| 240-249 | Experimental Use |
+----------------+-------------------------+
| 250-254 | Private Use |
+----------------+-------------------------+
| 255 | Reserved |
+----------------+-------------------------+
11 MTU option does not match <this RFC> Table 10: Registration Procedures for
server the Test Setup PDU Command Response
Field Registry
12 Multi-connection parameters <this RFC> IANA has assigned decimal values in the "Test Setup PDU Command
rejected by server Response Field" registry as follows:
13 Connection allocation <this RFC> +=========+============================================+===========+
failure on server | Value | Description | Reference |
+=========+============================================+===========+
| 0 | None (used by client in Request) | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 1 | Acknowledgment | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 2 | Bad protocol version | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 3 | Invalid Jumbo datagram option | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 4 | Unexpected authentication in Setup Request | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 5 | Authentication missing in Setup Request | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 6 | Invalid authentication method | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 7 | Authentication failure | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 8 | Authentication time is invalid in Setup | RFC 9946 |
| | Request | |
+---------+--------------------------------------------+-----------+
| 9 | No maximum test bit rate specified | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 10 | Server maximum bit rate exceeded | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 11 | MTU option does not match server | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 12 | Multi-connection parameters rejected by | RFC 9946 |
| | server | |
+---------+--------------------------------------------+-----------+
| 13 | Connection allocation failure on server | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 240-249 | Reserved for Experimental Use | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 250-254 | Reserved for Private Use | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 255 | Reserved | RFC 9946 |
+---------+--------------------------------------------+-----------+
Table 10: Initial Test Setup PDU Command Response Field values Table 11: Initial Values of the Test Setup PDU Command Response
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,
note, value 6 signals that a client erroneously used an authMode value 6 signals that a client erroneously used an authMode that
which hasn't been standardised yet (i.e., authMode greater than 1 or hasn't been standardized yet (i.e., authMode is greater than 1 or 2).
2).
11.3.6. Test Activation PDU Command Request Registry 11.3.6. Test Activation PDU Command Request Registry
IANA will create 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 11. procedures [RFC8126] described in Table 12.
Range(Decimal) Registration Procedures
===============================================================
0-127 IETF Review
128-239 Specification Required
240-249 Experimental
250-254 Private Use
255 Reserved
Table 11: Registration procedures for the Test Activation PDU Command
Request registry
Initially, IANA will assign the decimal values defined by Table 12 in +================+=========================+
the "Test Activation PDU Command Request" registry. | Range(Decimal) | Registration Procedures |
+================+=========================+
| 0-127 | IETF Review |
+----------------+-------------------------+
| 128-239 | Specification Required |
+----------------+-------------------------+
| 240-249 | Experimental Use |
+----------------+-------------------------+
| 250-254 | Private Use |
+----------------+-------------------------+
| 255 | Reserved |
+----------------+-------------------------+
Value Description Reference Table 12: Registration Procedures for
=============================================================== the Test Activation PDU Command Request
0 No Request <this RFC> Registry
1 Request test in Upstream <this RFC> IANA has assigned decimal values in the "Test Activation PDU Command
direction (client to server) Request" registry as follows:
2 Request test in Downstream <this RFC> +=========+==============================+===========+
direction (server to client) | Value | Description | Reference |
+=========+==============================+===========+
| 0 | No Request | RFC 9946 |
+---------+------------------------------+-----------+
| 1 | Request test in upstream | RFC 9946 |
| | direction (client to server) | |
+---------+------------------------------+-----------+
| 2 | Request test in downstream | RFC 9946 |
| | direction (server to client) | |
+---------+------------------------------+-----------+
| 240-249 | Reserved for Experimental | RFC 9946 |
| | Use | |
+---------+------------------------------+-----------+
| 250-254 | Reserved for Private Use | RFC 9946 |
+---------+------------------------------+-----------+
| 255 | Reserved | RFC 9946 |
+---------+------------------------------+-----------+
Table 12: Initial Test Activation PDU Command Request values Table 13: Initial Values of the Test Activation
PDU Command Request Registry
11.3.7. Test Activation PDU Modifier Bitmap Registry 11.3.7. Test Activation PDU Modifier Bitmap Registry
IANA will create 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 13. registration procedures [RFC8126] described in Table 14.
Range(Bitmap) Registration Procedures
===============================================================
00000000-01111111 IETF Review
10000000 Reserved
Table 13: Registration procedures for the Test Activation PDU
Modifier Bitmap registry
Initially, IANA will assign the bitmap values defined by Table 14 in
the "Test Activation PDU Modifier Bitmap" registry.
Value Description Reference +===================+=========================+
=============================================================== | Range(Bitmap) | Registration Procedures |
0x00 No modifications <this RFC> +===================+=========================+
| 00000000-01111111 | IETF Review |
+-------------------+-------------------------+
| 10000000 | Reserved |
+-------------------+-------------------------+
0x01 Set when srIndexConf is <this RFC> Table 14: Registration Procedures for the
start rate for search Test Activation PDU Modifier Bitmap
Registry
0x02 Set for randomized <this RFC> IANA has assigned bitmap values in the "Test Activation PDU Modifier
UDP payload Bitmap" registry as follows:
Table 14: Initial Test Activation PDU Modifier Bitmap values +=======+===============================================+===========+
| Value | Description | Reference |
+=======+===============================================+===========+
| 0x00 | No modifications | RFC 9946 |
+-------+-----------------------------------------------+-----------+
| 0x01 | Set when srIndexConf is | RFC 9946 |
| | start rate for search | |
+-------+-----------------------------------------------+-----------+
| 0x02 | Set for randomized UDP | RFC 9946 |
| | payload | |
+-------+-----------------------------------------------+-----------+
11.3.8. Test Activation PDU Rate Adjustment Algo. Registry Table 15: Initial Values of the Test Activation PDU Modifier
Bitmap Registry
The Test Activation PDU layout contains a rateAdjAlgo field. The 11.3.8. Test Activation PDU Rate Adjustment Algo. Registry
table below defines the assigned Capitalized alphabetic UTF-8 values
in the registry.
IANA will create 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 15. registration procedures [RFC8126] described in Table 16.
Range(Capital alphabet. UTF-8) Registration Procedures
==========================================================
A-Y IETF review
Z Reserved
Table 15: Registration procedures for the Test Activation PDU Rate
Adjustment Algo. registry
Initially, IANA will assign the Capitalized alphabetic UTF-8 values, +=================================+=========================+
as well as the corresponding incremental numeric, defined by Table 16 | Range(Capital alphabet / UTF-8) | Registration Procedures |
in the "Test Activation PDU Rate Adjustment Algo." registry. +=================================+=========================+
| A-Y | IETF Review |
+---------------------------------+-------------------------+
| Z | Reserved |
+---------------------------------+-------------------------+
Value(Numeric) Description Reference Table 16: Registration Procedures for the Test Activation
======================================================== PDU Rate Adjustment Algo. Registry
A(n/a) Not used <this RFC>
B(0) Rate algorithm Type B [Y.1540Amd2] IANA has assigned capitalized alphabetic UTF-8 values, as well as the
corresponding incremental numeric values, in the "Test Activation PDU
Rate Adjustment Algo." registry as follows:
C(1) Rate algorithm Type C [TR-471] +================+=======================+==============+
| Value(Numeric) | Description | Reference |
+================+=======================+==============+
| A(n/a) | Not used | RFC 9946 |
+----------------+-----------------------+--------------+
| B(0) | Rate algorithm Type B | [Y.1540Amd2] |
+----------------+-----------------------+--------------+
| C(1) | Rate algorithm Type C | [TR-471] |
+----------------+-----------------------+--------------+
Table 16: Initial Test Activation PDU Rate Adjustment Algo. values Table 17: Initial Values of the Test Activation PDU
Rate Adjustment Algo. Registry
11.3.9. Test Activation PDU Command Response Field Registry 11.3.9. Test Activation PDU Command Response Field Registry
IANA will create 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 17. registration procedures [RFC8126] described in Table 18.
Range(Decimal) Registration Procedures
===============================================================
0-127 IETF Review
128-239 Specification Required
240-249 Experimental
250-254 Private Use
255 Reserved
Table 17: Registration procedures for the Test Activation PDU Command
Response Field registry
Initially, IANA will assign the decimal values defined by Table 18 in +================+=========================+
the "Test Activation PDU Command Response Field" registry. | Range(Decimal) | Registration Procedures |
+================+=========================+
| 0-127 | IETF Review |
+----------------+-------------------------+
| 128-239 | Specification Required |
+----------------+-------------------------+
| 240-249 | Experimental Use |
+----------------+-------------------------+
| 250-254 | Private Use |
+----------------+-------------------------+
| 255 | Reserved |
+----------------+-------------------------+
Value Description Reference Table 18: Registration Procedures for
=============================================================== the Test Activation PDU Command Response
0 None (used by <this RFC> Field Registry
client in Request)
1 Server Acknowledgment <this RFC> IANA has assigned decimal values in the "Test Activation PDU Command
Response Field" registry as follows:
2 Server indicates an error <this RFC> +=========+==================================+===========+
| Value | Description | Reference |
+=========+==================================+===========+
| 0 | None (used by client in Request) | RFC 9946 |
+---------+----------------------------------+-----------+
| 1 | Server acknowledgment | RFC 9946 |
+---------+----------------------------------+-----------+
| 2 | Server indicates an error | RFC 9946 |
+---------+----------------------------------+-----------+
| 240-249 | Reserved for Experimental Use | RFC 9946 |
+---------+----------------------------------+-----------+
| 250-254 | Reserved for Private Use | RFC 9946 |
+---------+----------------------------------+-----------+
| 255 | Reserved | RFC 9946 |
+---------+----------------------------------+-----------+
Table 18: Initial Test Activation PDU Command Response Field values Table 19: Initial Values of the Test Activation PDU
Command Response Field Registry
11.4. Guidelines for the Designated Experts 11.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. Acknowledgments 12. References
This document was edited by Al Morton, who passed away before being
able to finalize this work. Ruediger Geib only joined later to help
finalize this draft.
Thanks to Lincoln Lavoie, Can Desem, Greg Mirsky, Bjoern Ivar Teigen,
Ken Kerpez and Chen Li for reviewing this draft and providing helpful
suggestions and areas for further development. Mohamed Boucadair's
AD review improved comprehensibility of the document and he further
navigated the document well through the final review stages. Tommy
Pauly shepherded this document. Further comments by Gorry Fairhurst,
Eric Vyncke, Roman Danyliw, Gunter van de Velde, Deb Cooley, Tianran
Zhou, Andy Newton, Giuseppe Fioccola, Lars Eggert, Erik Kline and
Benson Muite helped to shape the document. David Dong and Amanda
Baber provided early reviews of the IANA Considerations section.
Starting with the early SEC-DIR review, Brian Weis provided very
constructive guidance regarding numerous security related protocol
issues. Crypto Forum RG reviewed these parts, again providing
guidance. Magnus Westerlund's review resulted in further changes and
refinements. Ultimately, Paul Wouters' feedback was critical in
finalizing the chosen security approach.
13. References
13.1. Normative References 12.1. Normative References
[C-Prog] ISO/IEC, "ISO/IEC 9899:1999 Programming languages - C", [C-Prog] ISO/IEC, "Programming languages -- C", ISO/IEC 9899:1999,
1999. 1999, <https://www.iso.org/standard/29237.html>.
[NIST800-108] [NIST800-108]
Chen, LC., "Recommendation for Key Derivation Using Chen, L., "Recommendation for Key Derivation Using
Pseudorandom Functions (Revised, Update 1)", August 2022, Pseudorandom Functions",
DOI 10.6028/NIST.SP.800-108r1-upd1, NIST
SP 800-108r1-upd1, August 2022,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-108r1-upd1.pdf>. NIST.SP.800-108r1-upd1.pdf>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
skipping to change at page 66, line 15 skipping to change at line 2994
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>. September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[RFC9097] Morton, A., Geib, R., and L. Ciavattone, "Metrics and [RFC9097] Morton, A., Geib, R., and L. Ciavattone, "Metrics and
Methods for One-Way IP Capacity", RFC 9097, Methods for One-Way IP Capacity", RFC 9097,
DOI 10.17487/RFC9097, November 2021, DOI 10.17487/RFC9097, November 2021,
<https://www.rfc-editor.org/info/rfc9097>. <https://www.rfc-editor.org/info/rfc9097>.
[TR-471] Morton, A,, Editor., "Broadband Forum TR-471: IP Layer [TR-471] Broadband Forum, "Maximum IP-Layer Capacity Metric,
Capacity Metrics and Measurement, Issue 4", September Related Metrics, and Measurements", TR-471, Issue 4,
2024, <https://www.broadband-forum.org/technical/download/ September 2024,
TR-471.pdf>. <https://www.broadband-forum.org/pdfs/tr-471-4-0-0.pdf>.
[Y.1540] ITU-T, "Internet protocol data communication service - IP [Y.1540] ITU-T, "Internet protocol data communication service - IP
packet transfer and availability performance parameters", packet transfer and availability performance parameters",
ITU-T Recommendation Y.1540, December 2019, ITU-T Recommendation Y.1540, December 2019,
<https://www.itu.int/rec/T-REC-Y.1540-201912-I/en>. <https://www.itu.int/rec/T-REC-Y.1540-201912-I/en>.
[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, <https://www.itu.int/rec/T-REC-Y.1540-201912-I/en>. 2023,
<https://www.itu.int/rec/T-REC-Y.1540-202303-I!Amd2/en>.
13.2. Informative References 12.2. Informative References
[EVP_KDF-KB] [EVP_KDF-KB]
"The Key-Based EVP_KDF implementation", "EVP_KDF-KB - The Key-Based EVP_KDF implementation",
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>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
skipping to change at page 69, line 22 skipping to change at line 3148
// Cleanup // Cleanup
// //
EVP_KDF_CTX_free(kctx); EVP_KDF_CTX_free(kctx);
EVP_KDF_free(kdf); EVP_KDF_free(kdf);
return 1; return 1;
} }
<CODE ENDS> <CODE ENDS>
Figure 12: KDF Example Code Snippet Figure 12: KDF Example Code Snippet
Acknowledgments
This document was edited by Al Morton, who passed away before being
able to finalize this work. Ruediger Geib only joined later to help
finalize this specification.
Thanks to Lincoln Lavoie, Can Desem, Greg Mirsky, Bjoern Ivar Teigen,
Ken Kerpez, and Chen Li for reviewing this specification and
providing helpful suggestions and areas for further development.
Mohamed Boucadair's AD review improved comprehensibility of the
document, and he further navigated the document well through the
final review stages. Tommy Pauly shepherded this document. Further
comments by Gorry Fairhurst, Éric Vyncke, Roman Danyliw, Gunter Van
de Velde, Deb Cooley, Tianran Zhou, Andy Newton, Giuseppe Fioccola,
Lars Eggert, Erik Kline, and Benson Muite helped to shape the
document. David Dong and Amanda Baber provided early reviews of the
IANA Considerations section.
Starting with the early SEC-DIR review, Brian Weis provided
constructive guidance regarding numerous security-related protocol
issues. The Crypto Forum Research Group reviewed these parts, again
providing guidance. Magnus Westerlund's review resulted in further
changes and refinements. Ultimately, Paul Wouters' feedback was
critical in finalizing the chosen security approach.
Authors' Addresses Authors' Addresses
Al Morton
Len Ciavattone Len Ciavattone
AT&T Labs AT&T Labs
Middletown, NJ Middletown, NJ
United States of America United States of America
Email: lenciavattone@gmail.com Email: lenciavattone@gmail.com
Ruediger Geib Ruediger Geib (editor)
Deutsche Telekom Deutsche Telekom
Deutsche Telekom Allee 9 Deutsche Telekom Allee 9
64295 Darmstadt 64295 Darmstadt
Germany Germany
Phone: +49 6151 5812747 Phone: +49 6151 5812747
Email: Ruediger.Geib@telekom.de Email: Ruediger.Geib@telekom.de
 End of changes. 355 change blocks. 
1034 lines changed or deleted 1110 lines changed or added

This html diff was produced by rfcdiff 1.48.