rfc9946xml2.original.xml   rfc9946.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE fc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-ippm-capacity-protocol-25"
ipr="trust200902" updates="">
<front>
<title abbrev="Test Protocol: IP Capacity Measurement">UDP Speed Test
Protocol for One-way IP Capacity Metric Measurement</title>
<author fullname="Len Ciavattone" initials="L." surname="Ciavattone"> <!DOCTYPE rfc [
<organization>AT&amp;T Labs</organization> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<address> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" consensus="true" category="std"
<postal> docName="draft-ietf-ippm-capacity-protocol-25" number="9946" ipr="trust200902" u
<street/> pdates="" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" toc
Depth="3" symRefs="true" sortRefs="true" version="3">
<city>Middletown</city> <front>
<title abbrev="Test Protocol: IP Capacity Measurement">The UDP Speed Test
Protocol for One-Way IP Capacity Metric Measurement</title>
<seriesInfo name="RFC" value="9946"/>
<region>NJ</region> <!--[rfced] *AD, per your request and the request of the WG, we have
added Al Morton as an author of this document. We have also added
the role of "editor" for Geib Ruediger. Please let us know if Al
should have an affiliation listed.
<code/> Note that when this document has completed AUTH48, we will ask you
to approve it on behalf of Al.
<country>USA</country> Current Authors (header):
</postal> A. Morton
<phone/> L. Ciavattone
AT&T Labs
<facsimile/> R. Geib, Ed.
Deutsche Telekom
-->
<author fullname="Al Morton" initials="A." surname="Morton">
<organization>AT&amp;T Labs</organization>
<address>
<postal>
<city></city>
<region></region>
<country></country>
</postal>
<email></email>
</address>
</author>
<author fullname="Len Ciavattone" initials="L." surname="Ciavattone">
<organization>AT&amp;T Labs</organization>
<address>
<postal>
<city>Middletown</city>
<region>NJ</region>
<country>United States of America</country>
</postal>
<email>lenciavattone@gmail.com</email> <email>lenciavattone@gmail.com</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Ruediger Geib" initials="R." surname="Geib" role="editor">
<author fullname="Ruediger Geib" initials="R." surname="Geib">
<organization>Deutsche Telekom</organization> <organization>Deutsche Telekom</organization>
<address> <address>
<postal> <postal>
<street>Deutsche Telekom Allee 9</street> <street>Deutsche Telekom Allee 9</street>
<!-- Reorder these if your country does things differently -->
<code>64295</code> <code>64295</code>
<city>Darmstadt</city> <city>Darmstadt</city>
<region/>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone>+49 6151 5812747</phone> <phone>+49 6151 5812747</phone>
<email>Ruediger.Geib@telekom.de</email> <email>Ruediger.Geib@telekom.de</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<!-- <author fullname="Al Morton" initials="A." surname="Morton"> <date year="2026" month="March"/>
<organization>AT&amp;T Labs</organization>
<address>
<postal>
<street/>
<city>Chicago</city>
<region>IL</region>
<code>60660</code> <area>OPS</area>
<workgroup>ippm</workgroup>
<country>USA</country> <!-- [rfced] Please insert any keywords (beyond those that appear in
</postal> the title) for use on https://www.rfc-editor.org/search.
-->
<phone/> <abstract>
<t>This document addresses the problem of protocol support for measuring
One-Way IP Capacity metrics specified by RFC 9097. The Method of
Measurement discussed in that RFC requires a feedback channel from the
receiver to control the sender's transmission rate in near real-time.
<facsimile/> <!--[rfced] Does "conducting RFC 9097 and other related measurements"
mean "conducting measurements as described in RFC 9097 and other
related measurements"? Please let us know how we may update for
clarity.
<email>acmorton@att.com</email> Original:
This document defines the UDP Speed Test Protocol (UDPSTP) for
conducting RFC 9097 and other related measurements.
<uri/> Perhaps:
</address> This document defines the UDP Speed Test Protocol (UDPSTP) for
</author> conducting measurements as described in RFC 9097 and other
related measurements.
--> -->
<date year="2025"/> This document defines the UDP Speed Test Protocol (UDPSTP) for conducting
RFC
<abstract>
<t>This document addresses the problem of protocol support for measuring
One-Way IP Capacity metrics specified by RFC 9097. The Method of
Measurement discussed there requires a feedback channel from the
receiver to control the sender's transmission rate in near-real-time.
This document defines the UDP Speed Test Protocol for conducting RFC
9097 and other related measurements.</t> 9097 and other related measurements.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>The performance community has seen development of Informative Bulk <name>Introduction</name>
Transport Capacity definitions in the "Framework for Bulk Transport
Capacity" (BTC, see <xref target="RFC3148"/>) and for "Network Capacity
and Maximum IP-layer Capacity" <xref target="RFC5136"/>. "Model-Based
Metrics for BTC" add experimental metric definitions and methods in
<xref target="RFC8337"/>.</t>
<t>This document specifies the UDP Speed Test Protocol (UDPSTP) enabling <!-- [rfced] We are unsure if the quoted text was intended to be the
the measurement of One-Way IP Capacity metrics as defined by <xref titles of or concepts in the RFCs listed. Since quote marks were
target="RFC9097"/>. The Method of Measurement discussed there deploys a present, we updated the text to reflect the exact titles of the
RFCs. Please let us know if this is agreeable or if you prefer
otherwise.
Original:
The performance community has seen development of Informative Bulk
Transport Capacity definitions in the "Framework for Bulk Transport
Capacity" (BTC, see [RFC3148]) and for "Network Capacity and Maximum
IP-layer Capacity" [RFC5136]. "Model-Based Metrics for BTC" add
experimental metric definitions and methods in [RFC8337].
Current:
The performance community has seen the development of Informative
Bulk Transport Capacity (BTC) definitions in "A Framework for
Defining Empirical Bulk Transfer Capacity Metrics" [RFC3148] and
"Defining Network Capacity" [RFC5136] as well as experimental
metric definitions and methods in "Model-Based Metrics for Bulk
Transport Capacity" [RFC8337].
-->
<t>The performance community has seen the development of Informative Bulk
Transport Capacity (BTC) definitions in "A Framework for Defining Empirica
l Bulk Transfer
Capacity Metrics" <xref target="RFC3148" format="default"/> and "Defining
Network Capacity" <xref target="RFC5136" format="default"/> as well as experimen
tal metric definitions and methods in "Model-Based Metrics for Bulk Transport Ca
pacity" <xref target="RFC8337" format="default"/>.</t>
<t>This document specifies the UDP Speed Test Protocol (UDPSTP) to enable
the measurement of One-Way IP Capacity metrics as defined by <xref target=
"RFC9097" format="default"/>. The Method of Measurement discussed in that RFC de
ploys a
feedback channel from the receiver to control the sender's transmission feedback channel from the receiver to control the sender's transmission
rate in near-real-time. Section 8.1 of <xref target="RFC9097"/> rate in near real-time. <xref target="RFC9097" section="8.1"/>
specifies requirements for this method.</t> specifies requirements for this method.</t>
<t>This protocol supports measurement features which weren't available <t>UDPSTP supports measurement features that weren't available
by TCP based speed tests and standard measurement protocols like One Way via TCP-based speed tests and standard measurement protocols, such as the
Active Measurement Protocol (OWAMP) <xref target="RFC4656"/>, Two-Way One-Way
Active Measurement Protocol (TWAMP) <xref target="RFC5357"/> and Simple Active Measurement Protocol (OWAMP) <xref target="RFC4656" format="default
Two-Way Active Measurement Protocol (STAMP) <xref target="RFC8762"/> "/>, Two-Way
Active Measurement Protocol (TWAMP) <xref target="RFC5357" format="default
"/>, and Simple
Two-Way Active Measurement Protocol (STAMP) <xref target="RFC8762" format=
"default"/>,
prior to this work. The controlled Bulk Capacity measurement or Speed prior to this work. The controlled Bulk Capacity measurement or Speed
Test, respectively, is based on UDP rather than TCP. The bulk Test, respectively, is based on UDP rather than TCP. The bulk
measurement load is unidirectional. These specifications did support measurement load is unidirectional. These specifications did support
creation of asymmetric traffic in combination with some two-way the creation of asymmetric traffic in combination with some two-way
communication, as supported by TWAMP and STAMP, when work on UDPSTP communication, as supported by TWAMP and STAMP, when work on UDPSTP
started. Further, two-way communications of TWAMP and STAMP are limited started. Further, two-way communications of TWAMP and STAMP are limited
to reflection or unidirectional load properties, but lack support for to reflection or unidirectional load properties, but they lack support for
closed loop feedback operation. The latter enables limiting congestion closed loop feedback operation. The latter enables limiting congestion
of a bottleneck, whose capacity is measured, to a short time range. of a bottleneck, whose capacity is measured, to a short time range.
Support of such a control loop is the main purpose of UDPSTP.</t> Support of such a control loop is the main purpose of UDPSTP.</t>
<t>Apart from measurement functionality, a Key Derivation Function (KDF) h
<t>Apart from measurement functionality, a Key Derivation Function has as
been added providing cryptographic separation of key material for been added to provide cryptographic separation of key material for
authentication of protocol messages in a standardized and authentication of protocol messages in a standardized and
cryptographically secure manner. This is a secondary improvement reached cryptographically secure manner. This is a secondary improvement reached
by UDPSTP and may simplify its reuse for other measurement purposes. by UDPSTP and may simplify its reuse for other measurement purposes.
Additionally, because the protocol uses synthetic payload data and Additionally, because the protocol uses synthetic payload data and
contains no direct user information, a decision was made to forgo contains no direct user information, a decision was made to forgo
encryption support. Secondarily, this is also expected to increase the encryption support. Secondarily, this is also expected to increase the
number of low-end devices that can support the test methodology.</t> number of low-end devices that can support the test methodology.</t>
<section numbered="true" toc="default">
<name>Terminology</name>
<section title="Terminology"> <dl spacing="normal" newline="false">
<t>Downstream UDP Speed Test: A client initiated Network Capacity <dt>Downstream UDP Speed Test:</dt><dd>A client-initiated Network Capaci
ty
measurement between a server acting as sender and a client acting as measurement between a server acting as sender and a client acting as
receiver.</t> receiver.</dd>
<dt>Upstream UDP Speed Test:</dt><dd>A client-initiated Network Capacity
<t>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 as
receiver.</t> receiver.</dd>
</dl>
</section> </section>
<!-- This statement may be removed by the RFC editor --> <section numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119"/>, <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section> </section>
</section> </section>
<section anchor="applicablity" numbered="true" toc="default">
<section anchor="applicablity" title="Scope, Goals, and Applicability"> <name>Scope, Goals, and Applicability</name>
<t>The scope of this document is to define a protocol to measure the <t>The scope of this document is to define a protocol to measure the
Maximum IP-Layer Capacity metric according to the Method of Measurement Maximum IP-Layer Capacity Metric according to the Method of Measurement
standardized by Section 8 of <xref target="RFC9097"/>. As such, this standardized by <xref target="RFC9097" section="8"/>. As such, this
document adheres to the applicability scope defined in Section 2 of document adheres to the applicability scope defined in
<xref target="RFC9097"/>.</t> <xref target="RFC9097" section="2"/>.</t>
<t>Some aspects of this protocol and end-host configuration can lead to <t>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 algorithm. emulation enabled by creative use of the load rate adjustment algorithm.
Per <xref target="RFC9097"/>, that algorithm must not be used as a Per <xref target="RFC9097" format="default"/>, 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.</t> measurement.</t>
<t>The goal is to harmonize the specified IP-Layer Capacity Metric and
<t>The goal is to harmonize the specified IP-Layer Capacity metric and Method across the industry, and this protocol supports the
method across the industry, and this protocol supports the specifications of IETF (see <xref target="RFC9097" format="default"/>) and
specifications of IETF (<xref target="RFC9097"/>) and other Standards other Standards
Development Organizations (SDO's; see, e.g., <xref Development Organizations (SDOs) (see, e.g., <xref target="TR-471" format=
target="TR-471"/>).</t> "default"/>).</t>
<t>The primary application of the protocol described here is the same as <t>The primary application of the protocol described here is the same as
in Section 2 of <xref target="RFC7497"/> where:</t> in <xref target="RFC7497" section="2"/> where:</t>
<t><list style="symbols"> <blockquote>
<t>The access portion of the network is the focus of this problem <t>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 bidirectional access partly described by rates in bits per
second.</t> second.</t>
</list></t> </blockquote>
<t>UDPSTP is a client-based protocol. It may be applied by consumers to <t>UDPSTP is a client-based protocol. It may be applied by consumers to
measure their own access bandwidth. Consumers may prefer an independent measure their own access bandwidth. Consumers may prefer an independent
3rd party domain hosting the measurement server for this purpose. UDPSTP third-party domain hosting the measurement server for this purpose.
may be deployed in Large-Scale Measurement of Broadband Performance
environments (LMAP, see <xref target="RFC7497"/>), another independent <!--[rfced] FYI - We made "LMAP environments" singular to agree with
3rd party domain measurement server deployment. A network operator may "another independent third-party domain measurement server
deployment" as shown below. Please let us know of any objections.
Original:
UDPSTP may be deployed in Large-Scale Measurement of Broadband
Performance environments (LMAP, see [RFC7497]), another independent
3rd party domain measurement server deployment.
Current:
UDPSTP may be deployed in a Large-scale Measurement of Broadband
Performance (LMAP) environment (see [RFC7497]), another independent
third-party domain measurement server deployment.
-->
UDPSTP
may be deployed in a Large-scale Measurement of Broadband Performance (LMA
P)
environment (see <xref target="RFC7497" format="default"/>), another indep
endent
third-party domain measurement server deployment. A network operator may
support operation and maintenance by UDPSTP, a typical intra-domain support operation and maintenance by UDPSTP, a typical intra-domain
deployment. All these deployments require or benefit from trust into the deployment.
results, which are ensured by authenticated communication.</t>
</section>
<section title="Protocol Overview"> <!--[rfced] Please clarify "benefit from trust into the results". Is
<t>All messages defined by this document SHALL use UDP transport.</t> the intended meaning perhaps "benefit from trusting the results"?
Original:
All these deployments require or benefit from trust into the
results, which are ensured by authenticated communication.
Perhaps:
All these deployments require or benefit from trusting the
results, which are ensured by authenticated communication.
-->
All these deployments require or benefit from trust into the
results, which are ensured by authenticated communication.</t>
</section>
<section numbered="true" toc="default">
<name>Protocol Overview</name>
<t>All messages defined by this document <bcp14>SHALL</bcp14> use UDP tran
sport.</t>
<t>The remainder of this section gives an informative overview of the <t>The remainder of this section gives an informative overview of the
communication protocol between two test endpoints (without expressing communication protocol between two test endpoints (without expressing
requirements or elaborating on the authentication aspects).</t> requirements or elaborating on the authentication aspects).</t>
<t>One endpoint takes the role of server, listening for connection <t>One endpoint takes the role of server, listening for connection
requests on a standard UDP Speed Test Protocol port number from the requests on a standard UDP Speed Test Protocol port number from the
other endpoint, the client.</t> other endpoint, the client.</t>
<t>The client requires configuration of a test direction parameter <t>The client requires configuration of a test direction parameter
(upstream or downstream test, where the client performs the role of (upstream or downstream test, where the client performs the role of
sender or receiver, respectively) as well as the hostname or IP sender or receiver, respectively) as well as the hostname or IP
address(es) of the server(s) in order to begin the setup and address(es) of the server(s) in order to begin the setup and
configuration exchanges with the server(s). By default, the client uses configuration exchanges with the server(s). By default, the client uses
the single, standard UDPSTP port number per connection (see <xref the single, standard UDPSTP port number per connection (see <xref target="
target="Test-Setup"/>). If the default port number is not used, the Test-Setup" format="default"/>). If the default port number is not used, the
client may require configuration of the control port number used by each client may require configuration of the control port number used by each
server. This would be the case if multiple server instances (processes) server. This would be the case if multiple server instances (processes)
operate on one or more machines.</t> operate on one or more machines.</t>
<t>Additionally, multi-connection (multi-flow) testing is supported by <t>Additionally, multi-connection (multi-flow) testing is supported by
the protocol. Each connection is independent and attempts to maximize the protocol. Each connection is independent and attempts to maximize
its own individual traffic rate. For multi-connection tests, a single its own individual traffic rate. For multi-connection tests, a single
client process would replicate the connection setup and test procedure client process would replicate the connection setup and test procedure
multiple times (once for each flow) to one or more server instances. The multiple times (once for each flow) to one or more server instances. The
server instance(s) would process each connection independently, as if server instance(s) would process each connection independently, as if
they were coming from separate clients. It shall be the responsibility they were coming from separate clients. It shall be the responsibility
of the client process to manage the inter-related connections: handling of the client process to manage the inter-related connections such as hand ling
the individual connection setup successes and failures, cleaning up the individual connection setup successes and failures, cleaning up
connections during a test (should some fail) as well as aggregate the connections during a test (should some fail), and aggregating the
individual test results into an overall set of performance statistics. individual test results into an overall set of performance statistics.
Fields in the Setup Request (mcIndex, mcCount, and mcIdent, see <xref
target="Client-Gen-Activation"/>) are used to both differentiate and
associate the multiple connections that comprise a single test.</t>
<t>The protocol uses UDP transport <xref target="RFC0768"/> with two <!--[rfced] We don't see the terms "mcIndex", "mcCount", and "mcIdent" in
connection phases (Control and Data). The exchanges 1 and 2 (see below) Section 6.1. Was Section 5.1 perhaps intended?
Original:
Fields in the Setup Request (mcIndex, mcCount, and mcIdent, see
Section 6.1) are used to both differentiate and associate the
multiple connections that comprise a single test.
Perhaps:
Fields in the Setup Request (i.e., mcIndex, mcCount, and mcIdent;
see Section 5.1) are used to both differentiate and associate the
multiple connections that comprise a single test.
-->
Fields in the Setup Request (i.e., mcIndex, mcCount, and mcIdent; see <xre
f target="Client-Gen-Activation" format="default"/>) are used to both differenti
ate and
associate the multiple connections that comprise a single test.</t>
<t>The protocol uses UDP transport <xref target="RFC0768" format="default"
/> with two
connection phases (Control and Data). As shown below, exchanges 1 and 2
constitute the Control phase, while exchanges 3 and 4 constitute the constitute the Control phase, while exchanges 3 and 4 constitute the
Data phase. In this document, the term message and the term Protocol Data phase. In this document, the term "message" and the term "Protocol
Data Unit, or PDU (<xref target="RFC5044"/>) are used Data Unit", or "PDU" <xref target="RFC5044" format="default"/>, are used
interchangeably.</t> interchangeably.</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers">
<t>Test Setup Request and Response: If a server instance is <t>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 left IPv6. Thus, the decision on the preferred IP address family is left
to the name resolver's default behavior. Support for separate IPv4 to the name resolver's default behavior. Support for separate IPv4
and IPv6 measurements or an IPv4 and IPv6 multi connection setup are and IPv6 measurements or an IPv4 and IPv6 multi-connection setup are
left for future improvement. The client then requests to begin a left for future improvement. The client then requests to begin a
test by communicating its UDPSTP protocol version, intended security test by communicating its UDPSTP protocol version, intended security
mode, and datagram size support. The server either confirms matching mode, and datagram size support. The server either confirms matching
a configuration or rejects the connection request. If the request is a configuration or rejects the connection request. If the request is
accepted, the server provides a unique ephemeral port number for accepted, the server provides a unique ephemeral port number for
each test connection, allowing further communication. In a each test connection, allowing further communication. In a
multi-connection setup, distinct UDP port numbers may be assigned multi-connection setup, distinct UDP port numbers may be assigned
with each Setup Response from a server instance. Distinct UDP port with 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.</t> from the same server in that case.</t>
</li>
<li>
<t>Test Activation Request and Response: After having received a <t>Test Activation Request and Response: After having received a
confirmation of the configuration by a server, the client composes a confirmation of the configuration by a server, the client composes a
request conveying parameters such as the testing direction, the request conveying parameters such as the testing direction, the
duration of the test interval and test sub-intervals, and various duration of the test interval and test sub-intervals, and various
thresholds (for a detailed discussion, see <xref target="RFC9097"/> thresholds (for a detailed discussion, see <xref target="RFC9097" form
and <xref target="TR-471"/>). The server then chooses to accept, at="default"/>
ignore or modify any of the test parameters, and communicates the and <xref target="TR-471" format="default"/>). The server then chooses
to accept,
ignore, or modify any of the test parameters and communicates the
set that will be used unless the client rejects the modifications. set that will be used unless the client rejects the modifications.
Note that the client assumes that the Test Activation exchange has Note that the client assumes that the Test Activation exchange has
opened any co-located firewalls and network address/port translators opened any co-located firewalls and network address/port translators
for the test connection (in response to the Request packet on the for the test connection (in response to the Request packet on the
ephemeral port number) and the traffic that follows. See <xref ephemeral port number) and the traffic that follows. See <xref target=
target="RFC9097"/> for a more detailed discussion of firewall and "RFC9097" format="default"/> for a more detailed discussion of firewall and
NAT related features. If the Test Activation Request is rejected or NAT-related features. If the Test Activation Request is rejected or
fails, the client assumes that the firewall will close the fails, the client assumes that the firewall will close the
address/port number pinhole entry after the firewall's configured address/port number pinhole entry after the firewall's configured
idle traffic timeout.</t> idle traffic timeout.</t>
</li>
<li>
<t>Test Stream Transmission and Measurement Feedback Messages: <t>Test Stream Transmission and Measurement Feedback Messages:
Testing proceeds with one endpoint sending Load PDUs and the other Testing proceeds with one endpoint sending the Load PDUs and the other
endpoint receiving the Load PDUs and sending frequent status endpoint receiving the Load PDUs and sending frequent status
messages to communicate status and reception conditions there. The messages to communicate the status and reception conditions. The
data in the feedback messages, whether received from the client or data in the feedback messages, whether received from the client or
when being sent to the client, is input to a load rate adjustment when being sent to the client, is input to a load rate adjustment
algorithm at the server which controls future sending rates at algorithm at the server, which controls future sending rates at
either end. The choice to locate the load rate adjustment algorithm either end. The choice to locate the load rate adjustment algorithm
at the server, regardless of transmission direction, means that the at the server, regardless of transmission direction, means that the
algorithm can be updated more easily at a host within the network, algorithm can be updated more easily at a host within the network
and at a fewer number of hosts than the number of clients. Note that and at a fewer number of hosts than the number of clients. Note that
the status messages also help keep the pinhole (or mapping, the status messages also help keep the pinhole (or mapping,
respecitvely) active at on-path stateful devices. UDPSTP is at least respectively) active at on-path stateful devices. UDPSTP is at least
partially compliant to section 3.1 of <xref target="RFC8085"/>: if partially compliant to <xref target="RFC8085" section="3.1"/> if
the bottleneck is congested, but pending congestion is avoided by the bottleneck is congested, but pending congestion is avoided by
limiting the duration of that congestion to the minimum required to limiting the duration of that congestion to the minimum required to
determine the bottleneck capacity.</t> determine the bottleneck capacity.</t>
</li>
<li>
<t>Stopping the Test: When the specified test duration has been <t>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 it Feedback messages. After being received, the client acknowledges it
by also setting a STOP indication in its outgoing Load PDUs or by also setting a STOP indication in its outgoing Load PDUs or
Status Feedback messages. A graceful connection termination at each Status Feedback messages. A graceful connection termination at each
end then follows. Since the Load PDUs and Status Feedback messages end then follows. Since the Load PDUs and Status Feedback messages
are used, this exchange is considered a sub-exchange of 3. If the are used, this exchange is considered a sub-exchange of 3 above. If th
Test traffic stops or the communication path fails, the client e
test traffic stops or the communication path fails, the client
assumes that the firewall will close the address/port number assumes that the firewall will close the address/port number
combination after the firewall's configured idle traffic combination after the firewall's configured idle traffic
timeout.</t> timeout.</t>
</li>
<li>
<t>Both the client and server react to unexpected interruptions in <t>Both the client and server react to unexpected interruptions in
the Control or Data phase, respectively. Watchdog timers limit the the Control or Data phase, respectively. Watchdog timers limit the
time a server or client will wait before stopping all traffic and time a server or client will wait before stopping all traffic and
terminating a test.</t> terminating a test.</t>
</list></t> </li>
</ol>
<t><xref target="MessageExchange"/> provides an example exchange of <t><xref target="MessageExchange" format="default"/> provides an example e
control and measurement PDUs for both a downstream and upstream UDP xchange of
control and measurement PDUs for both downstream and upstream UDP
Speed Tests (always client initiated):</t> Speed Tests (always client initiated):</t>
<figure anchor="MessageExchange">
<t><figure anchor="MessageExchange" <name>Successful UDPSTP Message Exchanges</name>
title="Successful UDPSTP Message Exchanges"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
=========== Downstream Test =========== =========== Downstream Test ===========
+---------+ +---------+ +---------+ +---------+
| Client | Test Setup Request -----&gt; | Server | | Client | Test Setup Request -----> | Server |
+---------+ +---------+ +---------+ +---------+
&lt;----- Test Setup Response (Accept) <----- Test Setup Response (Accept)
&lt;----- Null Request PDU <----- Null Request PDU
Test Activation Request -----&gt; Test Activation Request ----->
&lt;----- Test Activation Response (Accept) <----- Test Activation Response (Accept)
&lt;----- Load PDUs <----- Load PDUs
Status Feedback PDUs -----&gt; Status Feedback PDUs ----->
After expiry of server's test duration timer... After expiry of server's test duration timer...
&lt;----- Load PDU (TEST_ACT_STOP) <----- Load PDU (TEST_ACT_STOP)
Status Feedback PDU (TEST_ACT_STOP) -----&gt; Status Feedback PDU (TEST_ACT_STOP) ----->
============ Upstream Test ============ ============ Upstream Test ============
+---------+ +---------+ +---------+ +---------+
| Client | Test Setup Request -----&gt; | Server | | Client | Test Setup Request -----> | Server |
+---------+ +---------+ +---------+ +---------+
&lt;----- Test Setup Response (Accept) <----- Test Setup Response (Accept)
&lt;----- Null Request PDU <----- Null Request PDU
Test Activation Request -----&gt; Test Activation Request ----->
&lt;----- Test Activation Response (Accept) <----- Test Activation Response (Accept)
Load PDUs -----&gt; Load PDUs ----->
&lt;----- Status Feedback PDUs <----- Status Feedback PDUs
After expiry of server's test duration timer... After expiry of server's test duration timer...
&lt;----- Status Feedback PDU (TEST_ACT_STOP) <----- Status Feedback PDU (TEST_ACT_STOP)
Load PDU (TEST_ACT_STOP) -----&gt;
</artwork>
<postamble/> Load PDU (TEST_ACT_STOP) ----->]]></artwork>
</figure></t> </figure>
<section anchor="Fixed-Rate" title="Fixed-Rate Testing"> <section anchor="Fixed-Rate" numbered="true" toc="default">
<name>Fixed-Rate Testing</name>
<t>A network operator who is certain of the IP-Layer Capacity to be <t>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 <xref target="RFC9097"/>). Fixed-rate testing SHOULD <xref target="RFC9097" section="8.1"/>). Fixed-rate testing <bcp14>SHOUL D</bcp14>
only be activated for operation and maintenance purposes by operators only be activated for operation and maintenance purposes by operators
within their local network domain.</t> within their local network domain.</t>
<t>If a subscriber requests a diagnostic test from the network <t>If a subscriber requests a diagnostic test from the network
operator, this strongly implies that there is no certainty on the operator, it strongly implies that there is no certainty on the
bottleneck capacity and initiating a UDP Speed Test based on the load bottleneck capacity and initiating a UDP Speed Test based on the load
adjustment algorithm is RECOMMENDED. To protect against misuse, a adjustment algorithm is <bcp14>RECOMMENDED</bcp14>. To protect against m
client (and in general, a consumer) MUST NOT be able to initiate a isuse, a
client (and in general, a consumer) <bcp14>MUST NOT</bcp14> be able to i
nitiate a
fixed-rate test. A network operator may conduct a fixed-rate test for fixed-rate test. A network operator may conduct a fixed-rate test for
a stable measurement at or near the maximum determined by the load a stable measurement at or near the maximum determined by the load
rate adjustment algorithm for debugging purposes. This may be valuable rate adjustment algorithm for debugging purposes. This may be valuable
for post-installation or post-repair verification.</t> for post-installation or post-repair verification.</t>
</section> </section>
<section anchor="Congestion" numbered="true" toc="default">
<section anchor="Congestion" <name>Handling of and Safeguards Required by Self-Induced Congestion</na
title="Handling of and Safeguards required by Self-Induced Conges me>
tion">
<t>Active capacity measurement requires inducing intentional <t>Active capacity measurement requires inducing intentional
congestion. On paths where the capacity bottleneck is not shared with congestion. On paths where the capacity bottleneck is not shared with
other flows, this self-congestion will be observed as loss and/or other flows, this self-congestion will be observed as loss and/or
delay. However, when a path is shared by other flows, the measurment delay. However, when a path is shared by other flows, the measurement
traffic can congest the bottleneck on the path and therefore can traffic can congest the bottleneck on the path and therefore
degrade the performance of other flows. Unrestricted use of the tool degrade the performance of other flows. Unrestricted use of the tool
could lead to traffic starvation and significant issues.</t> could lead to traffic starvation and significant issues.</t>
<t>Measurements that generate traffic on shared paths (including Wi-Fi
<t>Measurements that generate traffic on shared paths (including WiFi
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-rate must not be executed over other operators' network segments. Fixed-rate
testing therefore is limited to paths within a domain entirely managed testing, therefore, is limited to paths within a domain entirely managed
and operated section-wise and end-to-end by the network operator and operated section-wise and end-to-end by the network operator
performing the measurement. When the risks of disruption to other performing the measurement. When the risks of disruption to other
flows has been considered, testing could be extended to include 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.</t> agreement.</t>
<t>Concurrent tests that congest a common bottleneck will impair the <t>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.</t> path <bcp14>SHALL</bcp14> be limited to one, regardless of the number of
flows.</t>
<t>A load rate adjustment algorithm (see section 4.1) is required to <t>A load rate adjustment algorithm (see <xref target="LoadRateAlgoReqs"
/>) 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.</t> loss of connectivity is detected.</t>
</section> </section>
</section> </section>
<section anchor="Security-Checksum" <!--[rfced] Is there only one optional checksum or would it be correct
title="Requirements, Security Operations, and Optional Checksum"> to make checksum plural in the title of Section 4 (for
<t>Security and checksum operation aren't covered by <xref consistency with "Requirements" and "Security Operations") as well
target="RFC9097"/>, which only defines the Method of Measurement. This as in one sentence in Section 4?
Original:
Section 4. Requirements, Security Operations, and Optional Checksum
This section adds the operational specification related to security
and optional checksum.
Perhaps:
Section 4. Requirements, Security Operations, and Optional Checksums
This section adds the operational specification related to security
and optional checksums.
-->
<section anchor="Security-Checksum" numbered="true" toc="default">
<name>Requirements, Security Operations, and Optional Checksum</name>
<t>Security and checksum operations aren't covered by <xref target="RFC909
7" format="default"/>, which only defines the Method of Measurement. This
section adds the operational specification related to security and section adds the operational specification related to security and
optional checksum. Due to the additional complexities, and loss of the optional checksum.
<!--[rfced] In order to avoid hyphenating "Layer-3-to-Layer-4 mapping",
may we rephrase this sentence as shown below?
Original:
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 3 fragmentation be avoided.
Perhaps:
Due to the additional complexities, and loss of the direct
mapping of packets to datagrams between Layer 3 and Layer 4,
it is recommended that Layer 3 fragmentation be avoided.
-->
Due to the additional complexities, and loss of the
direct Layer 3 to Layer 4 mapping of packets to datagrams, it is direct Layer 3 to Layer 4 mapping of packets to datagrams, it is
recommended that Layer 3 fragmentation be avoided. A simplified approach recommended that Layer 3 fragmentation be avoided. A simplified approach
is to choose the default datagram size small enough to prevent is to choose the default datagram size that is small enough to prevent
fragmentation. This version of the specification does not support fragmentation. This version of the specification does not support
Packetization Layer Path MTU Discovery for Datagram Transports Datagram Packetization Layer Path MTU Discovery
(DPLPMTUD) <xref target="RFC8899"/>. A future version could specify how (DPLPMTUD) <xref target="RFC8899" format="default"/>. A future version cou
ld specify how
to support this. DPLPMTUD support will require a carefully adapted to support this. DPLPMTUD support will require a carefully adapted
protocol design to ensure interoperability. Unless IP fragmentation is protocol design to ensure interoperability. Unless IP fragmentation is
expected, and is one of the attributes being measured, the IPv4 DF bit expected, and is one of the attributes being measured, the IPv4 Don't Frag
SHOULD be set for all tests.</t> ment (DF) bit
<bcp14>SHOULD</bcp14> be set for all tests.</t>
<t>Note: When this specification is used for network debugging, it may <t>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.</t> administrator.</t>
<t>This section specifies generic requirements, which a measurement load
<t>This section specifies generic requirements which a measurement load rate adjustment algorithm conforming to this specification <bcp14>MUST</bc
rate adjustment algorithm conforming to this specification MUST p14>
fulfill.</t> fulfill.</t>
<section anchor="LoadRateAlgoReqs" numbered="true" toc="default">
<section anchor="LoadRateAlgoReqs" <name>Load Rate Adjustment Algorithm Requirements</name>
title="Load Rate Adjustment Algorithm Requirements">
<t>This document specifies an active capacity measurement method using <t>This document specifies an active capacity measurement method using
a load rate adjustment algorithm. The requirements following below and a load rate adjustment algorithm. The requirements following below and
the currently standardised load rate adjustment algorithms B <xref the currently standardized load rate adjustment algorithms B <xref targe
target="Y.1540Amd2"/> and C <xref target="TR-471"/> result from years t="Y.1540Amd2" format="default"/> and C <xref target="TR-471" format="default"/>
result from years
of experiments and testing by the original authors. These tests were of experiments and testing by the original authors. These tests were
performed in Labs, but also in the Internet and covered a set of performed in labs, and also in the Internet, and covered a set of
different fixed, broadband, mobile and wireless access types and different fixed, broadband, mobile, and wireless access types and
technologies in different countries and continents. Feedback received technologies in different countries and continents.
by performance measurement experts was included, as well as changes
resulting from the standardisation of <xref target="RFC9097"/>
(reflected also in algorithm B <xref target="Y.1540Amd2"/>, which
updates a prior version of this algorithm).</t>
<t>Load rate adjustment algorithms for capacity measurement MUST <!--[rfced] We are having trouble parsing this sentence. Please
comply with the requirements specified by this section. New standard clarify where the feedback received by the experts and the
load rate adjustment algorithms for capacity measurement MUST be changes resulting from standardization were included - was it in
reviewed by IETF designated experts prior to assignment of a codepoint the measurement method or testing?
in the IETF Test Activation PDU Rate Adjustment Algorithm
Registry.</t>
<t>Load rate adjustment algorithm for capacity measurement Original:
requirements:</t> Feedback received by performance measurement experts was included,
as well as changes resulting from the standardisation of [RFC9097]
(reflected also in algorithm B [Y.1540Amd2], which updates a prior
version of this algorithm).
-->
<t><list style="numbers"> Feedback received
by performance measurement experts was included, as well as changes
resulting from the standardization of <xref target="RFC9097" format="def
ault"/>
(reflected also in algorithm B <xref target="Y.1540Amd2" format="default
"/>, which
updates a prior version of this algorithm).</t>
<t>Load rate adjustment algorithms for capacity measurement <bcp14>MUST<
/bcp14>
comply with the requirements specified by this section. New standard
load rate adjustment algorithms for capacity measurement <bcp14>MUST</bc
p14> be
reviewed by IETF designated experts prior to assignment of a code point
in the "Test Activation PDU Rate Adjustment Algorithm"
registry.</t>
<t>The load rate adjustment algorithm for capacity measurement
requirements is as follows:</t>
<ol spacing="normal" type="1">
<li>
<t>The measurement load rate adjustment algorithm described in <t>The measurement load rate adjustment algorithm described in
this section MUST NOT be used as a general Congestion Control this section <bcp14>MUST NOT</bcp14> be used as a general CCA.</t>
Algorithm (CCA).</t> </li>
<li>
<t>This specification MUST only be used in the application of <t>This specification <bcp14>MUST</bcp14> only be used in the applic
ation of
diagnostic and operations measurements.</t> diagnostic and operations measurements.</t>
</li>
<t>Both, Load PDU messages and Status Feedback PDU messages MUST <li>
<t>Both Load PDU messages and Status Feedback PDU messages <bcp14>MU
ST</bcp14>
contain sequence numbers.</t> contain sequence numbers.</t>
</li>
<li>
<t>The nominal duration of a measurement interval at the <t>The nominal duration of a measurement interval at the
Destination, testIntTime (I in <xref target="RFC9097"/>), MUST Destination, parameter testIntTime ("I" in <xref target="RFC9097" fo rmat="default"/>), <bcp14>MUST</bcp14>
default to a value of no more than 10 seconds.</t> default to a value of no more than 10 seconds.</t>
</li>
<t>A high-speed mode to achieve high sending rates quickly MUST <li>
<t>A high-speed mode to achieve high sending rates quickly <bcp14>MU
ST</bcp14>
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 intervals, variation threshold exception in all of the consecutive intervals
indicate "congestion" within a test. The threshold of consecutive indicate "congestion" within a test. The threshold of consecutive
feedback intervals SHALL be configurable with a default of 3 feedback intervals <bcp14>SHALL</bcp14> be configurable with a defau lt of 3
intervals and a maximum duration to infer congestion of 500 intervals and a maximum duration to infer congestion of 500
ms.</t> ms.</t>
</li>
<li>
<t>Congestion <bcp14>MUST</bcp14> be indicated if the Status Feedbac
k PDUs
indicate that either sequence number anomalies were detected OR
the delay range was above the upper delay variation threshold.
<t>Congestion MUST be indicated, if the Status Feedback PDUs <!--[rfced] For clarity, may we update this sentence to contain a
either indicate that sequence number anomalies were detected OR serial list of the threshold values as shown below?
the delay range was above the upper delay variation threshold. The
RECOMMENDED threshold values are 10 for sequence number gaps and Original:
The RECOMMENDED threshold values are 10 for sequence number gaps
and 30 ms for lower and 90 ms for upper delay variation thresholds,
respectively.
Perhaps:
The RECOMMENDED threshold values are 10 for sequence number gaps,
30 ms for lower delay variation thresholds, and 90 ms for upper
delay variation thresholds.
-->
The
<bcp14>RECOMMENDED</bcp14> threshold values are 10 for sequence numb
er gaps and
30 ms for lower and 90 ms for upper delay variation thresholds, 30 ms for lower and 90 ms for upper delay variation thresholds,
respectively.</t> respectively.</t>
</li>
<t>The load rate adjustment algorithm MUST include a Load PDU <li>
timeout and a Status PDU timeout which both stop the test when <t>The load rate adjustment algorithm <bcp14>MUST</bcp14> include a
Load PDU
timeout and a Status PDU timeout, which both stop the test when
received PDU streams cease unexpectedly.</t> received PDU streams cease unexpectedly.</t>
</li>
<t>The Load PDU timeout SHALL be reset to the configured value <li>
<t>The Load PDU timeout <bcp14>SHALL</bcp14> be reset to the configu
red value
each time a Load PDU is received. If the Load PDU timeout expires, each 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 <bcp14>SHALL</bcp14> be closed and no further Status PD
sent. The default Load PDU timeout MUST be no more than 1 sec.</t> U feedback
sent. The default Load PDU timeout <bcp14>MUST</bcp14> be no more th
<t>The Status PDU timeout SHALL be reset to the configured value an 1 second.</t>
</li>
<li>
<t>The Status PDU timeout <bcp14>SHALL</bcp14> be reset to the confi
gured 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 <bcp14>SHALL</bcp14> be closed and no fu
packets sent. The default Status PDU timeout timeout MUST be no rther load
packets sent. The default Status PDU timeout <bcp14>MUST</bcp14> be
no
more than 1 second.</t> more than 1 second.</t>
</li>
<li>
<t>If a network operator is certain of the IP-Layer Capacity to be <!--[rfced] Should this sentence be updated to more closely match
validated, then testing MAY start with a fixed-rate test at the similar wording in Section 3.1? This would also help with how
IP-Layer Capacity and avoid activating the measurement load rate "avoid activating the measurement" relates to the sentence.
adjustment algorithm (see section 8.1 of <xref
target="RFC9097"/>). However, the stimulus for a diagnostic test
(such as a subscriber request) strongly implies that there is no
certainty, and the load adjustment algorithm is RECOMMENDED.</t>
<t>This specification MUST only be used in circumstances Current:
consistent with Section 10 of <xref target="RFC9097"/> ("Security If a network operator is certain of the IP-Layer Capacity to be
Considerations").</t> validated, then testing MAY start with a fixed-rate test at the
IP-Layer Capacity and avoid activating the measurement load rate
adjustment algorithm (see Section 8.1 of [RFC9097])
Perhaps:
A network operator who is certain of the IP-Layer Capacity to be
validated MAY start with a fixed-rate test at the IP-Layer Capacity
and avoid activating the measurement load rate adjustment algorithm
(see Section 8.1 of [RFC9097])
-->
<t>If a network operator is certain of the IP-Layer Capacity to be
validated, then testing <bcp14>MAY</bcp14> start with a fixed-rate t
est at the
IP-Layer Capacity and avoid activating the measurement load rate
adjustment algorithm (see <xref target="RFC9097" section="8.1"/>). H
owever, the stimulus for a diagnostic test
(such as a subscriber request) strongly implies that there is no
certainty, and the load adjustment algorithm is <bcp14>RECOMMENDED</
bcp14>.</t>
</li>
<li>
<t>This specification <bcp14>MUST</bcp14> only be used in circumstan
ces
consistent with Section <xref target="RFC9097" section="10" sectionF
ormat="bare">Security
Considerations</xref> of <xref target="RFC9097"/>.</t>
</li>
<li>
<t>Further measurement load rate adjustment algorithm requirements <t>Further measurement load rate adjustment algorithm requirements
are specified by <xref target="RFC9097"/>.</t> are specified by <xref target="RFC9097" format="default"/>.</t>
</list></t> </li>
</ol>
<t>The following measurement load rate adjustment algorithms are <t>The following measurement load rate adjustment algorithms are
subject to these requirements:</t> subject to these requirements:</t>
<ul spacing="normal">
<t><list style="bullets"> <li>
<t>Measurement load rate adjustment algorithm B <xref <t>Measurement load rate adjustment algorithm B <xref target="Y.1540
target="Y.1540Amd2"/>.</t> Amd2" format="default"/>.</t>
</li>
<t>Measurement load rate adjustment algorithm C <xref <li>
target="TR-471"/>.</t> <t>Measurement load rate adjustment algorithm C <xref target="TR-471
</list></t> " format="default"/>.</t>
</li>
</ul>
</section> </section>
<section numbered="true" toc="default">
<section title="Parameters and Definitions"> <name>Parameters and Definitions</name>
<t>Please refer to Section 4 of <xref target="RFC9097"/> for an <t>Please refer to <xref target="RFC9097" section="4"/> for an
overview of Parameters related to the Maximum IP-Layer Capacity Metric overview of Parameters related to the Maximum IP-Layer Capacity Metric
and Method. A set of error-codes to support debugging are provided in and Method. A set of error codes to support debugging are provided in
<xref target="Error-codes"/>.</t> <xref target="Error-codes" format="default"/>.</t>
</section> </section>
<section anchor="SecurityModes" numbered="true" toc="default">
<section anchor="SecurityModes" title="Security Mode Operations"> <name>Security Mode Operations</name>
<t>There are two security modes of operation that perform <t>There are two security modes of operation that perform
authentication of the client/server messaging. The two modes are:</t> authentication of the client/server messaging. The two modes are:</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>
<t>A REQUIRED mode with authentication during the Control phase <t>A <bcp14>REQUIRED</bcp14> mode with authentication during the Con
trol 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 <xref processing power is a consideration (see <xref target="applicablity"
target="applicablity"/>).</t> format="default"/>).</t>
</li>
<t>An OPTIONAL mode with the additional authentication of the <li>
<t>An <bcp14>OPTIONAL</bcp14> mode with the additional authenticatio
n of the
Status Feedback messages during the Data phase. This mode may be Status 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 <xref message integrity verification throughout the test (see <xref target
target="applicablity"/>).</t> ="applicablity" format="default"/>).</t>
</list></t> </li>
</ol>
<t>The requirements discussed hereafter refer to the PDUs in sections <t>The requirements discussed hereafter refer to the PDUs in Sections
5 and 6 below, primarily the authMode, keyId, authUnixTime, and <xref target="Test-Setup" format="counter"/> and <xref target="Test-Acti
vation" format="counter"/> below, primarily the authMode, keyId, authUnixTime, a
nd
authDigest fields. The roles in this section have been generalized so authDigest fields. The roles in this section have been generalized so
that the requirements for the PDU sender and receiver can be re-used that the requirements for the PDU sender and receiver can be re-used
and referred to by other sections within this document. Each 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 measurements better suited to protect the privacy of those involved in measurements
<xref target="RFC7594"/>.</t> <xref target="RFC7594" format="default"/>.</t>
<t>A load rate adjustment method needs to satisfy the requirements <t>A load rate adjustment method needs to satisfy the requirements
listed in <xref target="LoadRateAlgoReqs"/>. This is necessary also to listed in <xref target="LoadRateAlgoReqs" format="default"/>. This is ne cessary also to
avoid potentially inducing congestion after there is an overload or avoid potentially inducing congestion after there is an overload or
loss (including loss on the control path).</t> loss (including loss on the control path).</t>
<section anchor="Auth-Mode-1" numbered="true" toc="default">
<section anchor="Auth-Mode-1" <name>Mode 1: Required Authenticated Mode</name>
title="Mode 1: Required Authenticated Mode"> <t>In this mode, the client and the server <bcp14>SHALL</bcp14> be con
<t>In this mode, the client and the server SHALL be configured to figured to
use one of a number of shared secret keys, designated via the use one of a number of shared secret keys, designated via the
numeric keyId field (see <xref target="key-management"/>). This key numeric keyId field (see <xref target="key-management" format="default
SHALL be used as input to the KDF (Key Derivation Function), as "/>). This key
specified in <xref target="kdf"/>, to obtain the actual keys used by <bcp14>SHALL</bcp14> be used as input to the KDF, as
specified in <xref target="kdf" format="default"/>, to obtain the actu
al keys used by
the client and server for authentication.</t> the client and server for authentication.</t>
<t>During the Control phase, the sender <bcp14>SHALL</bcp14> read the
<t>During the Control phase, the sender SHALL read the current current
system (wall-clock) time and populate the authUnixTime field and system (wall-clock) time and populate the authUnixTime field
next calculate the 32-octet HMAC-SHA-256 hash of the entire PDU and next calculate the 32-octet HMAC-SHA-256 hash of the entire PDU
according to section 6 of <xref target="RFC6234"/> (with the according to <xref target="RFC6234" section="6"/> (with the
authDigest and checkSum preset to all zeroes). The authDigest field authDigest and checkSum preset to all zeroes). The authDigest field
is filled by the result, then the packet is sent to the receiver. is filled by the result, then the packet is sent to the receiver.
The value in the authUnixTime field is a 32-bit timestamp and a The value in the authUnixTime field is a 32-bit timestamp, and a
10-second tolerance window (+/- 5 seconds) SHALL be used by the 10-second tolerance window (+/- 5 seconds) <bcp14>SHALL</bcp14> be use
d by the
receiver to distinguish a subsequent replay of a PDU. See Table 2 of receiver to distinguish a subsequent replay of a PDU. See Table 2 of
<xref target="TR-471"/> for a recommended timestamp resolution.</t> <xref target="TR-471" format="default"/> for a recommended timestamp r
esolution.</t>
<t>Upon reception, the receiver SHALL validate the message PDU for <t>Upon reception, the receiver <bcp14>SHALL</bcp14> validate the mess
age 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 be extracted from the PDU and the field, along with the
checkSum field, zeroed prior to the HMAC calculation used for checkSum field, zeroed prior to the Hashed Message Authentication Code
comparison (see section 7.2 of <xref target="RFC9145"/>).</t> (HMAC) calculation used for
comparison (see <xref target="RFC9145" section="7.2"/>).</t>
<t>If the validation fails, the receiver SHOULD NOT continue with <!--[rfced] Should "SHOULD" be added to the latter part of this
sentence for clarity (i.e., "SHOULD NOT continue with the Control
phase and SHOULD implement silent rejection")?
Original:
If the validation fails, the receiver SHOULD NOT continue with the
Control phase and implement silent rejection (no further packets
sent on the address/port pairs).
Perhaps:
If the validation fails, the receiver SHOULD NOT continue with the
Control phase and SHOULD implement silent rejection (no further
packets sent on the address/port pairs).
-->
<t>If the validation fails, the receiver <bcp14>SHOULD NOT</bcp14> con
tinue with
the Control phase and implement silent rejection (no further packets the Control phase and implement silent rejection (no further packets
sent on the address/port pairs). The exception is when the testing sent on the address/port pairs). The exception is when the testing
hosts have been configured for troubleshooting Control phase hosts have been configured for troubleshooting Control phase
failures and rejection messages will aid in the process.</t> failures and rejection messages will aid in the process.</t>
<t>If the validation succeeds, the receiver <bcp14>SHALL</bcp14> conti
<t>If the validation succeeds, the receiver SHALL continue with the nue 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).</t> indicating the error conditions identified (if any).</t>
<t>This process <bcp14>SHALL</bcp14> be executed for the request and r
<t>This process SHALL be executed for the request and response in esponse in
the Test Setup exchange, including the Null Request (<xref the Test Setup exchange, including the Null Request (<xref target="Tes
target="Test-Setup"/>) and the Test Activation exchange (<xref t-Setup" format="default"/>) and the Test Activation exchange (<xref target="Tes
target="Test-Activation"/>).</t> t-Activation" format="default"/>).</t>
</section> </section>
<section anchor="Auth-Mode-2" numbered="true" toc="default">
<section anchor="Auth-Mode-2" <name>Mode 2: Optional Authenticated Mode for Data Phase</name>
title="Mode 2: Optional Authenticated Mode for Data Phase">
<t>This mode incorporates Authenticated mode 1. When using the <t>This mode incorporates Authenticated mode 1. When using the
optional authentication during the Data phase, authentication SHALL optional authentication during the Data phase, authentication <bcp14>S
also be applied to the Status Feedback PDU (see <xref HALL</bcp14>
target="Status-PDU"/>). The client sends the Status PDU in a also be applied to the Status Feedback PDU (see <xref target="Status-P
DU" format="default"/>). The client sends the Status PDU in a
downstream test, and the server sends it in an upstream test.</t> downstream test, and the server sends it in an upstream test.</t>
<t>The Status PDU sender <bcp14>SHALL</bcp14> 1) read the current syst
<t>The Status PDU sender SHALL read the current system (wall-clock) em (wall-clock)
time and populate the authUnixTime field, then calculate the time and populate the authUnixTime field, 2) calculate the
authDigest field of the entire Status PDU (with the authDigest and authDigest field of the entire Status PDU (with the authDigest and
checkSum preset to all zeroes) and send the packet to the receiver. checkSum preset to all zeroes), and 3) send the packet to the receiver .
The values of authUnixTime field and authDigest field are determined The values of authUnixTime field and authDigest field are determined
as defined by <xref target="Auth-Mode-1"/>.</t> as defined by <xref target="Auth-Mode-1" format="default"/>.</t>
<t>Upon reception, the receiver <bcp14>SHALL</bcp14> validate the mess
<t>Upon reception, the receiver SHALL validate the message PDU for age 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.</t> field, zeroed prior to the HMAC calculation used for comparison.</t>
<t>If the authentication validation fails, the receiver <bcp14>SHALL</
<t>If the authentication validation fails, the receiver SHALL ignore bcp14> ignore
the message. If the watchdog timer expires (due to successive failed the message. If the watchdog timer expires (due to successive failed
validations), the test session will prematurely terminate (no validations), the test session will prematurely terminate (and no
further load traffic SHALL be transmitted). This is necessary also further load traffic <bcp14>SHALL</bcp14> be transmitted). This is nec
essary also
to avoid potentially inducing congestion after there is an overload to avoid potentially inducing congestion after there is an overload
or loss on the control path.</t> or loss on the control path.</t>
<t>If this optional mode has not been selected, then the keyId, <t>If this optional mode has not been selected, then the keyId,
authUnixTime, and authDigest fields of the Status PDU (see <xref authUnixTime, and authDigest fields of the Status PDU (see <xref targe
target="Status-PDU"/>) SHALL be set to all zeroes.</t> t="Status-PDU" format="default"/>) <bcp14>SHALL</bcp14> be set to all zeroes.</t
>
</section> </section>
</section> </section>
<section anchor="key-management" numbered="true" toc="default">
<section anchor="key-management" title="Key Management"> <name>Key Management</name>
<t>Section 2 of <xref target="RFC7210"/> specifies a conceptual <t><xref target="RFC7210" section="2"/> specifies a conceptual
database for long-lived cryptographic keys. The key table SHALL be database for long-lived cryptographic keys. The key table <bcp14>SHALL</
used with the REQUIRED authentication mode and the OPTIONAL bcp14> be
used with the <bcp14>REQUIRED</bcp14> authentication mode and the <bcp14
>OPTIONAL</bcp14>
authentication mode (using the same key). For authentication, this key authentication mode (using the same key). For authentication, this key
SHALL only be used as input to the KDF, specified in <xref <bcp14>SHALL</bcp14> only be used as input to the KDF, as specified in <
target="kdf"/>, to derive the actual keys used for authentication xref target="kdf" format="default"/>, to derive the actual keys used for authent
ication
processing. Key rotation and related management specifics are beyond processing. Key rotation and related management specifics are beyond
the scope of this document.</t> the scope of this document.</t>
<t>The key table <bcp14>SHALL</bcp14> have (at least) the following fiel ds per <xref target="RFC7210" section="2"/>:</t>
<t>The key table SHALL have (at least) the following fields, referring <!--[rfced] We note a variance with the terms listed in Section 4.4
to Section 2 of <xref target="RFC7210"/>:</t> versus the terms listed in RFC 7210. In RFC 7210, "Time" is uppercase
(except in "SendLifetimeStart", which contains a lowercase "t"
both in this document and RFC 7210). Should this document be
updated as follows for consistency with RFC 7210?
<t><list style="symbols"> Original:
<t>AdminKeyName</t> * SendLifetimeEnd
<t>LocalKeyName</t> * AcceptLifetimeStart
<t>KDF</t> * AcceptLifetimeEnd
<t>AlgID</t> Perhaps:
* SendLifeTimeEnd
<t>Key</t> * AcceptLifeTimeStart
<t>SendLifetimeStart</t> * AcceptLifeTimeEnd
-->
<ul spacing="normal">
<li>
<t>AdminKeyName</t>
</li>
<li>
<t>LocalKeyName</t>
</li>
<li>
<t>KDF</t>
</li>
<li>
<t>AlgID</t>
</li>
<li>
<t>Key</t>
</li>
<li>
<t>SendLifetimeStart</t>
</li>
<li>
<t>SendLifetimeEnd</t> <t>SendLifetimeEnd</t>
</li>
<li>
<t>AcceptLifetimeStart</t> <t>AcceptLifetimeStart</t>
</li>
<li>
<t>AcceptLifetimeEnd</t> <t>AcceptLifetimeEnd</t>
</list></t> </li>
</ul>
<t>The LocalKeyName SHALL be determined from the corresponding keyId <t>The LocalKeyName <bcp14>SHALL</bcp14> be determined from the correspo
nding keyId
field in the PDUs that follow.</t> field in the PDUs that follow.</t>
<section anchor="kdf" numbered="true" toc="default">
<section anchor="kdf" title="Key Derivation Function (KDF)"> <name>Key Derivation Function (KDF)</name>
<t>A Key Derivation Function (KDF) is a one-way function that <t>A Key Derivation Function (KDF) is a one-way function that
provides cryptographic separation of key material. The protocol provides cryptographic separation of key material. The protocol
requires a KDF to securely derive cryptographic keys used for requires a KDF to securely derive cryptographic keys used for
authentication of protocol messages. The inclusion of a KDF ensures authentication of protocol messages. The inclusion of a KDF ensures
that keys are generated in a standardized, cryptographically secure that keys are generated in a standardized, cryptographically secure
manner, reducing the risk of key compromise and enabling manner, reducing the risk of key compromise and enabling
interoperability across implementations. The benefits of using a KDF interoperability across implementations. The benefits of using a KDF
include:</t> include:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Security: A KDF produces keys with high entropy, resistant to <t>Security: A KDF produces keys with high entropy, resistant to
brute-force and related-key attacks, ensuring robust protection brute-force and related-key attacks, ensuring robust protection
for protocol communications.</t> for protocol communications.</t>
</li>
<li>
<t>Flexibility: The KDF allows derivation of multiple keys from <t>Flexibility: The KDF allows derivation of multiple keys from
a single shared secret, supporting distinct keys for client and a single shared secret, supporting distinct keys for client and
server authentication.</t> server authentication.</t>
</li>
<li>
<t>Standardization: By adhering to established cryptographic <t>Standardization: By adhering to established cryptographic
standards, the KDF ensures compatibility with existing security standards, the KDF ensures compatibility with existing security
frameworks and facilitates implementation audits.</t> frameworks and facilitates implementation audits.</t>
</li>
<li>
<t>Efficiency: The KDF enables efficient key generation without <t>Efficiency: The KDF enables efficient key generation without
requiring additional key exchange mechanisms, minimizing requiring additional key exchange mechanisms, minimizing
protocol overhead.</t> protocol overhead.</t>
</list></t> </li>
</ul>
<t>The KDF algorithm SHALL be a Key Derivation Function in Counter <t>The KDF algorithm <bcp14>SHALL</bcp14> be a Key Derivation Function
Mode, as specified in Section 4.1 of <xref target="NIST800-108"/>. in Counter
Mode, as specified in Section 4.1 of <xref target="NIST800-108" format
="default"/>.
This algorithm uses a counter-based mechanism to generate key This algorithm uses a counter-based mechanism to generate key
material from a shared secret, ensuring deterministic and secure key material from a shared secret, ensuring deterministic and secure key
derivation. The Pseudorandom Function (PRF) used in the KDF SHALL be derivation. The Pseudorandom Function (PRF) used in the KDF <bcp14>SHA
HMAC-SHA-256, as defined in section 6 of <xref target="RFC6234"/>. LL</bcp14> be
IANA is asked to assign &ldquo;HMAC-SHA-256&rdquo; as a new KeyTable HMAC-SHA-256, as defined in <xref target="RFC6234" section="6"/>.
KDF (<xref target="kdf-HMAC-SHA-256"/>).</t> IANA has assigned "HMAC-SHA-256" as a new KeyTable
KDF (<xref target="kdf-HMAC-SHA-256" format="default"/>).</t>
<t>The KDF SHALL use the following parameters:</t> <t>The KDF <bcp14>SHALL</bcp14> use the following parameters:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Kin (Key-derivation key): The shared key as identified by the <t>Kin (key-derivation key): The shared key as identified by the
keyId field in the PDU.</t> keyId field in the PDU.</t>
</li>
<li>
<t>Label: The fixed string "UDPSTP" (without quotes), encoded as <t>Label: The fixed string "UDPSTP" (without quotes), encoded as
a UTF-8 string, used to bind the derived keys to this specific a UTF-8 string, used to bind the derived keys to this specific
protocol.</t> protocol.</t>
</li>
<li>
<t>Context: The UTF-8 string representation of the authUnixTime <t>Context: The UTF-8 string representation of the authUnixTime
field received in the very first Setup Request PDU sent from the field received in the very first Setup Request PDU sent from the
client to the server. This ensures that the derived keys are client to the server. This ensures that the derived keys are
unique to the session and tied to the temporal context of the unique to the session and tied to the temporal context of the
initial setup exchange. The authUnixTime field serves as a nonce initial setup exchange. The authUnixTime field serves as a nonce
and is protected from modification by the HMAC-SHA-256 hash and is protected from modification by the HMAC-SHA-256 hash
present in the authDigest field.</t> present in the authDigest field.</t>
</li>
<t>r: The length of the binary encoding of the counter SHALL be <li>
<t>r: The length of the binary encoding of the counter <bcp14>SHAL
L</bcp14> be
32 (bits).</t> 32 (bits).</t>
</list></t> </li>
</ul>
<t>The total derived key material SHALL be 512 bits (64 octets) in <t>The total derived key material <bcp14>SHALL</bcp14> be 512 bits (64
length. The key material SHALL be structured as follows, from most octets) in
length. The key material <bcp14>SHALL</bcp14> be structured as follows
, from most
significant bit (MSB) to least significant bit (LSB):</t> significant bit (MSB) to least significant bit (LSB):</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Client Authentication Key: 256 bits (32 octets), used for <t>Client Authentication Key: 256 bits (32 octets); used for
authenticating messages sent by the client.</t> authenticating messages sent by the client.</t>
</li>
<t>Server Authentication Key: 256 bits (32 octets), used for <li>
<t>Server Authentication Key: 256 bits (32 octets); used for
authenticating messages sent by the server.</t> authenticating messages sent by the server.</t>
</list></t> </li>
</ul>
<t>This structure ensures that the derived keys are sufficient for <t>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.</t> maintaining clear separation of function and directionality.</t>
<t>If authentication of the initial Setup Request PDU received by <t>If authentication of the initial Setup Request PDU received by
the server fails, due to an invalid authDigest field, any and all the server fails, due to an invalid authDigest field, any and all
derived keying material and keys SHALL be considered invalid.</t> derived keying material and keys <bcp14>SHALL</bcp14> be considered in
valid.</t>
<t>The key material derived from the initial Setup Request PDU, <t>The key material derived from the initial Setup Request PDU,
either at the client prior to transmission or at the server upon either at the client prior to transmission or at the server upon
reception, SHALL be used for all subsequent PDUs sent between them reception, <bcp14>SHALL</bcp14> be used for all subsequent PDUs sent b etween them
for that test connection. As such, the KDF is only required to be for that test connection. As such, the KDF is only required to be
executed once by the client and server for each test connection.</t> executed once by the client and server for each test connection.</t>
<t><xref target="KDF-Example" format="default"/>, <xref target="KDFfig
<t><xref target="KDF-Example"/>, <xref target="KDFfigure"/> provides ure" format="default"/> provides
a code snippet demonstrating derivation of the specified keys from a code snippet demonstrating derivation of the specified keys from
key material using the OpenSSL cryptographic library. Specifically, key material using the OpenSSL cryptographic library, specifically
the high-level Key-Based EVP_KDF implementation (Key-Based Envelope the high-level Key-Based EVP_KDF implementation (Key-Based Envelope
Key Derivation Function, see <xref target="EVP_KDF-KB"/> for Key Derivation Function); see <xref target="EVP_KDF-KB" format="defaul
details).</t> t"/> for
details.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Configuration of Network Functions with Stateful Filtering <!--[rfced] Does "that 4-tuple" refer to the source and destination
"> addresses and port numbers? If so, may we update the text as
shown below for clarity?
Original:
Successful interaction with a local firewall assumes the firewall is
configured to allow a host to open a bidirectional connection using
unique source and destination addresses as well as port numbers by
sending a packet using that 4-tuple for a given transport protocol.
Perhaps:
Successful interaction with a local firewall assumes the firewall
is configured to allow a host to open a bidirectional connection
using unique source and destination addresses as well as port
numbers (i.e., a 4-tuple) by sending a packet using that 4-tuple
for a given transport protocol.
-->
<name>Configuration of Network Functions with Stateful Filtering</name>
<t>Successful interaction with a local firewall assumes the firewall <t>Successful interaction with a local firewall assumes the firewall
is configured to allow a host to open a bidirectional connection using is 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.</t> configuration.</t>
<t>The firewall at the server <bcp14>MUST</bcp14> be configured with an
<t>The firewall at the server MUST be configured with an open pinhole open pinhole
for the server IP address and standard UDP port of the server. All for the server IP address and standard UDP port of the server. All
messages sent by the client to the server use this standard UDP messages sent by the client to the server use this standard UDP
port.</t> port.</t>
<t>The server uses one ephemeral UDP port per test connection. <t>The server uses one ephemeral UDP port per test connection.
Assuming that the firewall administration at the server does not allow Assuming that the firewall administration at the server does not allow
an open UDP ephemeral port range, then the server MUST send a Null an open UDP ephemeral port range, then the server <bcp14>MUST</bcp14> se nd a Null
Request to the client from the ephemeral port communicated to the Request to the client from the ephemeral port communicated to the
client in the Test Setup Response. The Null Request may not reach the client in the Test Setup Response. The Null Request may not reach the
client: it may be discarded by the client's firewall.</t> client: it may be discarded by the client's firewall.</t>
<t>If the server firewall administration allows an open UDP ephemeral <t>If the server firewall administration allows an open UDP ephemeral
port range, then the Null Request is not strictly necessary. However, port range, then the Null Request is not strictly necessary. However,
the availability of an open port range policy cannot be assumed.</t> the availability of an open port range policy cannot be assumed.</t>
<t>Network Address Translators (NATs) are expected to offer support of <t>Network Address Translators (NATs) are expected to offer support of
a wider set of operational configurations as compared to Firewalls. a 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 of
scope of this document, as are combined implementations of NAT and the scope of this document, as are combined implementations of NAT and
firewalls too.</t> firewalls too.</t>
</section> </section>
<section anchor="Checksum" numbered="true" toc="default">
<section anchor="Checksum" title="Optional Checksum"> <name>Optional Checksum</name>
<t>The protocol MUST utilize the standard UDP checksum for all IPv4 <t>The protocol <bcp14>MUST</bcp14> utilize the standard UDP checksum fo
r all IPv4
and IPv6 datagrams it sends. The purpose of this checksum is to and IPv6 datagrams it sends. The purpose of this checksum is to
protect the intended recipient as well as other recipients to whom a protect the intended recipient as well as other recipients to whom a
corrupted packet may be delivered. This provides:</t> corrupted packet may be delivered. This provides:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Protection of the endpoint transport state from unnecessary <t>Protection of the endpoint transport state from unnecessary
extra state (e.g., Invalid state from rogue packets).</t> extra state (e.g., Invalid state from rogue packets).</t>
</li>
<li>
<t>Protection of the endpoint transport state from corruption of <t>Protection of the endpoint transport state from corruption of
internal state.</t> internal state.</t>
</li>
<li>
<t>Pre-filtering by the endpoint of erroneous data, to protect the <t>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.</t> cannot itself reject.</t>
</li>
<li>
<t>Pre-filtering of incorrectly addressed destination packets, <t>Pre-filtering of incorrectly addressed destination packets,
before responding to a source address.</t> before responding to a source address.</t>
</list></t> </li>
</ul>
<t>All of the PDUs exchanged between the client and server support an <t>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).
<!--[rfced] Please clarify what "one" refers to in "16-bit one's
complement Internet checksum". Is the checksum 16 bits?
Original:
The calculation is the same as the 16-bit one's complement Internet
checksum used in the IPv4 packet header (see section 3.1 of
[RFC0791]).
-->
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 <xref target="RFC0791"/>). This checksum is header (see <xref target="RFC0791" section="3.1"/>). This checksum is
intended for environments where UDP data integrity may be uncertain. intended for environments where UDP data integrity may be uncertain.
This includes situations where the standard UDP checksum is not This includes situations where the standard UDP checksum is not
verified upon reception or a nonstandard network API is in use (things verified 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 <bcp14>SHALL</bcp14> i nclude 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 that the UDP checksum calculation need not include it for Load
PDUs.</t> PDUs.</t>
<t>If a PDU sender is populating the checkSum field, it <bcp14>SHALL</bc
<t>If a PDU sender is populating the checkSum field, it SHALL do so as p14> 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 receiver checkSum field set to zero prior to the calculation). The PDU receiver
SHALL subsequently verify the PDU checksum whenever checksum <bcp14>SHALL</bcp14> subsequently verify the PDU checksum whenever check sum
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.</t> checksum validation fails, the PDU <bcp14>SHALL</bcp14> be discarded.</t
>
<t>Because of the redundancy when used in conjunction with <t>Because of the redundancy when used in conjunction with
authentication, it is OPTIONAL for a PDU sender to utilize the UDPSTP authentication, it is <bcp14>OPTIONAL</bcp14> for a PDU sender to utiliz e the UDPSTP
checkSum field. However, because authentication is not applicable to checkSum field. However, because authentication is not applicable to
the Load PDU, the checkSum field SHALL be utilized by the sender the Load PDU, the checkSum field <bcp14>SHALL</bcp14> be utilized by the sender
whenever UDP data integrity may be uncertain (as outlined above).</t> whenever UDP data integrity may be uncertain (as outlined above).</t>
</section> </section>
</section> </section>
<section anchor="Test-Setup" numbered="true" toc="default">
<section anchor="Test-Setup" title="Test Setup Request and Response"> <name>Test Setup Request and Response</name>
<t>The client source IP address and the server destination IP address <t>The client source IP address and the server destination IP address
MUST NOT be a broadcast or multicast address. Any Test Setup Request or <bcp14>MUST NOT</bcp14> be a broadcast or multicast address. Any Test Setu p Request or
Test Setup Response packet containing a multicast or broadcast source or Test Setup Response packet containing a multicast or broadcast source or
destination IP address MUST be silently dropped and ignored.</t> destination IP address <bcp14>MUST</bcp14> be silently dropped and ignored
.</t>
<t>The measurement method and the protocol specified by this document <t>The measurement method and the protocol specified by this document
are expected to function with unicast and anycast IP addresses.</t> are expected to function with unicast and anycast IP addresses.</t>
<section anchor="Setup-Fields" numbered="true" toc="default">
<section anchor="Setup-Fields" <name>Client Generates Test Setup Request</name>
title="Client Generates Test Setup Request"> <t>The client <bcp14>SHALL</bcp14> begin the Control phase exchange by s
<t>The client SHALL begin the Control phase exchange by sending a Test ending a Test
Setup Request message to the server's (standard) control port. This Setup Request message to the server's (standard) control port. This
standard UDPSTP port number is utilized for each connection of a standard UDPSTP port number is utilized for each connection of a
multi-connection test.</t> multi-connection test.</t>
<t>The client SHALL simultaneously start a test initiation timer so <!--[rfced] May we rephrase the text in the parentheses for clarity as
follows?
Original:
The client SHALL simultaneously start a test initiation timer so that
if the Control phase fails to complete Test Setup and Test Activation
exchanges in the allocated time, the client software SHALL exit
(close the UDP socket and indicate an error message to the user).
Perhaps:
The client SHALL simultaneously start a test initiation timer so that
if the Control phase fails to complete Test Setup and Test Activation
exchanges in the allocated time, the client software SHALL exit
(i.e., the UDP socket will close and an error message will be displayed
to the user).
-->
<t>The client <bcp14>SHALL</bcp14> simultaneously start a test initiatio
n timer so
that if the Control phase fails to complete Test Setup and Test that if the Control phase fails to complete Test Setup and Test
Activation exchanges in the allocated time, the client software SHALL Activation exchanges in the allocated time, the client software <bcp14>S HALL</bcp14>
exit (close the UDP socket and indicate an error message to the user). exit (close the UDP socket and indicate an error message to the user).
Lost messages result in a Test Setup and Test Activation failure. The Lost messages result in a Test Setup and Test Activation failure. The
test initiation timer MAY reuse the test termination timeout test initiation timer <bcp14>MAY</bcp14> reuse the test termination time out
value.</t> value.</t>
<t>The watchdog timeout is configured as a 1-second interval to <t>The watchdog timeout is configured as a 1-second interval to
trigger a warning message that the received traffic has stopped. The trigger a warning message that the received traffic has stopped. The
test termination timeout is based on the watchdog interval, and test termination timeout is based on the watchdog interval and
implements a wait time of 2 additional seconds before triggering a implements a wait time of 2 additional seconds before triggering a
non-graceful termination.</t> non-graceful termination.</t>
<t>Note: Any field labeled as 'reserved for alignment', in any PDU, <t>Note: Any field labeled as 'reserved for alignment', in any PDU,
MUST be set to 0 and MUST be ignored upon receipt.</t> <bcp14>MUST</bcp14> be set to 0 and <bcp14>MUST</bcp14> be ignored upon receipt.</t>
<t>The UDP PDU format layout SHALL be as follows (big-endian AB, <!--[rfced] Is "by most significant byte" correct, or should it be
starting by most significant byte ending by least significant "with the most significant byte" as shown below?
Original:
The UDP PDU format layout SHALL be as follows (big-endian AB,
starting by most significant byte ending by least
significant byte):
Perhaps:
The UDP PDU format layout SHALL be as follows (big-endian AB,
starting with the most significant byte and ending with
the least significant byte):
-->
<t>The UDP PDU format layout <bcp14>SHALL</bcp14> be as follows (big-endi
an AB,
starting by most significant byte and ending by least significant
byte):</t> byte):</t>
<t><figure anchor="Setup-PDU" title="Test Setup PDU Layout"> <!--[rfced] FYI: For Figures 2, 4, 6, 8, and 10, we moved the bit
<artwork> ruler over one space to the right so that the numbers are
0 1 2 3 positioned over the dashes rather than the plus signs to match
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 use in the RFC Series.
-->
<figure anchor="Setup-PDU">
<name>Test Setup PDU Layout</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
<postamble/>
</figure></t>
<t>Additional details regarding the Setup Request and Response fields <t>Additional details regarding the Setup Request and Response fields
are as follows:</t> are as follows:</t>
<t>pduId: A two-octet field. IANA is asked to assign the value hex <dl spacing="normal" newline="false">
0xACE1 (<xref target="pduId"/>).</t> <dt>pduId:</dt><dd>A two-octet field. IANA has assigned the hex value
0xACE1 (<xref target="pduId" format="default"/>).</dd>
<t>protocolVer: A two-octet field, identifying the actual protocol <dt>protocolVer:</dt><dd>A two-octet field identifying the actual protoc
version. IANA is asked to assign only one initial value, 20 (<xref ol
target="protocolVer"/>).</t> version. IANA has assigned 20 as the value (<xref target="protocolVer" f
ormat="default"/>).</dd>
<t>mcIndex: A one-octet field, indicating the index of a connection <dt>mcIndex:</dt><dd>A one-octet field indicating the index of a connect
ion
relative to all connections that make up a single test (starting at 0, relative to all connections that make up a single test (starting at 0,
incremented by 1 per connection). It is used to differentiate separate incremented by 1 per connection). It is used to differentiate separate
connections within a multi-connection test. An implementation may connections within a multi-connection test. An implementation may
restrict the number of connections supported for a single test to a restrict the number of connections supported for a single test to a
value less than or equal to 255.</t> value less than or equal to 255.</dd>
<dt>mcCount:</dt><dd>A one-octet field indicating the total count of
<t>mcCount: A one-octet field, indicating the total count of connections that the client is attempting to set up.</dd>
connections that the client is attempting to setup.</t> <dt>mcIdent:</dt><dd>A two-octet field containing a pseudorandom non-zer
o
<t>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 used by
clients/servers to associate separate connections with a single clients/servers to associate separate connections with a single
multi-connection test.</t> multi-connection test.</dd>
<dt>cmdRequest:</dt><dd>A one-octet field set to CHSR_CREQ_SETUPREQ to i
<t>cmdRequest: A one-octet field set to CHSR_CREQ_SETUPREQ to indicate ndicate
a Setup request message. Note that CHSR_CREQ_NONE remains unused.</t> a Setup Request message. Note that CHSR_CREQ_NONE remains unused.</dd>
<dt>cmdResponse:</dt><dd>A one-octet field. All Request PDUs always have
<t>cmdResponse: A one-octet field. All Request PDUs always have a a
Command Response of XXXX_CRSP_NONE.</t> Command Response of XXXX_CRSP_NONE.</dd>
<dt>maxBandwith:</dt><dd>A two-octet field. A non-zero value of this fie
<t>maxBandwith: A two-octet field. A non-zero value of this field ld
specifies the maximum bit rate the client expects to send or receive specifies the maximum bit rate the client expects to send or receive
during the requested test in Mbps. The server compares this value to during the requested test in Mbps. The server compares this value to
its currently available configured limit for test admission control. its currently available configured limit for test admission control.
This field MAY be used for rate-limiting the maximum rate the server This field <bcp14>MAY</bcp14> be used to rate-limit the maximum rate the server
should attempt. The maxBandwidth field's most significant bit, the should attempt. The maxBandwidth field's most significant bit, the
CHSR_USDIR_BIT, is set to 0 by default to indicate "downstream" and CHSR_USDIR_BIT, is set to 0 by default to indicate "downstream" and
has to be set to 1 to indicate "upstream".</t> has to be set to 1 to indicate "upstream".</dd>
<dt>testPort:</dt><dd>A two-octet field set to zero in the Test Setup Re
<t>testPort: A two-octet field, set to zero in the Test Setup Request quest
and populated by the server in the Test Setup Response. It contains and populated by the server in the Test Setup Response. It contains
the UDP ephemeral port number on the server that the client has to use the UDP ephemeral port number on the server that the client has to use
for the Test Activation Request and subsequent Load or Status for the Test Activation Request and subsequent Load or Status
PDUs.</t> PDUs.</dd>
<dt>modifierBitmap:</dt><dd><t>A one-octet field. This document only ass
<t>modifierBitmap: A one-octet field. This document only assigns two igns two
bits in this bitmap, see <xref target="Setup-modifierBitmap"/>:</t> bits in this bitmap; see <xref target="Setup-modifierBitmap" format="def
ault"/>:</t>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="CHSR_JUMBO_STATUS">This bit SHALL be set by default. <dt>CHSR_JUMBO_STATUS:</dt>
By default, sending rates up to 1 Gbps SHALL NOT produce IP packet <dd>This bit <bcp14>SHALL</bcp14> be set by default.
sizes greater than 1250 bytes (unless CHSR_TRADITIONAL_MTU is set) By default, sending rates up to 1 Gbps <bcp14>SHALL NOT</bcp14> prod
while rates above 1 Gbps MAY produce IP packet sizes up to 9000 uce IP packet
bytes. When CHSR_JUMBO_STATUS is not set, all sending rates SHALL sizes greater than 1250 bytes (unless CHSR_TRADITIONAL_MTU is set),
NOT produce IP packet sizes greater than 1250 bytes (unless while rates above 1 Gbps <bcp14>MAY</bcp14> produce IP packet sizes
CHSR_TRADITIONAL_MTU is set).</t> up to 9000
bytes. When CHSR_JUMBO_STATUS is not set, all sending rates <bcp14>S
<t hangText="CHSR_TRADITIONAL_MTU">This bit SHALL NOT be set by HALL
default. If set, sending rates up to 1 Gbps MAY produce IP packets NOT</bcp14> produce IP packet sizes greater than 1250 bytes (unless
up to the Traditional size of 1500 bytes. If CHSR_JUMBO_STATUS is CHSR_TRADITIONAL_MTU is set).</dd>
simultaneously not set, all sending rates SHALL NOT produce IP <dt>CHSR_TRADITIONAL_MTU:</dt>
packets greater than the Traditional size of 1500 bytes.</t> <dd>This bit <bcp14>SHALL NOT</bcp14> be set by
</list>Other bit positions are left unassigned by this document.</t> default. If set, sending rates up to 1 Gbps <bcp14>MAY</bcp14> produ
ce IP packets
<t>authMode: A one-octet field. The authMode field currently has two up to the traditional size of 1500 bytes. If CHSR_JUMBO_STATUS is
values assigned (see <xref target="Setup-authMode"/>). One of the simultaneously not set, all sending rates <bcp14>SHALL NOT</bcp14> p
following has to be set (see <xref target="SecurityModes"/> for roduce IP
requirements and details of operation): <list style="hanging"> packets greater than the traditional size of 1500 bytes.</dd>
<t hangText="AUTHMODE_1:">Required Authentication for Control </dl></dd></dl>
phase</t> <t>Other bit positions are left unassigned per this document.</t>
<dl spacing="normal" newline="false">
<t hangText="AUTHMODE_2:">Optional Authentication for Control and <dt>authMode:</dt><dd><t>A one-octet field. The authMode field currently
Data phase (Status Feedback PDU only)</t> has two
</list>A range of 60 through 63 is reserved for experimentation. values assigned (see <xref target="Setup-authMode" format="default"/>).
IANA is asked to create a registry for the assigned values; see the One of the
IANA Considerations Section.</t> following has to be set (see <xref target="SecurityModes" format="defaul
t"/> for
<t>authUnixTime: A 32-bit timestamp of the current system (wall-clock) requirements and details of operation):</t>
time since the Unix Epoch on January 1st, 1970 at 00:00:00 UTC.</t> <dl newline="false" spacing="normal">
<dt>AUTHMODE_1:</dt>
<t>authDigest: This field contains the 32-octet HMAC-SHA-256 hash that <dd>Required Authentication for Control
phase.</dd>
<dt>AUTHMODE_2:</dt>
<dd>Optional Authentication for Control and
Data phase (Status Feedback PDU only).</dd>
</dl>
</dd></dl>
<t>A range of 60 through 63 is reserved for experimentation.
IANA has created a registry for the assigned values; see the
<xref target="IANA" format="title"/> section.</t>
<dl spacing="normal" newline="false">
<dt>authUnixTime:</dt><dd>A 32-bit timestamp of the current system (wall
-clock)
time since the Unix Epoch on January 1, 1970 at 00:00:00 UTC.</dd>
<dt>authDigest:</dt><dd>This field contains the 32-octet HMAC-SHA-256 ha
sh that
covers the entire PDU. Normally, the calculation is done as the last covers the entire PDU. Normally, the calculation is done as the last
step of building the PDU. However, if the optional checkSum field is step of building the PDU. However, if the optional checkSum field is
being utilized, it becomes the penultimate step and is done just prior being utilized, it becomes the penultimate step and is done just prior
to the checksum calculation (with the checkSum field set to zero).</t> to the checksum calculation (with the checkSum field set to zero).</dd>
<dt>keyId:</dt><dd>A one-octet field carrying localKeyName, the numeric
<t>keyId: A one-octet field carrying localKeyName, the numeric key key
identifier for a key in the shared key table.</t> identifier for a key in the shared key table.</dd>
<dt>reservedAuth1:</dt><dd>A one-octet field. This field <bcp14>MUST</bc
<t>reservedAuth1: A one-octet field. This field MUST be set to 0 and p14> be set to 0 and
MUST be ignored upon receipt. Consistent naming and placement of the <bcp14>MUST</bcp14> be ignored upon receipt. Consistent naming and place
reservedAuth1 field across all PDUs is done to minimize authentication ment of the
related changes in future UDPSTP versions.</t> reservedAuth1 field across all PDUs is done to minimize authentication-r
elated
<t>checkSum: A two-octet field, containing an optional checksum of the changes in future UDPSTP versions.</dd>
entire PDU (see <xref target="Checksum"/> for guidance). The <dt>checkSum:</dt><dd>A two-octet field containing an optional checksum
of the
entire PDU (see <xref target="Checksum" format="default"/> for guidance)
. The
calculation is done as the very last step of building the PDU, with calculation is done as the very last step of building the PDU, with
the checkSum field set to zero.</t> the checkSum field set to zero.</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Server Test Setup Request Processing and Response Generati <name>Server Test Setup Request Processing and Response Generation</name
on"> >
<t>This section describes the processes at the server to evaluate the <t>This section describes the processes at the server that are used to e
valuate the
Test Setup Request and determine the next steps. When the server Test Setup Request and determine the next steps. When the server
receives the Setup Request, it SHALL first perform the following:</t> receives the Setup Request, it <bcp14>SHALL</bcp14> first perform the fo
llowing:</t>
<t anchor="VerifyPDU">Message Verification Procedure</t> <t anchor="VerifyPDU">Message Verification Procedure:</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers">
<t>Verify that the size of the message is correct.</t> <t>Verify that the size of the message is correct.</t>
</li>
<li>
<t>If the optional checkSum field is being utilized, validate the <t>If the optional checkSum field is being utilized, validate the
checksum as described in <xref target="Checksum"/> and (if valid) checksum as described in <xref target="Checksum" format="default"/> and (if valid)
zero the checkSum field prior to authentication verification.</t> zero the checkSum field prior to authentication verification.</t>
</li>
<li>
<t>Verify that the authMode value is valid and appropriate (per <t>Verify that the authMode value is valid and appropriate (per
<xref target="SecurityModes"/>) for the message type.</t> <xref target="SecurityModes" format="default"/>) for the message typ
e.</t>
</li>
<li>
<t>If the authMode is valid and appropriate, authenticate the <t>If the authMode is valid and appropriate, authenticate the
message by checking the authDigest as prescribed in <xref message by checking the authDigest as prescribed in <xref target="Se
target="SecurityModes"/>.</t> curityModes" format="default"/>.</t>
</li>
<li>
<t>If the message is authentic, check the authUnixTime field for <t>If the message is authentic, check the authUnixTime field for
acceptable immediacy.</t> acceptable immediacy.</t>
</list>Note: If any of the above checks fail, the message SHALL be </li>
</ol>
<t>Note: If any of the above checks fail, the message <bcp14>SHALL</bcp1
4> be
considered invalid.</t> considered invalid.</t>
<section numbered="true" toc="default">
<section title="Test Setup Request Processing - Rejection"> <name>Test Setup Request Processing -- Rejection</name>
<t>The server SHALL then evaluate the other fields in the protocol <t>The server <bcp14>SHALL</bcp14> then evaluate the other fields in t
he 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).</t> and Traditional MTU (1500 bytes).</t>
<t>If the client has selected options for</t>
<t>If the client has selected options for:<list style="symbols"> <ul spacing="normal">
<li>
<t>Jumbo datagram support (modifierBitmap),</t> <t>Jumbo datagram support (modifierBitmap),</t>
</li>
<t>Traditional MTU (modifierBitmap),</t> <li>
<t>Traditional MTU (modifierBitmap), and </t>
</li>
<li>
<t>Authentication mode (authMode)</t> <t>Authentication mode (authMode)</t>
</list></t> </li>
</ul>
<t>that do not match the server configuration, the server MUST <t>that do not match the server configuration, the server <bcp14>MUST<
/bcp14>
reject the Setup Request.</t> reject the Setup Request.</t>
<t>If the Setup Request must be rejected, the conditions below <t>If the Setup Request must be rejected, the conditions below
determine whether the server sends a response:</t> determine whether the server sends a response:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>If the authDigest is valid, a Test Setup Response SHALL be <t>If the authDigest is valid, a Test Setup Response <bcp14>SHALL<
sent back to the client with a corresponding command response /bcp14> be
sent back to the client with a corresponding Command Response
value indicating the reason for the rejection.</t> value indicating the reason for the rejection.</t>
</li>
<li>
<t>If the authDigest is invalid, then the Test Setup Request <t>If the authDigest is invalid, then the Test Setup Request
SHOULD fail silently. The exception is for operations support: <bcp14>SHOULD</bcp14> fail silently. The exception is for operatio ns support:
server administrators are permitted to send a Setup Response to server administrators are permitted to send a Setup Response to
support operations and troubleshooting.</t> support operations and troubleshooting.</t>
</list></t> </li>
</ul>
<t>The additional circumstances when a server SHALL NOT communicate <t>The additional circumstances when a server <bcp14>SHALL NOT</bcp14>
communicate
the appropriate Command Response code for an error condition (fail the appropriate Command Response code for an error condition (fail
silently) are when: <list style="numbers"> silently) are when: </t>
<ul spacing="normal"><li>
<t>the Setup Request PDU size is not equal to the 'struct <t>the Setup Request PDU size is not equal to the 'struct
controlHdrSR' size shown in <xref target="CHSR"/>,</t> controlHdrSR' size shown in <xref target="CHSR" format="default"/>
,</t>
</li>
<li>
<t>the PDU ID is not 0xACE1 (Test Setup PDU), or</t> <t>the PDU ID is not 0xACE1 (Test Setup PDU), or</t>
</li>
<t>a directed attack has been detected,</t> <li>
</list>in which case the server will allow setup attempts to <t>a directed attack has been detected.</t>
</li>
</ul>
<t>In this case, the server will allow setup attempts to
terminate silently. Attack detection is beyond the scope of this terminate silently. Attack detection is beyond the scope of this
specification.</t> specification.</t>
<t>When the server replies to a Test Setup Request message, the Test <t>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 <bcp14>SHALL</bcp14> retain the original values received in it, with t he following
exceptions:</t> exceptions:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>The cmdRequest field is set to CHSR_CREQ_SETUPRSP, indicating <t>The cmdRequest field is set to CHSR_CREQ_SETUPRSP, indicating
a response.</t> a response.</t>
</li>
<li>
<t>The cmdResponse field is set to an error code (starting at <t>The cmdResponse field is set to an error code (starting at
cmdResponse 2, Bad Protocol Version, see <xref cmdResponse 2, Bad Protocol Version; see <xref target="Error-codes
target="Error-codes"/>), indicating the reason for rejection. If " format="default"/>), indicating the reason for rejection. If
cmdResponse indicates a bad protocol version (CHSR_CRSP_BADVER), cmdResponse indicates a bad protocol version (CHSR_CRSP_BADVER),
the protocolVer field is also updated to indicate the current the protocolVer field is also updated to indicate the current
expected version.</t> expected version.</t>
</li>
<li>
<t>The authUnixTime field is updated to the current system <t>The authUnixTime field is updated to the current system
(wall-clock) time and, after the authDigest and checkSum fields (wall-clock) time and, after the authDigest and checkSum fields
are zeroed, the authDigest is recalculated and inserted. If the are 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.</t> calculated and inserted.</t>
</list></t> </li>
</ul>
<t>The Setup Request/Response message PDU SHALL be organized as <t>The Setup Request/Response message PDU <bcp14>SHALL</bcp14> be orga
nized as
follows (here and in all following code figures coded by programming follows (here and in all following code figures coded by programming
language C <xref target="C-Prog"/>):</t> language C <xref target="C-Prog" format="default"/>):</t>
<figure anchor="CHSR">
<t><figure anchor="CHSR" title="Test Setup PDU"> <name>Test Setup PDU</name>
<artwork> <sourcecode name="" type="c" markers="true"><![CDATA[
&lt;CODE BEGINS&gt;
// //
// Control header for UDP payload of Setup Request/Response PDUs // Control header for UDP payload of Setup Request/Response PDUs
// //
struct controlHdrSR { struct controlHdrSR {
#define CHSR_ID 0xACE1 #define CHSR_ID 0xACE1
uint16_t pduId; // PDU ID uint16_t pduId; // PDU ID
#define PROTOCOL_VER 20 #define PROTOCOL_VER 20
uint16_t protocolVer; // Protocol version uint16_t protocolVer; // Protocol version
uint8_t mcIndex; // Multi-connection index uint8_t mcIndex; // Multi-connection index
uint8_t mcCount; // Multi-connection count uint8_t mcCount; // Multi-connection count
skipping to change at line 1216 skipping to change at line 1431
#define AUTHMODE_2 2 // Mode 2: Authenticated Control+Status #define AUTHMODE_2 2 // Mode 2: Authenticated Control+Status
uint8_t authMode; // Authentication mode uint8_t authMode; // Authentication mode
uint32_t authUnixTime; // Authentication timestamp uint32_t authUnixTime; // Authentication timestamp
#define AUTH_DIGEST_LENGTH 32 // SHA-256 digest length #define AUTH_DIGEST_LENGTH 32 // SHA-256 digest length
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
&lt;CODE ENDS&gt; ]]></sourcecode>
</artwork> </figure>
<postamble/>
</figure></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Test Setup Request Processing - Acceptance"> <name>Test Setup Request Processing -- Acceptance</name>
<t>If the server finds that the Setup Request matches its <t>If the server finds that the Setup Request matches its
configuration and is otherwise acceptable, the server SHALL initiate configuration and is otherwise acceptable, the server <bcp14>SHALL</bc p14> initiate
a new connection to receive the Test Activation Request from the a new connection to receive the Test Activation Request from the
client, using a new UDP socket allocated from the UDP ephemeral port client, using a new UDP socket allocated from the UDP ephemeral port
range. This new socket will also be used for the subsequent Load and range. This new socket will also be used for the subsequent Load and
Status PDUs that are part of testing (with the port number Status PDUs that are part of testing (with the port number
communicated back to the client in testPort field of the Test Setup communicated back to the client in testPort field of the Test Setup
Response). Then, the server SHALL start a watchdog timer (to Response). Then, the server <bcp14>SHALL</bcp14> start a watchdog time
terminate the new connection if the client goes silent) and SHALL r (to
terminate the new connection if the client goes silent) and <bcp14>SHA
LL</bcp14>
send the Test Setup Response back to the client. The watchdog timer send the Test Setup Response back to the client. The watchdog timer
is set to the same value as on the Client side (see <xref is set to the same value as on the client side (see <xref target="Test
target="Test-Setup"/>)</t> -Setup" format="default"/>)</t>
<t>When the server replies to the Test Setup Request message, the <t>When the server replies to the Test Setup Request message, the
Test Setup Response PDU is structured identically to the Request PDU Test Setup Response PDU is structured identically to the Request PDU
and SHALL retain the original values received in it, with the and <bcp14>SHALL</bcp14> retain the original values received in it, wi th the
following exceptions:</t> following exceptions:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>The cmdRequest field is set to CHSR_CREQ_SETUPRSP, indicating <t>The cmdRequest field is set to CHSR_CREQ_SETUPRSP, indicating
a response.</t> a response.</t>
</li>
<li>
<t>The cmdResponse field is set to CHSR_CRSP_ACKOK, indicating <t>The cmdResponse field is set to CHSR_CRSP_ACKOK, indicating
an acknowledgment.</t> an acknowledgment.</t>
</li>
<li>
<t>The testPort field is set to the ephemeral port number to be <t>The testPort field is set to the ephemeral port number to be
used for the client's Test Activation Request and all subsequent used for the client's Test Activation Request and all subsequent
communication.</t> communication.</t>
</li>
<li>
<t>The authUnixTime field is updated to the current system <t>The authUnixTime field is updated to the current system
(wall-clock) time and, after the authDigest and checkSum fields (wall-clock) time and, after the authDigest and checkSum fields
are zeroed, the authDigest is recalculated and inserted. If the are 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.</t> calculated and inserted.</t>
</list></t> </li>
</ul>
<t>Finally, the new UDP connection associated with the new socket <t>Finally, the new UDP connection associated with the new socket
and port are made ready, and the server awaits further communication and port are made ready, and the server awaits further communication
there.</t> there.</t>
<t>To ensure that a server's local firewall will successfully allow <t>To ensure that a server's local firewall will successfully allow
packets received for the new ephemeral port, the server SHALL packets received for the new ephemeral port, the server <bcp14>SHALL</ bcp14>
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 <bcp14>SHALL</bcp14> be the new ephemeral port. This o peration
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 <bcp14>SHALL</bcp14> follow the Message Verificat
listed in <xref target="VerifyPDU"/>. Note that there is no response ion Procedure
listed in <xref target="VerifyPDU" format="default"/>. Note that there
is no response
to a Null Request.</t> to a Null Request.</t>
<t>The UDP PDU format layout <bcp14>SHALL</bcp14> be as follows (big-e
<t>The UDP PDU format layout SHALL be as follows (big-endian ndian
AB):</t> AB):</t>
<figure anchor="Null-Request">
<t><figure anchor="Null-Request" title="Null Request PDU Layout"> <name>Null Request PDU Layout</name>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
<postamble/>
</figure></t>
<t>Authentication and checksum fields follow the same methodology as <t>The authentication and checkSum fields follow the same methodology as
with the Setup Request and Response.</t> with the Setup Request and Response.</t>
<t>Additional details regarding the Null Request fields are as <t>Additional details regarding the Null Request fields are as
follows:</t> follows:</t>
<dl spacing="normal" newline="false">
<t>pduId: IANA is asked to assign the value hex 0xDEAD (<xref <dt>pduId:</dt><dd>IANA has assigned the hex value 0xDEAD (<xref targe
target="pduId"/>).</t> t="pduId" format="default"/>).</dd>
<dt>cmdRequest:</dt><dd>Set to CHNR_CREQ_NULLREQ to indicate a Null Re
<t>cmdRequest: Is set to CHNR_CREQ_NULLREQ indicating a Null Request quest
message.</t> message.</dd>
<dt>cmdResponse:</dt><dd>Set to CHNR_CRSP_NONE.</dd>
<t>cmdResponse: Is set to CHNR_CRSP_NONE.</t> <dt>authMode:</dt><dd>Same as in <xref target="Setup-Fields" format="d
efault"/>.</dd>
<t>authMode: Same as <xref target="Setup-Fields"/></t> <dt>authUnixTime:</dt><dd>Same as in <xref target="Setup-Fields" forma
t="default"/>.</dd>
<t>authUnixTime: Same as <xref target="Setup-Fields"/></t> <dt>authDigest:</dt><dd>Same as in <xref target="Setup-Fields" format=
"default"/>.</dd>
<t>authDigest: Same as <xref target="Setup-Fields"/></t> <dt>keyId:</dt><dd>Same as in <xref target="Setup-Fields" format="defa
ult"/>.</dd>
<t>keyId: Same as <xref target="Setup-Fields"/></t> <dt>reservedAuth1:</dt><dd>Same as in <xref target="Setup-Fields" form
at="default"/>.</dd>
<t>reservedAuth1: Same as <xref target="Setup-Fields"/></t> <dt>checkSum:</dt><dd>Same as in <xref target="Setup-Fields" format="d
efault"/>.</dd>
<t>checkSum: Same as <xref target="Setup-Fields"/></t> </dl>
<t>If a Test Activation Request is not subsequently received from <t>If a Test Activation Request is not subsequently received from
the client on the new ephemeral port number before the watchdog the client on the new ephemeral port number before the watchdog
timer expires, the server SHALL close the socket and deallocate the timer expires, the server <bcp14>SHALL</bcp14> close the socket and de allocate the
associated resources.</t> associated resources.</t>
<t>The Null Request message PDU <bcp14>SHALL</bcp14> be organized as f
<t>The Null Request message PDU SHALL be organized as follows:</t> ollows:</t>
<figure anchor="CHNR">
<t><figure anchor="CHNR" title="Null Request PDU"> <name>Null Request PDU</name>
<artwork> <sourcecode name="" type="c" markers="true"><![CDATA[
&lt;CODE BEGINS&gt;
// //
// Control header for UDP payload of Null Request PDU // Control header for UDP payload of Null Request PDU
// //
struct controlHdrNR { struct controlHdrNR {
#define CHNR_ID 0xDEAD #define CHNR_ID 0xDEAD
uint16_t pduId; // PDU ID uint16_t pduId; // PDU ID
uint16_t protocolVer; // Protocol version uint16_t protocolVer; // Protocol version
#define CHNR_CREQ_NONE 0 #define CHNR_CREQ_NONE 0
#define CHNR_CREQ_NULLREQ 1 // Null request #define CHNR_CREQ_NULLREQ 1 // Null request
uint8_t cmdRequest; // Command request uint8_t cmdRequest; // Command request
skipping to change at line 1359 skipping to change at line 1556
uint8_t cmdResponse; // Command response uint8_t cmdResponse; // Command response
uint8_t reserved1; // (reserved for alignment) uint8_t reserved1; // (reserved for alignment)
// ========== Integrity Verification ========== // ========== Integrity Verification ==========
uint8_t authMode; // Authentication mode uint8_t authMode; // Authentication mode
uint32_t authUnixTime; // Authentication timestamp uint32_t authUnixTime; // Authentication timestamp
uint8_t authDigest[AUTH_DIGEST_LENGTH]; uint8_t authDigest[AUTH_DIGEST_LENGTH];
uint8_t keyId; // Key ID in shared table uint8_t keyId; // Key ID in shared table
uint8_t reservedAuth1; // (reserved for alignment) uint8_t reservedAuth1; // (reserved for alignment)
uint16_t checkSum; // Header checksum uint16_t checkSum; // Header checksum
}; };
&lt;CODE ENDS&gt; ]]></sourcecode>
</artwork> </figure>
<postamble/>
</figure></t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Setup Response Processing at the Client"> <name>Setup Response Processing at the Client</name>
<t>When the client receives the Test Setup Response message, it SHALL <t>When the client receives the Test Setup Response message, it <bcp14>S
first follow the Message Verification Procedure listed in <xref HALL</bcp14>
target="VerifyPDU"/>.</t> first follow the Message Verification Procedure listed in <xref target="
VerifyPDU" format="default"/>.</t>
<t>It SHALL then proceed to evaluate the other fields in the protocol, <t>The client <bcp14>SHALL</bcp14> then proceed to evaluate the other fi
elds in the protocol,
beginning with the protocol version, PDU ID (to validate the type of beginning with the protocol version, PDU ID (to validate the type of
message), and cmdRequest for the role of the message, which MUST be message), and cmdRequest for the role of the message, which <bcp14>MUST<
Test Setup Response, CHSR_CREQ_SETUPRSP, as indicated by <xref /bcp14> be
target="CHSR"/>.</t> Test Setup Response, CHSR_CREQ_SETUPRSP, as indicated by <xref target="C
HSR" format="default"/>.</t>
<t>If the cmdResponse value indicates an error (values greater than <t>If the cmdResponse value indicates an error (values greater than
CHSR_CRSP_ACKOK) the client SHALL display/report a relevant message to CHSR_CRSP_ACKOK), the client <bcp14>SHALL</bcp14> display/report a relev ant message to
the user or management process and exit. If the client receives a 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 <bcp14>MUST</bcp14> terminate the connection and terminate op eration 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 <bcp14>SHALL</bcp14> com pose 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.</t> the test direction, the test duration, etc., as described below.</t>
</section> </section>
</section> </section>
<section anchor="Test-Activation" numbered="true" toc="default">
<section anchor="Test-Activation" <name>Test Activation Request and Response</name>
title="Test Activation Request and Response">
<t>This section is divided according to the sending and processing of <t>This section is divided according to the sending and processing of
the client, server, and again at the client.</t> the client and server and again at the client.</t>
<section anchor="Client-Gen-Activation" numbered="true" toc="default">
<section anchor="Client-Gen-Activation" <name>Client Generates Test Activation Request</name>
title="Client Generates Test Activation Request"> <t>Upon a successful setup exchange, the client <bcp14>SHALL</bcp14> com
<t>Upon a successful setup exchange, the client SHALL compose and send pose 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).</t> not the standard UDPSTP port).</t>
<t>The UDP PDU format layout is as follows (big-endian AB):</t> <t>The UDP PDU format layout is as follows (big-endian AB):</t>
<figure anchor="Test-Activation-PDU">
<t><figure anchor="Test-Activation-PDU" <name>Test Activation PDU Layout</name>
title="Test Activation PDU Layout"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork> 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 line 1450 skipping to change at line 1638
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
<postamble/>
</figure></t>
<t>Fields are populated based on default values or command-line <t>Fields are populated based on default values or command-line
options. Authentication and checksum fields follow the same options. The authentication and checkSum fields follow the same
methodology as with the Setup Request and Response.</t> methodology as with the Setup Request and Response.</t>
<dl spacing="normal" newline="false">
<t>pduId: IANA is asked to assign the value hex 0xACE2 (<xref <dt>pduId:</dt><dd>IANA has assigned the hex value 0xACE2 (<xref target=
target="pduId"/>).</t> "pduId" format="default"/>).</dd>
<dt>cmdRequest:</dt><dd>Set to CHTA_CREQ_TESTACTUS to indicate an upstre
<t>cmdRequest: Is set to CHTA_CREQ_TESTACTUS to indicate an upstream am
test activation or alternatively to CHTA_CREQ_TESTACTDS to indicate a test 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 unused.
See <xref target="ActivationCmdRequest"/>.</t> See <xref target="ActivationCmdRequest" format="default"/>.</dd>
<dt>cmdResponse:</dt><dd>Three CHTA_CRSP_&lt;Indication&gt; values are d
efined;
see <xref target="CHTA" format="default"/>.</dd>
<t>cmdResponse: three CHTA_CRSP_&lt;Indication&gt; values are defined, <!--[rfced] Section 6.1. We are having trouble parsing these
see <xref target="CHTA"/>.</t> sentences. May we update as shown below for clarity?
<t>lowThresh: Two two-octet field, low threshold Low on the Range of Original:
Round Trip Time variation, RTT (Range is values above minimum RTT, see lowThresh: Two two-octet field, low threshold Low on the Range of
also Table 3 <xref target="TR-471"/>.</t> Round Trip Time variation, RTT (Range is values above minimum RTT, see
also Table 3 [TR-471].
<t>upperThresh: Two two-octet field, upper threshold Low on the Range upperThresh: Two two-octet field, upper threshold Low on the Range
of 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 <xref target="TR-471"/>.</t> RTT, see also Table 3 of [TR-471].
<t>trialInt: A two-octet field, indicating the Status Feedback / trial Perhaps:
lowThresh: Two two-octet fields, with a low threshold Low on the
Range of Round-Trip Time (RTT) variation (the range is composed
of values above the minimum RTT); see also Table 3 [TR-471].
upperThresh: Two two-octet fields, with an upper threshold Low on
the Range of RTT variation (the range is composed of values above
the minimum RTT); see also Table 3 of [TR-471].
-->
<dt>lowThresh:</dt><dd>Two two-octet fields, low threshold Low on the Ra
nge of
Round Trip Time variation, RTT (Range is values above minimum RTT); see
also Table 3 <xref target="TR-471" format="default"/>.</dd>
<dt>upperThresh:</dt><dd>Two two-octet fields, upper threshold Low on th
e Range
of Round Trip Time variation, RTT (Range is values above minimum RTT);
see also Table 3 of <xref target="TR-471" format="default"/>.</dd>
<dt>trialInt:</dt><dd>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 number
of sub-intervals dt, and each sub-interval is further divided into a of sub-intervals dt, and each sub-interval is further divided into a
number of trial intervals (see <xref target="TR-471"/>). Starts by 1 number of trial intervals (see <xref target="TR-471" format="default"/>) . Starts by 1
and is continuously incremented during a single test interval and is continuously incremented during a single test interval
(testIntTime).</t> (testIntTime).</dd>
<dt>testIntTime:</dt><dd>A two-octet field. Duration of the test (either
<t>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 the
maximum duration of the search process in Seconds (see also maximum duration of the search process in seconds (see also
TestInterval, Table 3 of <xref target="TR-471"/>.</t> TestInterval in Table 3 of <xref target="TR-471" format="default"/>).</d
d>
<t>dscpEcn: Diffserv code point and ECN field, see also the DSCP field <dt>dscpEcn:</dt><dd>Diffserv code point and ECN field; see also the DSC
specified by <xref target="TR-471"/>. This specification does not P field
provide an ECN-capable transport, therefore the sender SHALL set the specified by <xref target="TR-471" format="default"/>. This specificatio
ECN field to not_ECT.</t> n does not
provide an ECN-capable transport; therefore, the sender <bcp14>SHALL</bc
<t>srIndexConf: A two-octet field. The requested Configured Sending p14> set the
ECN field to not_ECT.</dd>
<dt>srIndexConf:</dt><dd>A two-octet field. The requested Configured Sen
ding
Rate Table index, used in a Test Activation Request, of the desired Rate Table index, used in a Test Activation Request, of the desired
fixed or starting sending rate (depending on whether fixed or starting sending rate (depending on whether
CHTA_SRIDX_ISSTART is cleared or set respectively). Because a value of CHTA_SRIDX_ISSTART is cleared or set, respectively). Because a value of
zero is a valid fixed or starting sending rate index, the field SHALL zero is a valid fixed or starting sending rate index, the field <bcp14>S
HALL</bcp14>
be set to its maximum (CHTA_SRIDX_DEF) when requesting the default be set to its maximum (CHTA_SRIDX_DEF) when requesting the default
behavior of the server (starting the selected load rate adjustment behavior of the server (starting with the selected load rate adjustment
algorithm at its minimum/zero index). This SHALL be equivalent to algorithm at its minimum/zero index). This <bcp14>SHALL</bcp14> be equiv
alent to
setting srIndexConf to zero and setting the CHTA_SRIDX_ISSTART setting srIndexConf to zero and setting the CHTA_SRIDX_ISSTART
bit.</t> bit.</dd>
<dt>useOwDelVar:</dt><dd>A one-octet field. Boolean, default True (if Fa
<t>useOwDelVar: A one-octet field. Boolean, default True (False: Use lse, use
RTT=round-trip delay variation in the load rate adjustment RTT=round-trip delay variation in the load rate adjustment
algorithm)(True: EnableIPDV which uses one-way delay variation for the algorithm; if True, use EnableIPDV, which uses one-way delay variation f
load rate adjustment algorithm), see EnableIPDV in Table 1 of <xref or the
target="TR-471"/>.</t> load rate adjustment algorithm). See EnableIPDV in Table 1 of <xref targ
et="TR-471" format="default"/>.</dd>
<dt>highSpeedDelta:</dt><dd>A one-octet field; see <xref section="A" tar
get="RFC9097" format="default"/>.</dd>
<dt>slowAdjThresh and seqErrThresh:</dt><dd>Two two-octet fields; see
<xref section="A" target="RFC9097" format="default"/>.</dd>
<t>highSpeedDelta: A one-octet field, see Appendix A of <xref <!--[rfced] We note that the following sentences refer to "Loss,
target="RFC9097"/>.</t> Reordering, and Duplication" differently. Please let us know
if/how they can be updated for consistency (perhaps "loss,
out-of-order, and duplicate totals").
<t>slowAdjThresh, seqErrThresh: Two two-octet fields, see Appendix A In addition, under Section 6.1, we updated "default true" to "default
of <xref target="RFC9097"/>.</t> is True". Please let us know if this changes the intended meaning.
<t>ignoreOooDup: A one-octet field. Ignore out of oder duplicates, Original:
Boolean. When True only Loss counts toward received packet sequence (Section 6.1)
number errors. When False, Loss, Reordering and Duplication are all ignoreOooDup: ... 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
<xref target="TR-471"/>).</t> True (see also Table 3 of [TR-471]).
<t>modifierBitmap: A one-octet field. This document only assigns two (Section 7.1)
bits in this bitmap, see <xref lpduSeqNo: A four-octet field indicating the Load PDU sequence
target="Activation-modifierBitmap"/>:</t> number (starting at 1). Used to determine loss, out-of-order,
and duplicates.
<t><list style="hanging"> (Section 7.2)
<t hangText="CHTA_SRIDX_ISSTART">Treat srIndexConf as the starting seqErrLoss/seqErrOoo/seqErrDup: Three four-octet fields,
sending rate to be used by the load rate adjustment algorithm</t> populated by the Loss, out-of-order, and duplicate totals.
<t hangText="CHTA_RAND_PAYLOAD">Randomize the Payload Content Perhaps:
beyond the Load PDU header</t> (Section 6.1)
</list>Other bit positions are left unassigned by this document.</t> ignoreOooDup: ... When False, loss, out-of-order, and
duplicate totals are all counted as sequence number errors;
default is True (see also Table 3 of [TR-471]).
<t>rateAdjAlgo: A one-octet field. The applied Load Rate Adjustment (Section 7.1)
Algorithm, see <xref target="Activation-rateAdjAlgo"/>.</t> lpduSeqNo: A four-octet field indicating the Load PDU sequence
number (starting at 1). Used to determine loss, out-of-order,
and duplicate totals.
<t>Sending Rate structure (srStruct), used by the server in a Test (Section 7.2)
Activation Response for an upstream test, to communicate the (initial) seqErrLoss/seqErrOoo/seqErrDup: Three four-octet fields
Load PDU transmission parameters the client SHALL use. For a Test populated by the loss, out-of-order, and duplicate totals.
Activation Request or a downstream test, this structure SHALL be -->
<dt>ignoreOooDup:</dt><dd>A one-octet field. Ignore out-of-order duplica
tes,
Boolean. When True, only Loss counts toward received packet sequence
number errors. When False, Loss, Reordering, and Duplication are all
counted as sequence number errors; default True (see also Table 3 of
<xref target="TR-471" format="default"/>).</dd>
<dt>modifierBitmap:</dt><dd><t>A one-octet field. This document only ass
igns two
bits in this bitmap; see <xref target="Activation-modifierBitmap" format
="default"/>:</t>
<dl newline="false" spacing="normal">
<dt>CHTA_SRIDX_ISSTART:</dt>
<dd>Treat srIndexConf as the starting
sending rate to be used by the load rate adjustment algorithm.</dd>
<dt>CHTA_RAND_PAYLOAD:</dt>
<dd>Randomize the payload content
beyond the Load PDU header.</dd>
</dl></dd></dl>
<t>Other bit positions are left unassigned per this document.</t>
<dl spacing="normal" newline="false">
<dt>rateAdjAlgo:</dt><dd>A one-octet field. The applied load rate adjust
ment
algorithm; see <xref target="Activation-rateAdjAlgo" format="default"/>.
</dd>
</dl>
<t>srStruct: Sending Rate structure. Used by the server in a Test
Activation Response for an upstream test to communicate the (initial)
Load PDU transmission parameters the client <bcp14>SHALL</bcp14> use. Fo
r a Test
Activation Request or a downstream test, this structure <bcp14>SHALL</bc
p14> be
zeroed. Two sets of periodic transmission parameters are available, zeroed. Two sets of periodic transmission parameters are available,
allowing for dual independent transmitters (to support a high degree allowing for dual independent transmitters (to support a high degree
of rate granularity). The fields are defined as follows:</t> of rate granularity). The fields are defined as follows:</t>
<dl spacing="normal" newline="false">
<t>txInterval1 and txInterval2: Two four-octet fields indicating the <dt>txInterval1 and txInterval2:</dt><dd>Two four-octet fields indicatin
g 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.</t> recommended for optimal rate selection.</dd>
<dt>udpPayload1 and udpPayload2:</dt><dd>Two four-octet fields indicatin
<t>udpPayload1 and udpPayload2: Two four-octet fields indicating the g the
UDP payload at load rate in [byte].</t> UDP payload at load rate in [byte].</dd>
<dt>burstSize1 and burstSize2:</dt><dd>Two four-octet fields indicating
<t>burstSize1 and burstSize2: Two four-octet fields indicating the the
burst size at load rate by a dimensionless number (of datagrams).</t> burst size at load rate by a dimensionless number (of datagrams).</dd>
<dt>udpAddon2:</dt><dd>A four-octet field indicating the size of a singl
<t>udpAddon2: A four-octet field indicating the size of a single Load e 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 when
udpPayload2 or burstSize2 are zero and result in no transmission of udpPayload2 or burstSize2 are zero and result in no transmission of
their own.</t> their own.</dd>
<dt>subIntPeriod:</dt><dd>A two-octet field. Test Sub-interval period in
<t>subIntPeriod: A two-octet field. Test Sub-interval period in [ms], [ms]
(see also Table 3 of <xref target="TR-471"/>). Trials with (see also Table 3 of <xref target="TR-471" format="default"/>). Trials w
ith
subIntPeriod in a range of 100 to 10000 [ms] resulted in a default subIntPeriod in a range of 100 to 10000 [ms] resulted in a default
value of 1000 ms.</t> value of 1000 ms.</dd>
<dt>authMode:</dt><dd>Same as in <xref target="Setup-Fields" format="def
<t>authMode: Same as <xref target="Setup-Fields"/></t> ault"/>.</dd>
<dt>authUnixTime:</dt><dd>Same as in <xref target="Setup-Fields" format=
<t>authUnixTime: Same as <xref target="Setup-Fields"/></t> "default"/>.</dd>
<dt>authDigest:</dt><dd>Same as in <xref target="Setup-Fields" format="d
<t>authDigest: Same as <xref target="Setup-Fields"/></t> efault"/>.</dd>
<dt>keyId:</dt><dd>Same as in <xref target="Setup-Fields" format="defaul
<t>keyId: Same as <xref target="Setup-Fields"/></t> t"/>.</dd>
<dt>reservedAuth1:</dt><dd>Same as in <xref target="Setup-Fields" format
<t>reservedAuth1: Same as <xref target="Setup-Fields"/></t> ="default"/>.</dd>
<dt>checkSum:</dt><dd>Same as in <xref target="Setup-Fields" format="def
<t>checkSum: Same as <xref target="Setup-Fields"/></t> ault"/>.</dd>
</dl>
<t>The Test Activation Request/Response message PDU (as well as the <t>The Test Activation Request/Response message PDU (as well as the
included Sending Rate structure) SHALL be organized as follows:</t> included Sending Rate structure) <bcp14>SHALL</bcp14> be organized as fo
llows:</t>
<t><figure anchor="CHTA" title="Test Activation PDU"> <figure anchor="CHTA">
<artwork> <name>Test Activation PDU</name>
&lt;CODE BEGINS&gt; <sourcecode name="" type="c" markers="true"><![CDATA[
// //
// Sending rate structure for a single row of transmission parameters // Sending rate structure for a single row of transmission parameters
// //
struct sendingRate { struct sendingRate {
uint32_t txInterval1; // Transmit interval (us) uint32_t txInterval1; // Transmit interval (us)
uint32_t udpPayload1; // UDP payload (bytes) uint32_t udpPayload1; // UDP payload (bytes)
uint32_t burstSize1; // UDP burst size per interval uint32_t burstSize1; // UDP burst size per interval
uint32_t txInterval2; // Transmit interval (us) uint32_t txInterval2; // Transmit interval (us)
uint32_t udpPayload2; // UDP payload (bytes) uint32_t udpPayload2; // UDP payload (bytes)
uint32_t burstSize2; // UDP burst size per interval uint32_t burstSize2; // UDP burst size per interval
skipping to change at line 1621 skipping to change at line 1842
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 line 1649 skipping to change at line 1870
uint16_t reserved4; // (reserved for alignment) uint16_t reserved4; // (reserved for alignment)
uint8_t reserved5; // (reserved for alignment) uint8_t reserved5; // (reserved for alignment)
// ========== Integrity Verification ========== // ========== Integrity Verification ==========
uint8_t authMode; // Authentication mode uint8_t authMode; // Authentication mode
uint32_t authUnixTime; // Authentication timestamp uint32_t authUnixTime; // Authentication timestamp
uint8_t authDigest[AUTH_DIGEST_LENGTH]; uint8_t authDigest[AUTH_DIGEST_LENGTH];
uint8_t keyId; // Key ID in shared table uint8_t keyId; // Key ID in shared table
uint8_t reservedAuth1; // (reserved for alignment) uint8_t reservedAuth1; // (reserved for alignment)
uint16_t checkSum; // Header checksum uint16_t checkSum; // Header checksum
}; };
&lt;CODE ENDS&gt; ]]></sourcecode>
</artwork> </figure>
<postamble/>
</figure></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Server Processes Test Activation Request and Generates Res <name>Server Processes Test Activation Request and Generates Response</n
ponse"> ame>
<t>After the server receives the Test Activation Request on the new <t>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 to message, the Test Activation Response PDU is structured identically to
the Request PDU and SHALL retain the original values received in it the Request PDU and <bcp14>SHALL</bcp14> retain the original values rece
unless they are explicitly coerced to a server acceptable value.</t> ived in it
unless they are explicitly coerced to a server-acceptable value.</t>
<t>When the server receives the Test Activation Request message, it <t>When the server receives the Test Activation Request message, it
SHALL first follow the Message Verification Procedure listed in <xref <bcp14>SHALL</bcp14> first follow the Message Verification Procedure lis
target="VerifyPDU"/>.</t> ted in <xref target="VerifyPDU" format="default"/>.</t>
<section numbered="true" toc="default">
<section title="Server Rejects or Modifies Request"> <name>Server Rejects or Modifies Request</name>
<t>When evaluating the Test Activation Request, the server MAY allow <t>When evaluating the Test Activation Request, the server <bcp14>MAY<
/bcp14> allow
the client to specify its own fixed or starting send rate via the client to specify its own fixed or starting send rate via
srIndexConf.</t> srIndexConf.</t>
<t>Alternatively, the server <bcp14>MAY</bcp14> enforce a maximum limi
<t>Alternatively, the server MAY enforce a maximum limit of the t of the
fixed or starting send rate which the client can successfully fixed or starting send rate, which the client can successfully
request. If the client's Test Activation Request exceeds the request. If the client's Test Activation Request exceeds the
server's configured maximum, the server MUST either reject the server's configured maximum, the server <bcp14>MUST</bcp14> either rej ect the
request or coerce the value to the configured maximum bit rate, and request or coerce the value to the configured maximum bit rate, and
communicate that maximum to the client in the Test Activation communicate that maximum to the client in the Test Activation
Response. The client can of course choose to end the test, as Response. The client can of course choose to end the test, as
appropriate.</t> appropriate.</t>
<t>Other parameters where the server has the OPTION to coerce the <t>Other parameters where the server has the OPTION to coerce the
client to use values other than those in the Test Activation Request client to use values other than those in the Test Activation Request
are (grouped by role):</t> are (grouped by role):</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Load rate adjustment algorithm: lowThresh, upperThresh, <t>Load rate adjustment algorithm: lowThresh, upperThresh,
useOwDelayVar, highSpeedDelta, slowAdjThresh, seqErrThresh, useOwDelayVar, highSpeedDelta, slowAdjThresh, seqErrThresh,
highSpeedDelta, ignoreOooDup, rateAdjAlgo.</t> highSpeedDelta, ignoreOooDup, rateAdjAlgo</t>
</li>
<li>
<t>Test duration/intervals: trialInt, testIntTime, <t>Test duration/intervals: trialInt, testIntTime,
subIntPeriod</t> subIntPeriod</t>
</li>
<li>
<t>Packet marking: dscpEcn</t> <t>Packet marking: dscpEcn</t>
</list>Coercion is a step towards performing a test with the </li>
</ul>
<t>Coercion is a step towards performing a test with the
server-configured values; even though the client might prefer server-configured values; even though the client might prefer
certain values, the server gives the client an opportunity to run a certain values, the server gives the client an opportunity to run a
test with different values than the preferred set. In these cases, test with different values than the preferred set. In these cases,
the Command Response value SHALL be CHTA_CRSP_ACKOK.</t> the Command Response value <bcp14>SHALL</bcp14> be CHTA_CRSP_ACKOK.</t
>
<t>Note that the server also has the option of completely rejecting <t>Note that the server also has the option of completely rejecting
the request and sending back an appropriate cmdResponse field value the request and sending back an appropriate cmdResponse field value
(currently only CHTA_CRSP_BADPARAM, see <xref (currently only CHTA_CRSP_BADPARAM; see <xref target="Activation-cmdRe
target="Activation-cmdResponse"/>).</t> sponse" format="default"/>).</t>
<t>Whether this error response is sent or not depends on the <t>Whether this error response is sent or not depends on the
Security mode of operation and the outcome of authDigest security mode of operation and the outcome of authDigest
validation.</t> validation.</t>
<t>If the Test Activation Request must be rejected (due to the <t>If the Test Activation Request must be rejected (due to the
Command Response value being CHTA_CRSP_BADPARAM), and</t> Command Response value being CHTA_CRSP_BADPARAM), and</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>If the authDigest is valid, a Test Activation Response SHALL <t>If the authDigest is valid, a Test Activation Response <bcp14>S
be sent back to the client with a corresponding command response HALL</bcp14>
be sent back to the client with a corresponding Command Response
value indicating the reason for the rejection.</t> value indicating the reason for the rejection.</t>
</li>
<t>If the authDigest is invalid, then the Test Activation <li>
Request SHOULD fail silently. The exception is for operations <t>If the authDigest is invalid, the Test Activation
support: server administrators are permitted to send a Request <bcp14>SHOULD</bcp14> fail silently. The exception is for
operations
support: server administrators are permitted to send an
Activation Response to support operations and Activation Response to support operations and
troubleshooting.</t> troubleshooting.</t>
</list></t> </li>
</ul>
<t>The additional circumstances when a server SHALL NOT communicate <t>The additional circumstances when a server <bcp14>SHALL NOT</bcp14>
communicate
the appropriate Command Response code for an error condition (fail the appropriate Command Response code for an error condition (fail
silently) are when: <list style="numbers"> silently) are when: </t>
<ul spacing="normal"><li>
<t>the Test Activation Request PDU size is not equal to the <t>the Test Activation Request PDU size is not equal to the
'struct controlHdrTA' size shown in <xref target="CHTA"/>,</t> 'struct controlHdrTA' size shown in <xref target="CHTA" format="de
fault"/>,</t>
</li>
<li>
<t>the PDU ID is not 0xACE2 (Test Activation PDU), or</t> <t>the PDU ID is not 0xACE2 (Test Activation PDU), or</t>
</li>
<t>a directed attack has been detected,</t> <li>
</list>in which case the server will allow Test Activation <t>a directed attack has been detected.</t>
</li>
</ul>
<t>In this case, the server will allow Test Activation
Requests to terminate silently. Attack detection is beyond the scope Requests to terminate silently. Attack detection is beyond the scope
of this specification.</t> of this specification.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Server Accepts Request and Generates Response</name>
<t>When the server sends the Test Activation Response, it <bcp14>SHALL
</bcp14> set
the cmdResponse field to CHTA_CRSP_ACKOK (see <xref target="Activation
-cmdResponse" format="default"/>).</t>
<t>If the client has requested an upstream test, the server
<bcp14>SHALL</bcp14>:</t>
<ul spacing="normal">
<li>
<section title="Server Accepts Request and Generates Response"> <!--[rfced] May we clarify the text in parentheses as shown below
<t>When the server sends the Test Activation Response, it SHALL set (i.e., update "having been set to CHTA_SRIDX_DEF" to "and if the
the cmdResponse field to CHTA_CRSP_ACKOK (see <xref parameters were set to CHTA_SRIDX_DEF")? Note that there are two
target="Activation-cmdResponse"/>)</t> instances in the text.
<t>If the client has requested an upstream test, the server Original:
SHALL:</t> * include the transmission parameters from the first row of the
Sending Rate Table in the Sending Rate structure (if requested by
srIndexConf having been set to CHTA_SRIDX_DEF), or
Perhaps:
* include the transmission parameters from the first row of the
Sending Rate Table in the Sending Rate structure (if requested by
srIndexConf and if the parameters were set to CHTA_SRIDX_DEF), or
-->
<t><list style="symbols">
<t>include the transmission parameters from the first row of the <t>include the transmission parameters from the first row of the
Sending Rate Table in the Sending Rate structure (if requested Sending Rate Table in the Sending Rate structure (if requested
by srIndexConf having been set to CHTA_SRIDX_DEF), or</t> by srIndexConf having been set to CHTA_SRIDX_DEF), or</t>
</li>
<li>
<t>include the transmission parameters from the designated <t>include the transmission parameters from the designated
Configured Sending Rate Table index (srIndexConf) of the Sending Configured Sending Rate Table index (srIndexConf) of the Sending
Rate Table where, if CHTA_SRIDX_ISSTART is set in Rate Table where, if CHTA_SRIDX_ISSTART is set in
modifierBitmap, this will be used as the starting rate for the modifierBitmap, this will be used as the starting rate for the
load rate adjustment algorithm, else it will be considered a load rate adjustment algorithm; else, it will be considered a
fixed-rate test.</t> fixed-rate test.</t>
</list></t> </li>
</ul>
<t>When generating the Test Activation Response (acceptance) for a <t>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 <bcp14>SHALL</bcp14> set all octets of the Sending Rate
structure to zero.</t> structure to zero.</t>
<t>If activation continues, the server prepares the new connection <t>If activation continues, the server prepares the new connection
for an upstream OR downstream test.</t> for an upstream OR downstream test.</t>
<t>In the case of an upstream test, the server <bcp14>SHALL</bcp14> pr
<t>In the case of an upstream test, the server SHALL prepare to use epare to use
a single timer to send Status PDUs at the specified interval. For a 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 <bcp14>SHALL</bcp14> prepare to utilize du
send Load PDUs based on</t> al timers to
send Load PDUs based on:</t>
<t><list style="symbols"> <ul spacing="normal">
<li>
<t>the transmission parameters directly from the first row of <t>the transmission parameters directly from the first row of
the Sending Rate Table (if requested by srIndexConf having been the Sending Rate Table (if requested by srIndexConf having been
set to CHTA_SRIDX_DEF), or</t> set to CHTA_SRIDX_DEF), or</t>
</li>
<li>
<t>the transmission parameters from the designated Configured <t>the transmission parameters from the designated Configured
Sending Rate Table index (srIndexConf) of the Sending Rate Table Sending Rate Table index (srIndexConf) of the Sending Rate Table
where, if CHTA_SRIDX_ISSTART is set in modifierBitmap, this will where, if CHTA_SRIDX_ISSTART is set in modifierBitmap, this will
be used as the starting rate for the load rate adjustment be used as the starting rate for the load rate adjustment
algorithm, else it will be considered a fixed-rate test.</t> algorithm; else, it will be considered a fixed-rate test.</t>
</list></t> </li>
</ul>
<t>The server SHALL then send the Test Activation Response back to <t>The server <bcp14>SHALL</bcp14> then send the Test Activation Respo
nse back to
the client, update the watchdog timer with a new timeout value, and the client, update the watchdog timer with a new timeout value, and
set a test duration timer to eventually stop the test.</t> set a test duration timer to eventually stop the test.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Client Processes Test Activation Response"> <name>Client Processes Test Activation Response</name>
<t>When the client receives the Test Activation Response message, it <t>When the client receives the Test Activation Response message, it
SHALL first follow the Message Verification Procedure listed in <xref <bcp14>SHALL</bcp14> first follow the Message Verification Procedure lis
target="VerifyPDU"/>.</t> ted in <xref target="VerifyPDU" format="default"/>.</t>
<t>After the client receives the (vetted) Test Activation Response, it <t>After the client receives the (vetted) Test Activation Response, it
first checks the command response value.</t> first checks the Command Response value.</t>
<!--[rfced] We are having trouble parsing "SHALL display/report a
relevant message to the ... management process". Is "process"
essential to the sentence? Please let us know how we may update
the text for clarity.
Original:
If the client receives a Test Activation cmdResponse field value that
indicates an error, the client SHALL display/report a relevant
message to the user or management process and exit.
Perhaps:
If the client receives a Test Activation cmdResponse field value that
indicates an error, the client SHALL display/report a relevant
message to the user or management and exit.
-->
<t>If the client receives a Test Activation cmdResponse field value <t>If the client receives a Test Activation cmdResponse field value
that indicates an error, the client SHALL display/report a relevant that indicates an error, the client <bcp14>SHALL</bcp14> display/report a relevant
message to the user or management process and exit.</t> message to the user or management process and exit.</t>
<t>If the client receives a Test Activation cmdResponse field value <t>If the client receives a Test Activation cmdResponse field value
that is not equal to one of the codes defined in <xref that is not equal to one of the codes defined in <xref target="Activatio
target="Activation-cmdResponse"/>, the client MUST terminate the n-cmdResponse" format="default"/>, the client <bcp14>MUST</bcp14> terminate the
connection and terminate operation of the current setup procedure.</t> connection and terminate operation of the current setup procedure.</t>
<t>If the client receives a Test Activation Command Response value <t>If the client receives a Test Activation Command Response value
that indicates success (CHTA_CRSP_ACKOK, see <xref that indicates success (e.g., CHTA_CRSP_ACKOK; see <xref target="Activat
target="Activation-cmdResponse"/>), the client SHALL update its ion-cmdResponse" format="default"/>), the client <bcp14>SHALL</bcp14> update its
configuration to use any test parameters modified by the server. If configuration to use any test parameters modified by the server. If
the setup parameters coerced by the server are not acceptable to the the setup parameters coerced by the server are not acceptable to the
client, the client ends the test.</t> client, the client ends the test.</t>
<t>To finalize an accepted test activation, the client <bcp14>SHALL</bcp
<t>To finalize an accepted test activation, the client SHALL prepare 14> prepare
its connection for either an upstream test with dual timers set to its connection for either an upstream test with dual timers set to
send Load PDUs (based on the starting transmission parameters sent by send Load PDUs (based on the starting transmission parameters sent by
the server), OR a downstream test with a single timer to send Status the server) OR a downstream test with a single timer to send Status
PDUs at the specified interval.</t> PDUs at the specified interval.</t>
<t>Then, the client <bcp14>SHALL</bcp14> stop the test initiation timer
<t>Then, the client SHALL stop the test initiation timer and start a and start a
watchdog timer to detect if the server goes quiet.</t> watchdog timer to detect if the server goes quiet.</t>
<t>The connection is now ready for testing.</t> <t>The connection is now ready for testing.</t>
</section> </section>
</section> </section>
<section anchor="Test-Measurement" numbered="true" toc="default">
<section anchor="Test-Measurement" <name>Test Load Stream Transmission and Measurement Status Feedback Messag
title="Test Load Stream Transmission and Measurement Status Fe es</name>
edback Messages"> <t>This section describes the Data phase of the protocol. The roles of
<t>This section describes the data phase of the protocol. The roles of
sender and receiver vary depending on whether the direction of testing sender and receiver vary depending on whether the direction of testing
is from server to client, or the reverse.</t> is from server to client, or the reverse.</t>
<section numbered="true" toc="default" anchor="load_pdu_roles">
<section title="Load PDU and Roles"> <name>Load PDU and Roles</name>
<t>Testing proceeds with one endpoint sending Load PDUs, based on <t>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 Feedback conditions at the receiver. When the server is sending Status Feedback
messages, they will also contain the latest transmission parameters messages, they will also contain the latest transmission parameters
from the Sending Rate Table that the client SHALL use.</t> from the Sending Rate Table that the client <bcp14>SHALL</bcp14> use.</t
>
<t>When a Load PDU is received, the receiver SHALL first:</t> <t>When a Load PDU is received, the receiver <bcp14>SHALL</bcp14> do the
following:</t>
<t><list style="numbers"> <ol spacing="normal" type="1"><li>
<t>Verify that the size of the message is greater than or equal to <t>Verify that the size of the message is greater than or equal to
the 'struct loadHdr' size shown in <xref target="LoadPDU"/>.</t> the 'struct loadHdr' size shown in <xref target="LoadPDU" format="de
fault"/>.</t>
<t>If the optional checkSum field is being utilized, validate the </li>
<li>
<t>Validate the
checksum for the Load PDU header portion of the total message (as checksum for the Load PDU header portion of the total message (as
described in <xref target="Checksum"/>).</t> described in <xref target="Checksum" format="default"/>) if the opti
onal
checkSum field is being utilized.</t>
</li>
<li>
<t>Confirm that the PDU ID is 0xBEEF (Load PDU).</t> <t>Confirm that the PDU ID is 0xBEEF (Load PDU).</t>
</list>Note: If any of the above checks fail, the message SHALL be </li>
</ol>
<t>Note: If any of the above checks fail, the message <bcp14>SHALL</bcp1
4> be
considered invalid.</t> considered invalid.</t>
<t>The watchdog timer at the receiver <bcp14>SHALL</bcp14> be reset each
<t>The watchdog timer at the receiver SHALL be reset each time a valid 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 <xref target="Test-Stop"/> for in use). See non-graceful test stop in <xref target="Test-Stop" format=" default"/> for
handling the watchdog timeout expiration at each endpoint. Note that handling the watchdog timeout expiration at each endpoint. Note that
the watchdog timer's purpose is to detect a connection failure or a the watchdog timer's purpose is to detect a connection failure or a
massive congestion condition only.</t> massive congestion condition only.</t>
<t>When the server is sending Load PDUs in the role of sender, it <t>When the server is sending Load PDUs in the role of sender, it
SHALL use the transmission parameters directly from the Sending Rate <bcp14>SHALL</bcp14> use the transmission parameters directly from the S ending Rate
Table via the index that is currently selected (which was indirectly Table via the index that is currently selected (which was indirectly
based on the feedback in its received Status Feedback messages).</t> based on the feedback in its received Status Feedback messages).</t>
<t>However, when the client is sending Load PDUs in the role of <t>However, when the client is sending Load PDUs in the role of
sender, it SHALL use the discreet transmission parameters that were sender, it <bcp14>SHALL</bcp14> 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.</t> the algorithm used to decide when and how to adjust the rate.</t>
<t>The server uses a load rate adjustment algorithm that evaluates
<t>The server uses a load rate adjustment algorithm which 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 the is the receiver, the information is communicated to the server via
periodic Status Feedback messages. When the server is the receiver, periodic Status Feedback messages. When the server is the receiver,
the information is used directly (although it is also communicated to the information is used directly (although it is also communicated to
the client via its periodic Status Feedback messages). This approach the client via its periodic Status Feedback messages). This approach
is unique to this protocol; it provides the ability to search for the is unique to this protocol; it provides the ability to search for the
Maximum IP Capacity and specify specific sender behaviors that are Maximum IP Capacity and specify specific sender behaviors that are
absent from other testing tools. Although the algorithm depends on the absent from other testing tools. Although the algorithm depends on the
protocol, it is not part of the protocol per se.</t> protocol, it is not part of the protocol per se.</t>
<t>The default algorithm (B; see <xref target="Y.1540" format="default"/
<t>The default algorithm (B, see <xref target="Y.1540"/>) has three >) has three
paths to its decision on the next sending rate:<list style="numbers"> paths to its decision on the next sending rate:</t>
<ol spacing="normal" type="1"><li>
<t>When there are no impairments present (no sequence errors and <t>When there are no impairments present (no sequence errors and
low delay variation), resulting in a sending rate increase.</t> low delay variation), resulting in a sending rate increase.</t>
</li>
<li>
<t>When there are low impairments present (no sequence errors but <t>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.</t> maintained.</t>
</li>
<li>
<t>When the impairment levels are above the thresholds set for <t>When the impairment levels are above the thresholds set for
this purpose and "congestion" is inferred, resulting in a sending this purpose and "congestion" is inferred, resulting in a sending
rate decrease.</t> rate decrease.</t>
</list></t> </li>
</ol>
<t>Algorithm B also has two modes for increasing/decreasing the <t>Algorithm B also has two modes for increasing/decreasing the
sending rate:<list style="symbols"> sending rate:</t>
<t>A high-speed mode (fast) to achieve high sending rates quickly, <ul spacing="normal">
but also back-off quickly when "congestion" is inferred from the <li>
<t>A high-speed mode (fast) to achieve high sending rates quickly
but that also backs off quickly when "congestion" is inferred from t
he
measurements. Consecutive feedback intervals that have a measurements. Consecutive feedback intervals that have a
supra-threshold count of sequence number anomalies and/or contain supra-threshold count of sequence number anomalies and/or contain
an upper delay variation threshold exception in all of the an 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.</t> <bcp14>SHALL</bcp14> be configurable with a default of 3 intervals.<
/t>
</li>
<li>
<t>A single-step (slow) mode where all rate adjustments use the <t>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 of table. The single-step mode continues after the first inference of
"congestion" from measured impairments.</t> "congestion" from measured impairments.</t>
</list></t> </li>
</ul>
<t>An <bcp14>OPTIONAL</bcp14> load rate adjustment algorithm (designated
C) has been
defined in <xref target="TR-471" format="default"/>.
<t>An OPTIONAL load rate adjustment algorithm (designated C) has been <!--[rfced] May we rephrase "adds the possibility to" to "provides the
defined in <xref target="TR-471"/>. Algorithm C operation and modes option to" for clarity?
Original:
Algorithm C operation and modes are similar to 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 mode
during a test (which improves the measurement accuracy in dynamic
or error-prone access, such as radio access).
Perhaps:
Algorithm C operation and modes are similar to B, but C uses
multiplicative increases in the fast mode to reach the gigabit
range quickly and provides the option to retry the fast mode
during a test (which improves the measurement accuracy in
dynamic or error-prone access, such as radio access).
-->
Algorithm C operation and modes
are similar to B, but C uses multiplicative increases in the fast mode are similar to B, but C uses multiplicative increases in the fast mode
to reach the Gigabit range quickly and adds the possibility to re-try to reach the gigabit range quickly and adds the possibility to re-try
the fast mode during a test (which improves the measurement accuracy the fast mode during a test (which improves the measurement accuracy
in dynamic or error-prone access, such as radio access).</t> in dynamic or error-prone access, such as radio access).</t>
<t>On the other hand, the test configuration <bcp14>MAY</bcp14> use a fi
<t>On the other hand, the test configuration MAY use a fixed sending xed sending
rate requested by the client, using the field srIndexConf.</t> rate requested by the client, using the field srIndexConf.</t>
<t>The client <bcp14>MAY</bcp14> communicate the desired fixed rate in i
<t>The client MAY communicate the desired fixed-rate in its test ts Test
activation request.</t> Activation Request.</t>
<t>The UDP PDU format layout <bcp14>SHALL</bcp14> be as follows (big-end
<t>The UDP PDU format layout SHALL be as follows (big-endian AB):</t> ian AB):</t>
<figure anchor="Load-PDU">
<t><figure anchor="Load-PDU" title="Load PDU Layout"> <name>Load PDU Layout</name>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lpduTime_sec | | lpduTime_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lpduTime_nsec | | lpduTime_nsec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rttRespDelay | checkSum | | rttRespDelay | checkSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Payload Content... . . Payload Content... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
<postamble/>
</figure></t>
<t>Specific details regarding Load PDU fields are as follows:</t> <t>Specific details regarding Load PDU fields are as follows:</t>
<dl spacing="normal" newline="false">
<t>pduId: IANA is asked to assign the value hex 0xBEEF (<xref <dt>pduId:</dt><dd>IANA has assigned the hex value 0xBEEF (<xref target=
target="pduId"/>).</t> "pduId" format="default"/>).</dd>
<dt>testAction:</dt><dd>A one-octet field designating the current test a
<t>testAction: A one-octet fileld designating the current test action ction
as either TEST_ACT_TEST (testing in progress), TEST_ACT_STOP1 (first as 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 server
and reciprocated by client). See <xref target="Test-Stop"/> for and reciprocated by client). See <xref target="Test-Stop" format="defaul
additional information on test termination.</t> t"/> for
additional information on test termination.</dd>
<t>rxStopped: A one-octet fileld. Boolean, 0 or 1, used to indicate to <dt>rxStopped:</dt><dd>A one-octet field. Boolean, 0 or 1, used to indic
ate to
the remote endpoint that local receive traffic (either Load or Status the remote endpoint that local receive traffic (either Load or Status
PDUs) has stopped. All outgoing Load or Status PDUs SHALL continue to PDUs) has stopped. All outgoing Load or Status PDUs <bcp14>SHALL</bcp14> continue to
assert this indication until traffic is received again, or the test is assert this indication until traffic is received again, or the test is
terminated. The time threshold to trigger this condition is expected terminated. The time threshold to trigger this condition is expected
to be a reasonable fraction of the watchdog timeout (a default of one to be a reasonable fraction of the watchdog timeout (a default of one
second is recommended).</t> second is recommended).</dd>
<t>lpduSeqNo: A four-octet field indicating the Load PDU sequence <dt>lpduSeqNo:</dt><dd>A four-octet field indicating the Load PDU sequen ce
number (starting at 1). Used to determine loss, out-of-order, and number (starting at 1). Used to determine loss, out-of-order, and
duplicates.</t> duplicates.</dd>
<dt>udpPayload:</dt><dd>A two-octet field indicating the total payload s
<t>udpPayload: A two-octet field indicating the total payload size of ize 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). This
field allows the Load PDU receiver to maintain accurate receive field allows the Load PDU receiver to maintain accurate receive
statistics if utilizing receive truncation (only requesting the Load statistics if utilizing receive truncation (only requesting the Load
PDU message header octets from the protocol stack).</t> PDU message header octets from the protocol stack).</dd>
<dt>spduSeqErr:</dt><dd>A two-octet field indicating the Status PDU loss
<t>spduSeqErr: A two-octet field indicating the Status PDU loss count, 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 PDU
sequence number (spduSeqNo) in the most recently received Status PDU. sequence number (spduSeqNo) in the most recently received Status PDU.
Used to communicate to the Load PDU receiver that return traffic (in Used to communicate to the Load PDU receiver that return traffic (in
the unloaded direction) is being lost.</t> the unloaded direction) is being lost.</dd>
<dt>spduTime_sec/spduTime_nsec:</dt><dd>Two four-octet fields containing
<t>spduTime_sec/spduTime_nsec: Two four-octet fields containing a copy a copy
of the most recent spduTime_sec/spduTime_nsec from the last Status PDU of the most recent spduTime_sec/spduTime_nsec from the last Status PDU
received. Used for RTT measurements made by the Load PDU receiver.</t> received. Used for RTT measurements made by the Load PDU receiver.</dd>
<dt>lpduTime_sec/lpduTime_nsec:</dt><dd>Two four-octet fields containing
<t>lpduTime_sec/lpduTime_nsec: Two four-octet fields containing the 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.</t> measurements made by the Load PDU receiver.</dd>
<dt>rttRespDelay:</dt><dd>A two-octet field indicating the RTT response
<t>rttRespDelay: A two-octet field indicating the RTT response delay, delay,
used to "adjust" raw RTT. On the Load PDU sender, it is the number of used to "adjust" raw RTT. On the Load PDU sender, it is the number of
milliseconds from reception of the most recent Status PDU (when the milliseconds from reception of the most recent Status PDU (when the
latest spduTime_sec/spduTime_nsec was obtained) to the transmission of latest spduTime_sec/spduTime_nsec was obtained) to the transmission of
the Load PDU (where the previously obtained spduTime_sec/spduTime_nsec the Load PDU (where the previously obtained spduTime_sec/spduTime_nsec
is returned). When the Load PDU receiver is calculating RTT, by is returned). When the Load PDU receiver is calculating RTT, by
subtracting the copied Status PDU send time (in the Load PDU) from the subtracting the copied Status PDU send time (in the Load PDU) from the
local Load PDU receive time, this value is subtracted from the raw RTT local Load PDU receive time, this value is subtracted from the raw RTT
to correct for any response delay due to Load PDU scheduling.</t> to correct for any response delay due to Load PDU scheduling.</dd>
<dt>checkSum:</dt><dd>An optional checksum of only the Load PDU header (
<t>checkSum: An optional checksum of only the Load PDU header (see see
<xref target="Checksum"/> for guidance). The checksum does not cover <xref target="Checksum" format="default"/> for guidance). The checksum d
the Payload Content. The calculation is done as the very last step of oes not cover
building the PDU header, with the checksum field set to zero.</t> the payload content. The calculation is done as the very last step of
building the PDU header, with the checkSum field set to zero.</dd>
<t>Payload Content: All zeroes, all ones, or a pseudorandom binary <dt>Payload Content:</dt><dd>All zeroes, all ones, or a pseudorandom bin
sequence.</t> ary
sequence.</dd>
<t>The Load PDU SHALL be organized as follows (followed by any payload </dl>
content):</t> <t>The Load PDU <bcp14>SHALL</bcp14> be organized as follows (followed b
y any payload content):</t>
<t><figure anchor="LoadPDU" title="Load PDU"> <figure anchor="LoadPDU">
<artwork> <name>Load PDU</name>
&lt;CODE BEGINS&gt; <sourcecode name="" type="c" markers="true"><![CDATA[
// //
// 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
uint16_t pduId; // PDU ID uint16_t pduId; // PDU ID
#define TEST_ACT_TEST 0 // Test active #define TEST_ACT_TEST 0 // Test active
#define TEST_ACT_STOP1 1 // Stop indication used locally by server #define TEST_ACT_STOP1 1 // Stop indication used locally by server
#define TEST_ACT_STOP2 2 // Stop indication exchanged with client #define TEST_ACT_STOP2 2 // Stop indication exchanged with client
uint8_t testAction; // Test action uint8_t testAction; // Test action
skipping to change at line 2049 skipping to change at line 2297
uint32_t lpduSeqNo; // Load PDU sequence number uint32_t lpduSeqNo; // Load PDU sequence number
uint16_t udpPayload; // UDP payload (bytes) uint16_t udpPayload; // UDP payload (bytes)
uint16_t spduSeqErr; // Status PDU sequence error count uint16_t spduSeqErr; // Status PDU sequence error count
uint32_t spduTime_sec; // Send time in last rx'd status PDU uint32_t spduTime_sec; // Send time in last rx'd status PDU
uint32_t spduTime_nsec; // Send time in last rx'd status PDU uint32_t spduTime_nsec; // Send time in last rx'd status PDU
uint32_t lpduTime_sec; // Send time of this load PDU uint32_t lpduTime_sec; // Send time of this load PDU
uint32_t lpduTime_nsec; // Send time of this load PDU uint32_t lpduTime_nsec; // Send time of this load PDU
uint16_t rttRespDelay; // Response delay for RTT (ms) uint16_t rttRespDelay; // Response delay for RTT (ms)
uint16_t checkSum; // Header checksum uint16_t checkSum; // Header checksum
}; };
&lt;CODE ENDS&gt; ]]></sourcecode>
</artwork> </figure>
<postamble/>
</figure></t>
</section> </section>
<section anchor="Status-PDU" numbered="true" toc="default">
<section anchor="Status-PDU" title="Status PDU"> <name>Status PDU</name>
<t>The Load PDU receiver SHALL send a Status PDU to the sender during <t>The Load PDU receiver <bcp14>SHALL</bcp14> send a Status PDU to the s
ender during
a test at the configured feedback interval, after at least one Load a test at the configured feedback interval, after at least one Load
PDU has been received (when there is something to provide status on). PDU has been received (when there is something to provide status on).
In test scenarios with long delays between client and server, it is In test scenarios with long delays between client and server, it is
possible for the Status PDU send timer to fire before the first Load possible for the Status PDU send timer to fire before the first Load
PDU arrives. In these cases, the Status PDU SHALL NOT be sent.</t> PDU arrives. In these cases, the Status PDU <bcp14>SHALL NOT</bcp14> be
sent.</t>
<t>When the Load PDU sender receives a Status PDU message, it SHALL <t>When the Load PDU sender receives a Status PDU message, it <bcp14>SHA
first follow the Message Verification Procedure listed in <xref LL</bcp14>
target="VerifyPDU"/>.</t> first follow the Message Verification Procedure listed in <xref target="
VerifyPDU" format="default"/>.</t>
<t>The watchdog timer at the Load PDU sender SHALL be reset each time <t>The watchdog timer at the Load PDU sender <bcp14>SHALL</bcp14> be res
et each time
a valid Status PDU is received (which includes verification of the a valid Status PDU is received (which includes verification of the
checkSum and/or authDigest, if in use). See non-graceful test stop in checkSum and/or authDigest, if in use). See non-graceful test stop in
<xref target="Test-Stop"/> for handling the watchdog timeout <xref target="Test-Stop" format="default"/> for handling the watchdog ti meout
expiration at each endpoint.</t> expiration at each endpoint.</t>
<t>The UDP PDU format layout <bcp14>SHALL</bcp14> be as follows (big-end
<t>The UDP PDU format layout SHALL be as follows (big-endian AB):</t> ian AB):</t>
<figure anchor="StatPDU">
<t><figure anchor="StatPDU" title="Status PDU Layout"> <name>Status PDU Layout</name>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
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 line 2109 skipping to change at line 2351
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 line 2158 skipping to change at line 2400
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
<postamble/>
</figure></t>
<t>Note that the Sending Rate structure is defined in <xref
target="Test-Activation"/>.</t>
<t>Note that the Sending Rate structure is defined in <xref target="Test -Activation" format="default"/>.</t>
<t>The primary role of the Status Feedback message is to communicate <t>The primary role of the Status Feedback message is to communicate
to the Load PDU sender the traffic conditions at the Load PDU the traffic conditions at the Load PDU
receiver. While the Sub-Interval Statistics structure (sisSav) covers receiver to the Load PDU sender. While the Sub-Interval Statistics struc
ture (sisSav) covers
the most recently saved (completed) sub-interval, similar fields the most recently saved (completed) sub-interval, similar fields
directly in the Status PDU itself cover the most recent trial interval directly in the Status PDU itself cover the most recent trial interval
(the time period between Status Feedback messages, completed by this (the time period between Status Feedback messages, completed by this
Status PDU). Both sets of statistics SHALL always be populated by the Status PDU). Both sets of statistics <bcp14>SHALL</bcp14> always be popu lated by the
Load PDU receiver, regardless of role (client or server).</t> Load PDU receiver, regardless of role (client or server).</t>
<t>Details on the Status PDU measurement fields are provided in <xref ta
<t>Details on the Status PDU measurement fields are provided in <xref rget="RFC9097" format="default"/>. The authentication and checkSum fields follow
target="RFC9097"/>. Authentication and checksum fields follow the same 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 information regarding fields not defined previously are as
follows:</t> follows:</t>
<dl spacing="normal" newline="false">
<t>pduId: IANA is asked to assign the value hex 0xFEED (<xref <dt>pduId:</dt><dd>IANA has assigned the hex value 0xFEED (<xref target=
target="pduId"/>).</t> "pduId" format="default"/>).</dd>
<dt>spduSeqNo:</dt><dd>A four-octet field containing the Status PDU sequ
<t>spduSeqNo: A four-octet field containing the Status PDU sequence ence
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 Status
PDU loss (in the unloaded direction). The loss count is communicated PDU loss (in the unloaded direction). The loss count is communicated
back to the Load PDU receiver via spduSeqErr in subsequent Load back to the Load PDU receiver via spduSeqErr in subsequent Load
PDUs.</t> PDUs.</dd>
<dt>subIntSeqNo:</dt><dd>A four-octet field containing the Sub-interval
<t>subIntSeqNo: A four-octet field containing the Sub-interval
sequence number (starting at 1) that corresponds to the statistics sequence number (starting at 1) that corresponds to the statistics
provided in sisSav, for the last saved (completed) sub-interval.</t> provided in sisSav, for the last saved (completed) sub-interval.</dd>
<t>sisSav: Sub-interval statistics saved (completed) for the most <!--[rfced] Please review the formatting of the list in Section 7.2,
in particular the indentation of terms following "SisSav". Please
let us know if this is correct (sisSav consists of all the fields
that follow) or if it needs an update.
-->
<dt>sisSav:</dt><dd><t>Sub-interval statistics saved (completed) for the
most
recent sub-interval (as designated by the subIntSeqNo). These consist recent sub-interval (as designated by the subIntSeqNo). These consist
of the following fields:</t> of the following fields:</t>
<dl spacing="normal" newline="false">
<t>rxDatagrams: A four-octet field Sub-interval indicating the number <dt>rxDatagrams:</dt><dd>A four-octet field Sub-interval indicating the
of received datagrams during the Sub-Interval.</t> number
of received datagrams during the Sub-Interval.</dd>
<t>rxBytes: An eight-octet field indicating the Sub-Interval byte <dt>rxBytes:</dt><dd>An eight-octet field indicating the Sub-Interval by
count (eight octets chosen to prevent overflow at high speeds).</t> te
count (eight octets chosen to prevent overflow at high speeds).</dd>
<t>deltaTime: A four-octet field indicating the exact duration of the <dt>deltaTime:</dt><dd>A four-octet field indicating the exact duration
of the
Sub-Interval in microseconds. Used to calculate the received traffic Sub-Interval in microseconds. Used to calculate the received traffic
rate together with rxBytes.</t> rate together with rxBytes.</dd>
<dt>seqErrLoss/seqErrOoo/seqErrDup:</dt><dd>Three four-octet fields popu
<t>seqErrLoss/seqErrOoo/seqErrDup: Three four-octet fields, populated lated
by the Loss, out-of-order, and duplicate totals. Available for both by the Loss, out-of-order, and duplicate totals. Available for both
the sub-interval and trial interval, it is a breakout of the SeqErrors the sub-interval and trial interval; it is a breakout of the SeqErrors
count in Table 3 of <xref target="TR-471"/>. seqErrOoo and seqErrDup count in Table 3 of <xref target="TR-471" format="default"/>. seqErrOoo
and seqErrDup
are realized by comparing sequence numbers. A lookback list of the are realized by comparing sequence numbers. A lookback list of the
last n sequence numbers received is used as the basis. Each Load PDU last n sequence numbers received is used as the basis. Each Load PDU
sequence number is checked against this lookback. The number n may sequence number is checked against this lookback. The number n may
depend on the implementation and on typical characteristics of depend on the implementation and on typical characteristics of
environments, where UDPST is deployed (like mobile networks or Wi-Fi). environments, where UDPSTP is deployed (like mobile networks or Wi-Fi).
Currently, a default sequence number interval of n=32 has been chosen. Currently, a default sequence number interval of n=32 has been chosen.
Specifically for seqErrOoo, each successively received higher seqno Specifically for seqErrOoo, each successively received higher seqno
sets the next-expected-seqno to seqno+1 and anything below that is sets the next-expected seqno to seqno+1, and anything below that is
considered out-of-order (i.e., delayed). For example, given the considered out of order (i.e., delayed). For example, given the
sequence 93, 94, 95, 100, 96, 97, 101, 98, 99, 102, 103, ... reception sequence 93, 94, 95, 100, 96, 97, 101, 98, 99, 102, 103, ... reception
of 96, 97, 98, and 99 would not increment the next-expected-seqno and of 96, 97, 98, and 99 would not increment the next-expected seqno and
would all be considered out-of-order.</t> would all be considered out of order.</dd>
<dt>delayVarMin/delayVarMax/delayVarSum/delayVarCnt:</dt><dd>Four four-o
<t>delayVarMin/delayVarMax/delayVarSum/delayVarCnt: Four four-octet ctet
fields populated by the one-way delay variation measurements of all fields populated by the one-way delay variation measurements of all
received Load PDUs (where avg = sum/cnt). For each Load PDU received, received Load PDUs (where avg = sum/cnt). For each Load PDU received,
the send time (lpduTime_sec/lpduTime_nsec) is subtracted from the the send time (lpduTime_sec/lpduTime_nsec) is subtracted from the
local receive time, which is then normalized by subtracting the local receive time, which is then normalized by subtracting the
current clockDeltaMin. Available for both the sub-interval and trial current clockDeltaMin. Available for both the sub-interval and trial
interval.</t> interval.</dd>
<dt>rttVarMinimum/rttVarMaximum (in sisSav):</dt><dd>Two four-octet fiel
<t>rttVarMinimum/rttVarMaximum (in sisSav): Two four-octet fields ds
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.</t> (rttVarSample) in the sub-interval designated by the subIntSeqNo.</dd>
<dt>accumTime:</dt><dd>The accumulated time of the test in milliseconds,
<t>accumTime: The accumulated time of the test in milliseconds, based based
on the duration of each sub-interval. Equivalent to the sum of each on the duration of each sub-interval. Equivalent to the sum of each
deltaTime (although in ms) sent in each Status PDU during the deltaTime (although in ms) sent in each Status PDU during the
test.</t> test.</dd>
<dt>clockDeltaMin:</dt><dd>A four-octet field indicating the minimum clo
<t>clockDeltaMin: A four-octet field indicating the minimum clock ck
delta (difference) since the beginning of the test. Obtained by delta (difference) since the beginning of the test. Obtained by
subtracting the send time of each Load PDU subtracting the send time of each Load PDU
(lpduTime_sec/lpduTime_nsec) from the local time that it was received. (lpduTime_sec/lpduTime_nsec) from the local time that it was received.
This value is initialized with the first Load PDU received and is This value is initialized with the first Load PDU received and is
updated with each subsequent one to maintain a current (and updated with each subsequent one to maintain a current (and
continuously updated) minimum. If the endpoint clocks are sufficiently continuously updated) minimum. If the endpoint clocks are sufficiently
synchronized, this will be the minimum one-way delay in milliseconds. synchronized, this will be the minimum one-way delay in milliseconds.
Otherwise, this value may be negative, but still valid for one-way Otherwise, this value may be negative but still valid for one-way
delay variation measurements for the default test duration (default is delay variation measurements for the default test duration (default is
10 [s]). If the test duration is extended to a range of minutes, where 10 [s]). If the test duration is extended to a range of minutes, where
significant clock drift can occur, synchronized (or at least significant clock drift can occur, synchronized (or at least
well-disciplined) clocks may be required.</t> well-disciplined) clocks may be required.</dd>
<dt>rttMinimum (in Status PDU):</dt><dd>A four-octet field indicating th
<t>rttMinimum (in Status PDU): A four-octet field indicating the e
minimum "adjusted" RTT measured since the beginning of the test. See minimum "adjusted" RTT measured since the beginning of the test. See
rttRespDelay regarding "adjusted" measurements. RTT is obtained by rttRespDelay (<xref target="load_pdu_roles"/>) regarding "adjusted" meas urements. RTT is obtained by
subtracting the copied spduTime_sec/spduTime_nsec in the received Load subtracting the copied spduTime_sec/spduTime_nsec in the received Load
PDU from the local time at which it was received. This minimum SHALL PDU from the local time at which it was received. This minimum <bcp14>SH ALL</bcp14>
be kept current (and continuously updated) via each Load PDU received be kept current (and continuously updated) via each Load PDU received
with an updated spduTime_sec/spduTime_nsec. This value MUST be with an updated spduTime_sec/spduTime_nsec. This value <bcp14>MUST</bcp1 4> be
positive. Before an initial value can be established, and because zero positive. Before an initial value can be established, and because zero
is itself valid, it SHALL be set to STATUS_NODEL when communicated in is itself valid, it <bcp14>SHALL</bcp14> be set to STATUS_NODEL when com
the Status PDU.</t> municated in
the Status PDU.</dd>
<t>rttVarSample: A four-octet field indicating the most recent <dt>rttVarSample:</dt><dd>A four-octet field indicating the most recent
"adjusted" RTT delay variation measurement. See rttRespDelay regarding "adjusted" RTT delay variation measurement. See rttRespDelay (<xref targ
et="load_pdu_roles"/>) regarding
"adjusted" measurements. RTT delay variation is obtained by "adjusted" measurements. RTT delay variation is obtained by
subtracting the current (and continuously updated) "adjusted" RTT subtracting the current (and continuously updated) "adjusted" RTT
minimum, communicated as rttMinimum (in Status PDU), from each minimum, communicated as rttMinimum (in Status PDU), from each
"adjusted" RTT measurement (which is itself obtained by subtracting "adjusted" RTT measurement (which is itself obtained by subtracting
the copied spduTime_sec/spduTime_nsec in the received Load PDU from the copied spduTime_sec/spduTime_nsec in the received Load PDU from
the local time at which it was received). Note that while one-way the local time at which it was received). Note that while one-way
delay variation is measured for every Load PDU received, RTT delay delay variation is measured for every Load PDU received, RTT delay
variation is only sampled via the Status PDU sent and the very next variation is only sampled via the Status PDU sent and the very next
Load PDU received with the corresponding updated Load PDU received with the corresponding updated
spduTime_sec/spduTime_nsec. When a new value is unavailable (possibly spduTime_sec/spduTime_nsec. When a new value is unavailable (possibly
due to packet loss), and because zero is itself valid, it SHALL be set due to packet loss), and because zero is itself valid, it <bcp14>SHALL</
to STATUS_NODEL when communicated in the Status PDU.</t> bcp14> be set
to STATUS_NODEL when communicated in the Status PDU.</dd>
<t>delayMinUpd: A one-octet field. Boolean, 0 or 1, indicating that <dt>delayMinUpd:</dt><dd>A one-octet field. Boolean, 0 or 1, indicating
that
the clockDeltaMin and/or rttMinimum (in Status PDU), as measured by the clockDeltaMin and/or rttMinimum (in Status PDU), as measured by
the Load PDU receiver, has been updated.</t> the Load PDU receiver, has been updated.</dd>
<dt>tiDeltaTime/tiRxDatagrams/tiRxBytes:</dt><dd>Three four-octet fields
<t>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 with the
received datagram and byte counts. Used to calculate the received received datagram and byte counts. Used to calculate the received
traffic rate for the trial interval.</t> traffic rate for the trial interval.</dd>
<dt>spduTime_sec/spduTime_nsec:</dt><dd>Two four-octet fields containing
<t>spduTime_sec/spduTime_nsec: Two four-octet fields, containing the the
local transmit time of the Status PDU. Expected to be copied into local transmit time of the Status PDU. Expected to be copied into
spduTime_sec/spduTime_nsec in subsequent Load PDUs after being spduTime_sec/spduTime_nsec in subsequent Load PDUs after being
received by the Load PDU sender. Used for RTT measurements.</t> received by the Load PDU sender. Used for RTT measurements.</dd>
<dt>authMode:</dt><dd>Same as in <xref target="Setup-Fields" format="def
<t>authMode: Same as <xref target="Setup-Fields"/></t> ault"/>.</dd>
<dt>authUnixTime:</dt><dd>Same as in <xref target="Setup-Fields" format=
<t>authUnixTime: Same as <xref target="Setup-Fields"/></t> "default"/>.</dd>
<dt>authDigest:</dt><dd>Same as in <xref target="Setup-Fields" format="d
<t>authDigest: Same as <xref target="Setup-Fields"/></t> efault"/>.</dd>
<dt>keyId:</dt><dd>Same as in <xref target="Setup-Fields" format="defaul
<t>keyId: Same as <xref target="Setup-Fields"/></t> t"/>.</dd>
<dt>reservedAuth1:</dt><dd>Same as in <xref target="Setup-Fields" format
<t>reservedAuth1: Same as <xref target="Setup-Fields"/></t> ="default"/>.</dd>
<dt>checkSum:</dt><dd>Same as in <xref target="Setup-Fields" format="def
<t>checkSum: Same as <xref target="Setup-Fields"/></t> ault"/>.</dd>
</dl></dd></dl>
<t>The Status Feedback message PDU (as well as the included <t>The Status Feedback message PDU (as well as the included
Sub-Interval Statistics structure) SHALL be organized as follows:</t> Sub-Interval Statistics structure) <bcp14>SHALL</bcp14> be organized as
follows:</t>
<t><figure anchor="STATUS" title="Status PDU"> <figure anchor="STATUS">
<artwork> <name>Status PDU</name>
&lt;CODE BEGINS&gt; <sourcecode name="" type="c" markers="true"><![CDATA[
// //
// 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
uint64_t rxBytes; // Received bytes (64 bits) uint64_t rxBytes; // Received bytes (64 bits)
uint32_t deltaTime; // Time delta (us) uint32_t deltaTime; // Time delta (us)
uint32_t seqErrLoss; // Loss sum uint32_t seqErrLoss; // Loss sum
uint32_t seqErrOoo; // Out-of-Order sum uint32_t seqErrOoo; // Out-of-Order sum
uint32_t seqErrDup; // Duplicate sum uint32_t seqErrDup; // Duplicate sum
skipping to change at line 2377 skipping to change at line 2595
uint16_t reserved3; // (reserved for alignment) uint16_t reserved3; // (reserved for alignment)
uint8_t reserved4; // (reserved for alignment) uint8_t reserved4; // (reserved for alignment)
// ========== Integrity Verification ========== // ========== Integrity Verification ==========
uint8_t authMode; // Authentication mode uint8_t authMode; // Authentication mode
uint32_t authUnixTime; // Authentication timestamp uint32_t authUnixTime; // Authentication timestamp
uint8_t authDigest[AUTH_DIGEST_LENGTH]; uint8_t authDigest[AUTH_DIGEST_LENGTH];
uint8_t keyId; // Key ID in shared table uint8_t keyId; // Key ID in shared table
uint8_t reservedAuth1; // (reserved for alignment) uint8_t reservedAuth1; // (reserved for alignment)
uint16_t checkSum; // Header checksum uint16_t checkSum; // Header checksum
}; };
&lt;CODE ENDS&gt; ]]></sourcecode>
</artwork> </figure>
<postamble/>
</figure></t>
</section> </section>
</section> </section>
<section anchor="Test-Stop" numbered="true" toc="default">
<section anchor="Test-Stop" title="Stopping a Test"> <name>Stopping a Test</name>
<t>When the test duration timer (testIntTime) on the server expires, it <t>When the test duration timer (testIntTime) on the server expires, it
SHALL set the local connection test action to TEST_ACT_STOP1 (phase 1 of <bcp14>SHALL</bcp14> set the local connection test action to TEST_ACT_STOP 1 (phase 1 of
graceful termination). This is simply a non-reversible state awaiting graceful termination). This is simply a non-reversible state awaiting
the next message(s) to be sent from the server. During this time, any the next message(s) to be sent from the server. During this time, any
received Load or Status PDUs are processed normally.</t> received Load or Status PDUs are processed normally.</t>
<t>Upon transmission of the next Load or Status PDUs, the server <bcp14>SH
<t>Upon transmission of the next Load or Status PDUs, the server SHALL ALL</bcp14>
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 value graceful termination) and mark any outgoing PDUs with a testAction value
of TEST_ACT_STOP2. While in this state, the server MAY reduce any Load of TEST_ACT_STOP2. While in this state, the server <bcp14>MAY</bcp14> redu ce any Load
PDU bursts to a size of one.</t> PDU bursts to a size of one.</t>
<t>When the client receives a Load or Status PDU with the TEST_ACT_STOP2 <t>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 <bcp14>SHALL</bcp14> finalize testing, display the test res
also mark its local connection with a test action of TEST_ACT_STOP2 (so ults, and
mark its local connection with a test action of TEST_ACT_STOP2 (so
that any PDUs subsequently received can be ignored).</t> that any PDUs subsequently received can be ignored).</t>
<t>With the test action of the client's connection set to <t>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 Load 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 sent or a Status PDU, <bcp14>SHALL</bcp14> result in it and any subsequent PDUs being sent
with a testAction value of TEST_ACT_STOP2 (as confirmation to the with a testAction value of TEST_ACT_STOP2 (as confirmation to the
server). While in this state, the client MAY reduce any Load PDU bursts server). While in this state, the client <bcp14>MAY</bcp14> reduce any Loa
to a size of one. The client SHALL then schedule an immediate end time d PDU bursts
to a size of one. The client <bcp14>SHALL</bcp14> then schedule an immedia
te end time
for the connection.</t> for the connection.</t>
<t>When the server receives the TEST_ACT_STOP2 confirmation in the Load <t>When the server receives the TEST_ACT_STOP2 confirmation in the Load
or Status PDU, the server SHALL schedule an immediate end time for the or Status PDU, the server <bcp14>SHALL</bcp14> schedule an immediate end t
connection which closes the socket and deallocates the associated ime for 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.</t> termination of the test.</t>
<t>In a non-graceful test stop due to path failure, the watchdog <t>In a non-graceful test stop due to path failure, the watchdog
timeouts at each endpoint will expire (sometimes at one endpoint first), timeouts at each endpoint will expire (sometimes at one endpoint first);
notifications in logs, STDOUT, and/or formatted output SHALL be made, notifications in logs, STDOUT, and/or formatted output <bcp14>SHALL</bcp14
and the endpoint SHALL schedule an immediate end time for the > be made;
and the endpoint <bcp14>SHALL</bcp14> schedule an immediate end time for t
he
connection.</t> connection.</t>
<t>If an attacker clears the TEST_ACT_STOP2 indication, then the <t>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 end <bcp14>SHALL</bcp14> take precedence and the endpoint <bcp14>SHALL</bcp14> schedule an immediate end
time for the connection.</t> time for the connection.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Operational considerations for the Measurement Method"> <name>Operational Considerations for the Measurement Method</name>
<t>The architecture of the method requires two cooperating hosts <t>The architecture of the method requires two cooperating hosts
operating in the roles of Src (test packet sender) and Dst (receiver), operating in the roles of Src (test packet sender) and Dst (receiver),
with a measured path and return path between them.</t> with a measured path and return path between them.</t>
<t>The nominal duration of a measurement interval at the Destination, <t>The nominal duration of a measurement interval at the Destination,
parameter testIntTime, MUST be constrained in a production network, parameter testIntTime, <bcp14>MUST</bcp14> be constrained in a production network,
since this is an active test method and it will likely cause congestion since this is an active test method and it will likely cause congestion
on the Src to Dst host path during a test.</t> on the Src to Dst host path during a test.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> to locate test endpoints as close to t
<t>It is RECOMMENDED to locate test endpoints as close to the intended he intended
measured link(s) as practical. The testing operator MUST set a value for measured link(s) as practical. The testing operator <bcp14>MUST</bcp14> se
t a value for
the MaxHops Parameter, based on the expected path length. This Parameter the MaxHops Parameter, based on the expected path length. This Parameter
can keep measurement traffic from straying too far beyond the intended can keep measurement traffic from straying too far beyond the intended
path.</t> path.</t>
<t>It is obviously counterproductive to run more than one independent <t>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. The stream) when attempting to measure the maximum capacity on a single path.
number of concurrent, independent tests of a path SHALL be limited to The
number of concurrent, independent tests of a path <bcp14>SHALL</bcp14> be
limited to
one.</t> one.</t>
<t>The load rate adjustment algorithm's scope is limited to helping <t>The load rate adjustment algorithm's scope is limited to helping
determine the Maximum IP-Layer Capacity in the context of an infrequent, determine the Maximum IP-Layer Capacity in the context of an infrequent,
diagnostic, short-term measurement. It is RECOMMENDED to discontinue diagnostic, short-term measurement. It is <bcp14>RECOMMENDED</bcp14> to di scontinue
non-measurement traffic that shares a subscriber's dedicated resources non-measurement traffic that shares a subscriber's dedicated resources
while testing: measurements may not be accurate, and throughput of while testing: measurements may not be accurate, and throughput of
competing elastic traffic may be greatly reduced.</t> competing elastic traffic may be greatly reduced.</t>
<t>See <xref target="RFC9097" section="8"/> for a discussion of the
<t>See section 8 of <xref target="RFC9097"/> for a discussion of the Method of Measurement beyond purely operational aspects.</t>
method of measurement beyond purely operational aspects.</t> <section numbered="true" toc="default">
<name>Notes on Interface Measurements</name>
<section title="Notes on Interface Measurements">
<t>Additional measurements may be useful in specific circumstances. <t>Additional measurements may be useful in specific circumstances.
For example, interface byte counters measured by a client at a For 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.</t> this form of diagnostic measurement may not be possible.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t>Active metrics and measurements have a long history of security <t>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 <xref measurement of live paths are relevant here. See <xref target="RFC4656" fo
target="RFC4656"/> and <xref target="RFC5357"/>.</t> rmat="default"/> and <xref target="RFC5357" format="default"/>.</t>
<!--[rfced] Please clarify what 2 instances of "those" refer to in
this sentence.
Original:
When considering privacy of those involved in measurement or those
whose traffic is measured, the sensitive information available to
potential observers is greatly reduced when using active techniques
which are within this scope of work.
-->
<t>When considering privacy of those involved in measurement or those <t>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 the traffic for measurement purposes raise many privacy issues. See the
reader to the privacy considerations described in the LMAP Framework privacy considerations described in the LMAP Framework
<xref target="RFC7594"/>, which covers active and passive <xref target="RFC7594" format="default"/>, which covers active and passive
techniques.</t> techniques.</t>
<t>Below are some new considerations for capacity measurement as
<t>There are some new considerations for Capacity measurement as
described in this document.</t> described in this document.</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers">
<t>Cooperating client and server hosts and agreements to test the <t>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 <bcp14>REQUIRED</bcp14>. Hosts perform in e
server or client roles. One way to assure a cooperative agreement ither the
employs the optional Authorization mode through the use of the server or the client roles. One way to assure a cooperative agreement
employs the optional Authorization mode is through the use of the
authDigest field and the known identity associated with the shared authDigest field and the known identity associated with the shared
key used to create the authDigest field via the KDF. Other means are key used to create the authDigest field via the KDF. Other means are
also possible, such as access control lists at the server.</t> also possible, such as access control lists at the server.</t>
</li>
<t>It is REQUIRED to have a user client-initiated setup handshake <li>
<t>It is <bcp14>REQUIRED</bcp14> to have a user client-initiated setup
handshake
between cooperating hosts that allows firewalls to control inbound between cooperating hosts that allows firewalls to control inbound
unsolicited UDP traffic which either goes to a control port or to unsolicited UDP traffic that goes to either a control port or
ephemeral ports that are only created as needed. Firewalls ephemeral ports that are only created as needed. Firewalls
protecting each host can both continue to do their job normally.</t> protecting each host can continue to do their jobs normally.</t>
</li>
<li>
<t>Client-server authentication and integrity protection for <t>Client-server authentication and integrity protection for
feedback messages conveying measurements is RECOMMENDED. To feedback messages conveying measurements is <bcp14>RECOMMENDED</bcp14> . To
accommodate different host limitations and testing circumstances, accommodate different host limitations and testing circumstances,
different modes of operation are available, as described in <xref different modes of operation are available, as described in <xref targ
target="Security-Checksum"/> above.</t> et="Security-Checksum" format="default"/>.</t>
</li>
<t>Hosts MUST limit the number of simultaneous tests to avoid <li>
<t>Hosts <bcp14>MUST</bcp14> limit the number of simultaneous tests to
avoid
resource exhaustion and inaccurate results.</t> resource exhaustion and inaccurate results.</t>
</li>
<t>Senders MUST be rate-limited. This can be accomplished using a <li>
<t>Senders <bcp14>MUST</bcp14> be rate-limited. This can be accomplish
ed using a
pre-built table defining all the offered sending rates that will be pre-built table defining all the offered sending rates that will be
supported. The default and optional load rate adjustment algorithm supported. The default and optional load rate adjustment algorithm
results in "ramp up" from the lowest rate in the table. Optionally, results in "ramp up" from the lowest rate in the table. Optionally,
the server could utilize the maxBandwidth field (and CHSR_USDIR_BIT the server could utilize the maxBandwidth field (and the CHSR_USDIR_BI T
bit) in the Setup Request from the client to limit the maximum that bit) in the Setup Request from the client to limit the maximum that
it will attempt to achieve.</t> it will attempt to achieve.</t>
</li>
<li>
<t>Service subscribers with limited data volumes who conduct <t>Service subscribers with limited data volumes who conduct
extensive capacity testing might experience the effects of Service 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 frequency and/or Provider's measurement hosts <bcp14>SHOULD</bcp14> be limited in frequ ency and/or
overall volume of test traffic (for example, the range of test overall volume of test traffic (for example, the range of test
interval duration values should be limited).</t> interval duration values should be limited).</t>
</list></t> </li>
</ol>
<t>One specific attack that has been recognized is an on-path attack on <t>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 the indication. Setting the indication in successive packets terminates the
test prematurely, with no threat to the Internet but annoyance for the test prematurely, with no threat to the Internet but annoyance for the
testers. If an attacker clears the STOP indication, the mitigation testers. If an attacker clears the STOP indication, the mitigation
relies on knowledge of the test duration at the client and server, where relies on knowledge of the test duration at the client and server, where
these hosts cease all traffic when the specified test duration is these hosts cease all traffic when the specified test duration is
complete.</t> complete.</t>
<t>Authentication methods and requirements steadily evolve. Alternate <t>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 Setup mode, whose support is indicated by assigning a suitable "Test Setup
PDU Authentication Mode Registry" value (see <xref PDU Authentication Mode" registry value (see <xref target="Setup-authMode"
target="Setup-authMode"/> ).</t> format="default"/> ).</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <!-- [rfced] We have included some specific questions about the IANA
<t>This document requests IANA to assign a User/Registered UDP port for text below. In addition to responding to those questions, please
the Test Setup exchange in the Control phase of protocol operation, and review all of the IANA-related updates carefully and let us know
to create a new registry group for the UDP Speed Test Protocol if any further changes are needed.
(UDPSTP).</t>
<section title="New User Port Number Assignment"> a) Section 11.1. In the "Service Name and Transport Protocol Port
<t>IANA will allocate the following service name to the "Service Name Number Registry" <https://www.iana.org/assignments/
and Transport Protocol Port Number Registry" registry:</t> service-names-port-numbers/>, the Transport Protocol is listed as
"udp", but in this document, it is listed as "UDP". For consistency,
should this term be lowercase or uppercase? Note that we will
communicate any changes to the registry to IANA.
<t><list style="hanging"> In this document:
<t hangText="Service:">udpstp</t> Transport Protocol: UDP
<t hangText="Transport Protocol:">UDP</t> In the registry:
Transport Protocol: upd
<t hangText="Assignee:">IESG &lt;iesg@ietf.org&gt;</t> - Also in Section 11.1, should "performance measurement protocol" or
"performance measurement" perhaps be capitalized? (We note that it
appears as "Performance Measurement protocol" in RFC 6812.)
<t hangText="Contact:">IETF Chair &lt;chair@ietf.org&gt;</t> Current:
Description: UDP-based IP-Layer Capacity and performance
measurement protocol
<t hangText="Description:">UDP-based IP-Layer Capacity and Perhaps:
performance measurement protocol</t> Description: UDP-based IP-Layer Capacity and Performance
Measurement protocol
<t hangText="Reference:">This RFC, RFCYYYY.</t> b) IANA has added the following entry to the "KeyTable KDFs" registry.
Is "[RFC6234]" the correct reference? Should this document also be
added as a reference?
<t hangText="Port Number:">&lt;PORTNUM&gt; of the IANA User Port Current:
range (1024-49151)</t> KDF Description Reference
</list></t> - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HMAC-SHA-256 HMAC using the SHA-256 hash [RFC6234]
<t>The protocol uses IP-Layer Unicast. The assignment of a single port c) May we update the note in the "UDP Speed Test Protocol (UDPSTP)"
number is requested to help configure firewalls and other port-based registry group for clarity as shown below (i.e., uppercase
systems for access control prior to negotiating dynamic ports between "experimental use" and add "are expected")? If so, we will ask IANA to
client and server.</t> update accordingly.
</section>
<section anchor="kdf-HMAC-SHA-256" title="New KeyTable KDF"> Original:
<t>IANA will allocate the following KDF to the existing list of Note: Values reserved for experimental use are not expected to be
KeyTable KDFs (see used on the Internet, but for experiments that are confined to closed
https://www.iana.org/assignments/keytable/keytable.xhtml#kdf).</t> environments.
<t><figure> Perhaps:
<artwork> Note: Values reserved for Experimental Use are not
KDF Description Reference expected to be used on the Internet but are expected to be used for
=============================================================== experiments that are confined to closed environments.
HMAC-SHA-256 HMAC using the SHA-256 hash [RFC6234]
</artwork>
</figure></t>
</section>
<section title="New UDPSTP Registry Group"> d) We note that the "Range" and "Value" column headers in the tables
<t>IANA will create the following registries in a new registry group listed below are different than what is listed in the corresponding
called "UDP Speed Test Protocol (UDPSTP)".</t> IANA registries. Should the IANA registries (which only list "Range"
and "Value") be updated to match this document, or should "(Hex)",
"(Decimal)", "(Bitmap)", "(Capital alphabet / UTF-8)", and
"(Numeric)" be removed from this document to match the IANA registries?
<t>IANA is requested to the following note under the "UDP Speed Test Current in this document (first header columns of the tables):
Protocol (UDPSTP)" registry group:</t> Table 2: Range(Hex)
Tables 4, 8, 10, 12, and 18: Range(Decimal)
Tables 6 and 14: Range(Bitmap)
Table 16: Range(Capital alphabet / UTF-8)
Table 17: Value(Numeric)
<t>Note: Values reserved for experimental use are not expected to be e) In the "PDU Identifier" registry, we note that IANA has listed
used on the Internet, but for experiments that are confined to closed "0x0001-0x7F00 / Specification Required" twice. We will ask IANA to
environments.</t> remove the duplicate entry. We also note that "0x8000-0xFFFE / IETF
Review" is missing. We will ask IANA to add it.
<section anchor="pduId" title="PDU Identifier Registry"> May we update the order of Table 2 in this document and in the IANA
<t>IANA will create the "PDU Identifier" registry under the "UDP registry as shown under the "Suggested" text below so that there is
Speed Test Protocol (UDPSTP)" registry group. Every UDPSTP PDU consistency with the order of the number ranges?
contains a two octet pduId field identifying the role and format of
the PDU that follows. The code points in this registry are allocated
according to the registration procedures <xref target="RFC8126"/>
described in Table 1.</t>
<t><figure> Current in the "PDU Identifier" registry:
<artwork>Range(Hex) Registration Procedures
===============================================================
0xFFFF and 0x0000 Reserved
0x8000-0xFFFE IETF Review Range Registration Procedures
- - - - - - - - - - - - - - - - - - - -
0x0000 Reserved
0x0001-0x7F00 Specification Required
0x7F01-0x7FE0 Reserved for Experimental Use
0x7FE1-0x7FFF Reserved for Private Use
0x0001-0x7F00 Specification Required
0xFFFF Reserved
0x0001-0x7F00 Specification Required Suggested (for the registry and this document):
0x7F01-0x7FE0 Experimental Range Registration Procedures
- - - - - - - - - - - - - - - - - - - -
0x0000 Reserved
0x0001-0x7F00 Specification Required
0x7F01-0x7FE0 Experimental Use
0x7FE1-0x7FFF Private Use
0x8000-0xFFFE IETF Review
0xFFFF Reserved
0x7FE1-0x7FFF Private Use f) In Table 7 under the description for value 0x02, is the hyphen
necessary in "IP-header" or may we remove it per use in most RFCs?
Also, may we add "an" before "IP header"?
</artwork> Original:
</figure>Table 1: Registration procedures for the PDU Identifier 0x02 Use Traditional MTU (1500 bytes with IP-header)
registry</t>
<t>Initially, IANA will assign the "PDU Identifier" registry with Perhaps:
the values in Table 2:</t> 0x02 Use Traditional MTU (1500 bytes with an IP header)
<t><figure> g) In the "Test Activation PDU Rate Adjustment Algo." registry name,
<artwork>Value Description Reference is the period after "Algo." necessary? We ask as there is no period
=================================================== after the "rateAdjAlgo" field, for example.
0xACE1 Test Setup PDU &lt;this RFC&gt;
0xACE2 Test Activation PDU &lt;this RFC&gt; Original:
"Test Activation PDU Rate Adjustment Algo." registry
0xBEEF Load PDU &lt;this RFC&gt; Perhaps:
"Test Activation PDU Rate Adjustment Algo" registry
0xDEAD Null PDU &lt;this RFC&gt; h) In Tables 11 and 19, how may we clarify the description for value 0.
Is "Request" referring to the "Setup Request" or other?
0xFEED Status Feedback PDU &lt;this RFC&gt; Original:
0 None (used by client in Request)
</artwork> Perhaps:
</figure>Table 2: Initial PDU Identifier Values</t> 0 None (used by client in the Setup Request)
</section> -->
<section anchor="protocolVer" title="Protocol Version Registry"> <name>IANA Considerations</name>
<t>IANA will create the "Protocol Version" registry under the "UDP <t>Per this document, IANA has assigned a UDP port for
Speed Test Protocol (UDPSTP)" registry group. UDPSTP Test Setup the Test Setup exchange in the Control phase of protocol operation and
Request, Test Setup Response and Test Activation Request PDUs has created a new registry group for the UDPSTP.</t>
contain a two octet protocolVer field, identifying the version of <section numbered="true" toc="default">
the protocol in use. The code points in this registry are allocated <name>New User Port Number Assignment</name>
according to the registration procedures <xref target="RFC8126"/> <t>IANA has registered the following service name in the "Service Name
described in Table 3.</t> and Transport Protocol Port Number Registry":</t>
<dl newline="false" spacing="compact">
<dt>Service Name:</dt>
<dd>udpstp</dd>
<dt>Port Number:</dt>
<dd>24601</dd>
<dt>Transport Protocol:</dt>
<dd>UDP</dd>
<dt>Description:</dt>
<dd>UDP-based IP-Layer Capacity and
performance measurement protocol</dd>
<dt>Assignee:</dt>
<dd>IESG &lt;iesg@ietf.org&gt;</dd>
<dt>Contact:</dt>
<dd>IETF Chair &lt;chair@ietf.org&gt;</dd>
<dt>Reference:</dt>
<dd>RFC 9946</dd>
<t><figure> </dl>
<artwork>Range(Decimal) Registration Procedures <t>The protocol uses IP-Layer Unicast. A single port
=============================================================== number was assigned to help configure firewalls and other port-based
0-19 Reserved systems for access control prior to negotiating dynamic ports between
client and server.</t>
</section>
<section anchor="kdf-HMAC-SHA-256" numbered="true" toc="default">
<name>New KeyTable KDF</name>
<t>IANA has added the following KDF entry to the
"KeyTable KDFs" registry (see
<eref target="https://www.iana.org/assignments/keytable" brackets="angle
"/>):</t>
20-40960 IETF Review <table>
<name>KeyTable KDFs Registry</name>
<thead>
<tr><th>KDF</th><th>Description</th><th>Reference</th></tr>
</thead>
<tbody>
<tr><td>HMAC-SHA-256</td><td>HMAC using the SHA-256 hash</td><td><xref targe
t="RFC6234"/></td></tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>New UDPSTP Registry Group</name>
<t>IANA has created the registries in the subsections that follow under
a new registry group
called "UDP Speed Test Protocol (UDPSTP)".</t>
<t>IANA has added the following note under the "UDP Speed Test
Protocol (UDPSTP)" registry group:</t>
40961-53248 Specification Required <blockquote>Note: Values reserved for experimental use are not expected
to be
used on the Internet, but for experiments that are confined to closed
environments.</blockquote>
53249-65534 Experimental <section anchor="pduId" numbered="true" toc="default">
<name>PDU Identifier Registry</name>
<t>IANA has created the "PDU Identifier" registry under the "UDP
Speed Test Protocol (UDPSTP)" registry group. Every UDPSTP PDU
contains a two-octet pduId field identifying the role and format of
the PDU that follows. The code points in this registry are allocated
according to the registration procedures <xref target="RFC8126" format
="default"/>
described in <xref target="reg-proc-pdu-identifier"/>.</t>
<table anchor="reg-proc-pdu-identifier">
<name>Registration Procedures for the PDU Identifier Registry</name>
<thead>
<tr>
<th>Range(Hex)</th>
<th>Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td>0xFFFF and 0x0000</td>
<td>Reserved</td>
</tr>
<tr>
<td>0x8000-0xFFFE</td>
<td>IETF Review</td>
</tr>
<tr>
<td>0x0001-0x7F00</td>
<td>Specification Required</td>
</tr>
<tr>
<td>0x7F01-0x7FE0</td>
<td>Experimental Use</td>
</tr>
<tr>
<td>0x7FE1-0x7FFF</td>
<td>Private Use</td>
</tr>
</tbody>
</table>
65535 Reserved <t>IANA has assigned values in the "PDU Identifier" registry as follow s:</t>
</artwork> <table anchor="init-pdu-iden-val">
</figure>Table 3: Registration procedures for the Protocol Version <name>Initial Values of the PDU Identifier Registry</name>
registry</t> <thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0x0000</td><td>Reserved</td><td>RFC 9946</td>
</tr>
<tr>
<td>0x7F01-0x7FE0</td><td>Reserved for Experimental Use</td><td>RFC 9946</
td>
</tr>
<tr>
<td>0x7FE1-0x7FFF</td><td>Reserved for Private Use</td><td>RFC 9946</td>
</tr>
<tr>
<td>0xACE1</td><td>Test Setup PDU</td><td>RFC 9946</td>
</tr>
<tr>
<td>0xACE2</td><td>Test Activation PDU</td><td>RFC 9946</td>
</tr>
<tr>
<td>0xBEEF</td><td>Load PDU</td><td>RFC 9946</td>
</tr>
<tr>
<td>0xDEAD</td><td>Null PDU</td><td>RFC 9946</td>
</tr>
<tr>
<td>0xFEED</td><td>Status Feedback PDU</td><td>RFC 9946</td>
</tr>
<tr> <td>0xFFFF</td><td>Reserved</td><td>RFC 9946</td>
</tr>
</tbody>
</table>
</section>
<section anchor="protocolVer" numbered="true" toc="default">
<name>Protocol Version Registry</name>
<t>IANA has created the "Protocol Version" registry under the "UDP
Speed Test Protocol (UDPSTP)" registry group. UDPSTP Test Setup
Request, Test Setup Response, and Test Activation Request PDUs
contain a two-octet protocolVer field, identifying the version of
the protocol in use. The code points in this registry are allocated
according to the registration procedures <xref target="RFC8126" format
="default"/>
described in <xref target="reg-proc-prot-ver-reg"/>.</t>
<t>Initially, IANA will assign the decimal value 20 listed in Table <table anchor="reg-proc-prot-ver-reg">
4 in the "Protocol Version" registry:</t> <name>Registration Procedures for the Protocol Version Registry</name>
<thead>
<tr>
<th>Range(Decimal)</th>
<th>Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td>0-19</td>
<td>Reserved</td>
</tr>
<tr>
<td>20-40960</td>
<td>IETF Review</td>
</tr>
<tr>
<td>40961-53248</td>
<td>Specification Required</td>
</tr>
<tr>
<td>53249-65534</td>
<td>Experimental Use</td>
</tr>
<tr>
<td>65535</td>
<td>Reserved</td>
</tr>
</tbody>
</table>
<t>IANA has assigned decimal value 20 in the "Protocol Version" regist
ry as follows:</t>
<t><figure> <table anchor="init-pro-ver-val">
<artwork>Value Reference <name>Initial Value of the Protocol Version Registry</name>
================================================ <thead>
20 &lt;this RFC&gt; <tr>
<th>Value</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>20</td>
<td>RFC 9946</td>
</tr>
</tbody>
</table>
</artwork>
</figure>Table 4: Initial Protocol Version value</t>
</section> </section>
<section anchor="Setup-modifierBitmap" numbered="true" toc="default">
<section anchor="Setup-modifierBitmap" <name>Test Setup PDU Modifier Bitmap Registry</name>
title="Test Setup PDU Modifier Bitmap Registry"> <t>IANA has created the "Test Setup PDU Modifier Bitmap" registry
<t>IANA will create the "Test Setup 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 Setup PDU layout contains a modifierBitmap field. The bitmaps Test Setup PDU layout contains a modifierBitmap field. The bitmaps
in this registry are allocated according to the registration in this registry are allocated according to the registration
procedures <xref target="RFC8126"/> described in Table 5.</t> procedures <xref target="RFC8126" format="default"/> described in <xre
f target="reg-proc-test-set-pdu-mod-bit-reg"/>.</t>
<t><figure>
<artwork>Range(Bitmap) Registration Procedures
===============================================================
00000000-01111111 IETF Review
10000000 Reserved
</artwork>
</figure>Table 5: Registration procedures for the Test Setup PDU
Modifier Bitmap Registry</t>
<t>Initially, IANA will assign the bitmap values defined by Table 6
in the "Test Setup PDU Modifier Bitmap" registry.</t>
<t><figure> <table anchor="reg-proc-test-set-pdu-mod-bit-reg">
<artwork>Value Description Reference <name>Registration Procedures for the Test Setup PDU Modifier Bitmap Re
=============================================================== gistry</name>
0x00 No modifications &lt;this RFC&gt; <thead>
<tr>
<th>Range(Bitmap)</th>
<th>Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td>00000000-01111111</td>
<td>IETF Review</td>
</tr>
<tr>
<td>10000000</td>
<td>Reserved</td>
</tr>
</tbody>
</table>
0x01 Allow Jumbo datagram &lt;this RFC&gt; <t>IANA has assigned bitmap values
sizes above sending in the "Test Setup PDU Modifier Bitmap" registry as follows:</t>
rates of 1 Gbps
0x02 Use Traditional MTU &lt;this RFC&gt; <table anchor="init-test-set-pdu-mod-bit-val">
(1500 bytes with <name>Initial Values of the Test Setup PDU Modifier Bitmap Registry</name>
IP-header) <thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0x00</td>
<td>No modifications</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>0x01</td>
<td>Allow Jumbo datagram sizes above sending rates of 1 Gbps</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>0x02</td>
<td>Use Traditional MTU (1500 bytes with IP-header)</td>
<td>RFC 9946</td>
</tr>
</tbody>
</table>
</artwork>
</figure>Table 6: Initial Test Setup PDU Modifier Bitmap
values</t>
</section> </section>
<section anchor="Setup-authMode" numbered="true" toc="default">
<section anchor="Setup-authMode" <name>Test Setup PDU Authentication Mode Registry</name>
title="Test Setup PDU Authentication Mode Registry"> <t>IANA has created the "Test Setup PDU Authentication Mode"
<t>IANA will create the "Test Setup PDU Authentication Mode"
registry under the "UDP Speed Test Protocol (UDPSTP)" registry registry under the "UDP Speed Test Protocol (UDPSTP)" registry
group. The Test Setup PDU layout contains an authMode field. The group. The Test Setup PDU layout contains an authMode field. The
code points in this registry are allocated according to the code points in this registry are allocated according to the
registration procedures <xref target="RFC8126"/> described in Table registration procedures <xref target="RFC8126" format="default"/> desc
7.</t> ribed in
<xref target="reg-proc-test-setup-pdu-auth-mode-reg"/>.</t>
<t><figure>
<artwork>Range(Decimal) Registration Procedures
===============================================================
0-59 IETF Review
60-63 Experimental
64-255 Reserved
</artwork>
</figure>Table 7: Registration procedures for the Test Setup PDU
Authentication Mode registry</t>
<t>Initially, IANA will assign the decimal values defined by Table 8
in the "Test Setup PDU Authentication Mode" registry.</t>
<t><figure> <table anchor="reg-proc-test-setup-pdu-auth-mode-reg">
<artwork>Value Description Reference <name>Registration Procedures for the Test Setup PDU Authentication Mode Regis
=============================================================== try</name>
0 Not used &lt;this RFC&gt; <thead>
<tr>
<th>Range(Decimal)</th>
<th>Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td>0-59</td>
<td>IETF Review</td>
</tr>
<tr>
<td>60-63</td>
<td>Experimental Use</td>
</tr>
<tr>
<td>64-255</td>
<td>Reserved</td>
</tr>
</tbody>
</table>
1 Required authentication &lt;this RFC&gt; <t>IANA has assigned decimal values
for the Control phase in the "Test Setup PDU Authentication Mode" registry as follows:</t>
2 Optional authentication for &lt;this RFC&gt; <table anchor="init-test-set-pdu-auth-mode-values">
the Data phase, in addition <name>Initial Values of the Test Setup PDU Authentication Mode Registry</name>
to the Control phase <thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Not used</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>1</td>
<td>Required authentication for the Control phase</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>2</td>
<td>Optional authentication for the Data phase, in addition to the Control
phase</td>
<td>RFC 9946</td>
</tr>
</tbody>
</table>
</artwork>
</figure>Table 8: Initial Test Setup PDU Authentication Mode
values</t>
</section> </section>
<section anchor="Error-codes" numbered="true" toc="default">
<section anchor="Error-codes" <name>Test Setup PDU Command Response Field Registry</name>
title="Test Setup PDU Command Response Field Registry"> <t>IANA has created the "Test Setup PDU Command Response Field"
<t>IANA will create the "Test Setup PDU Command Response Field"
registry under the "UDP Speed Test Protocol (UDPSTP)" registry registry under the "UDP Speed Test Protocol (UDPSTP)" registry
group. The Test Setup PDU layout contains a cmdResponse field. The group. The Test Setup PDU layout contains a cmdResponse field. The
code points in this registry are allocated according to the code points in this registry are allocated according to the
registration procedures <xref target="RFC8126"/> described in Table registration procedures <xref target="RFC8126" format="default"/> desc
9.</t> ribed in
<xref target="reg-proc-test-setup-pdu-comman-res-field-reg"/>.</t>
<t><figure>
<artwork>Range(Decimal) Registration Procedures
===============================================================
0-127 IETF Review
128-239 Specification Required
240-249 Experimental
250-254 Private Use
255 Reserved
</artwork>
</figure>Table 9: Registration procedures for the Test Setup PDU
Command Response Field Registry</t>
<t>Initially, IANA will assign the decimal values defined by Table
10 in the "Test Setup PDU Command Response Field" registry.</t>
<t><figure>
<artwork>Value Description Reference
===============================================================
0 None (used by &lt;this RFC&gt;
client in Request)
1 Acknowledgment &lt;this RFC&gt;
2 Bad Protocol Version &lt;this RFC&gt;
3 Invalid Jumbo datagram &lt;this RFC&gt;
option
4 Unexpected Authentication &lt;this RFC&gt;
in Setup Request
5 Authentication missing &lt;this RFC&gt;
in Setup Request
6 Invalid authentication &lt;this RFC&gt;
method
7 Authentication failure &lt;this RFC&gt;
8 Authentication time is &lt;this RFC&gt;
invalid in Setup Request
9 No Maximum test Bit rate &lt;this RFC&gt;
specified
10 Server Maximum Bit rate &lt;this RFC&gt;
exceeded
11 MTU option does not match &lt;this RFC&gt;
server
12 Multi-connection parameters &lt;this RFC&gt; <table anchor="reg-proc-test-setup-pdu-comman-res-field-reg">
rejected by server <name>Registration Procedures for the Test Setup PDU Command Response Field Re
gistry</name>
<thead>
<tr>
<th>Range(Decimal)</th>
<th>Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td>0-127</td>
<td>IETF Review</td>
</tr>
<tr>
<td>128-239</td>
<td>Specification Required</td>
</tr>
<tr>
<td>240-249</td>
<td>Experimental Use</td>
</tr>
<tr>
<td>250-254</td>
<td>Private Use</td>
</tr>
<tr>
<td>255</td>
<td>Reserved</td>
</tr>
</tbody>
</table>
13 Connection allocation &lt;this RFC&gt; <t>IANA has assigned decimal values
failure on server in the "Test Setup PDU Command Response Field" registry as follows:</t
>
</artwork> <table anchor="init-test-setup-pdu-commend-res-field-val">
</figure>Table 10: Initial Test Setup PDU Command Response Field <name>Initial Values of the Test Setup PDU Command Response Field Registry</na
values</t> me>
<thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>None (used by client in Request)</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>1</td>
<td>Acknowledgment</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>2</td>
<td>Bad protocol version</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>3</td>
<td>Invalid Jumbo datagram option</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>4</td>
<td>Unexpected authentication in Setup Request</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>5</td>
<td>Authentication missing in Setup Request</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>6</td>
<td>Invalid authentication method</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>7</td>
<td>Authentication failure</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>8</td>
<td>Authentication time is invalid in Setup Request</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>9</td>
<td>No maximum test bit rate specified</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>10</td>
<td>Server maximum bit rate exceeded</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>11</td>
<td>MTU option does not match server</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>12</td>
<td>Multi-connection parameters rejected by server</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>13</td>
<td>Connection allocation failure on server</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>240-249</td>
<td>Reserved for Experimental Use</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>250-254</td>
<td>Reserved for Private Use</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>255</td>
<td>Reserved</td>
<td>RFC 9946</td>
</tr>
</tbody>
</table>
<t>Note that value 4 is required for backward compatibility with <t>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
which hasn't been standardised yet (i.e., authMode greater than 1 or that hasn't been standardized yet (i.e., authMode is greater than 1 or
2).</t> 2).</t>
</section> </section>
<section anchor="ActivationCmdRequest" numbered="true" toc="default">
<section anchor="ActivationCmdRequest" <name>Test Activation PDU Command Request Registry</name>
title="Test Activation PDU Command Request Registry"> <t>IANA has created the "Test Activation PDU Command Request"
<t>IANA will create the "Test Activation PDU Command Request"
registry under the "UDP Speed Test Protocol (UDPSTP)" registry registry under the "UDP Speed Test Protocol (UDPSTP)" registry
group. The Test Setup PDU layout contains a cmdRequest field. The group. The Test Setup PDU layout contains a cmdRequest field. The
code points in this registry are allocated according to the code points in this registry are allocated according to the
registration procedures <xref target="RFC8126"/> described in Table registration procedures <xref target="RFC8126" format="default"/> desc
11.</t> ribed in
<xref target="reg-proc-test-act-pdu-command-req-reg"/>.</t>
<t><figure>
<artwork>Range(Decimal) Registration Procedures
===============================================================
0-127 IETF Review
128-239 Specification Required
240-249 Experimental
250-254 Private Use
255 Reserved
</artwork>
</figure>Table 11: Registration procedures for the Test Activation
PDU Command Request registry</t>
<t>Initially, IANA will assign the decimal values defined by Table
12 in the "Test Activation PDU Command Request" registry.</t>
<t><figure> <table anchor="reg-proc-test-act-pdu-command-req-reg">
<artwork>Value Description Reference <name>Registration Procedures for the Test Activation PDU Command Request Regi
=============================================================== stry</name>
0 No Request &lt;this RFC&gt; <thead>
<tr>
<th>Range(Decimal)</th>
<th>Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td>0-127</td>
<td>IETF Review</td>
</tr>
<tr>
<td>128-239</td>
<td>Specification Required</td>
</tr>
<tr>
<td>240-249</td>
<td>Experimental Use</td>
</tr>
<tr>
<td>250-254</td>
<td>Private Use</td>
</tr>
<tr>
<td>255</td>
<td>Reserved</td>
</tr>
</tbody>
</table>
1 Request test in Upstream &lt;this RFC&gt; <t>IANA has assigned decimal values
direction (client to server) in the "Test Activation PDU Command Request" registry as follows:</t>
2 Request test in Downstream &lt;this RFC&gt; <table anchor="init-test-act-pdu-comment-req-val">
direction (server to client) <name>Initial Values of the Test Activation PDU Command Request Registry</name
>
<thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>No Request</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>1</td>
<td>Request test in upstream direction (client to server)</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>2</td>
<td>Request test in downstream direction (server to client)</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>240-249</td>
<td>Reserved for Experimental Use</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>250-254</td>
<td>Reserved for Private Use</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>255</td>
<td>Reserved</td>
<td>RFC 9946</td>
</tr>
</tbody>
</table>
</artwork>
</figure>Table 12: Initial Test Activation PDU Command Request
values</t>
</section> </section>
<section anchor="Activation-modifierBitmap" numbered="true" toc="default
<section anchor="Activation-modifierBitmap" ">
title="Test Activation PDU Modifier Bitmap Registry"> <name>Test Activation PDU Modifier Bitmap Registry</name>
<t>IANA will create the "Test Activation PDU Modifier Bitmap" <t>IANA has created the "Test Activation PDU Modifier Bitmap"
registry under the "UDP Speed Test Protocol (UDPSTP)" registry registry under the "UDP Speed Test Protocol (UDPSTP)" registry
group. The Test Activation PDU layout (also) contains a group. The Test Activation PDU layout (also) contains a
modifierBitmap field. The bitmaps in this registry are allocated modifierBitmap field. The bitmaps in this registry are allocated
according to the registration procedures <xref target="RFC8126"/> according to the registration procedures <xref target="RFC8126" format
described in Table 13.</t> ="default"/>
described in <xref target="reg-proc-test-act-pdu-mod-bit-reg"/>.</t>
<t><figure>
<artwork>Range(Bitmap) Registration Procedures
===============================================================
00000000-01111111 IETF Review
10000000 Reserved
</artwork>
</figure>Table 13: Registration procedures for the Test Activation
PDU Modifier Bitmap registry</t>
<t>Initially, IANA will assign the bitmap values defined by Table 14
in the "Test Activation PDU Modifier Bitmap" registry.</t>
<t><figure> <table anchor="reg-proc-test-act-pdu-mod-bit-reg">
<artwork>Value Description Reference <name>Registration Procedures for the Test Activation PDU Modifier Bitmap Regi
=============================================================== stry</name>
0x00 No modifications &lt;this RFC&gt; <thead>
<tr>
<th>Range(Bitmap)</th>
<th>Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td>00000000-01111111</td>
<td>IETF Review</td>
</tr>
<tr>
<td>10000000</td>
<td>Reserved</td>
</tr>
</tbody>
</table>
0x01 Set when srIndexConf is &lt;this RFC&gt; <t>IANA has assigned bitmap values
start rate for search in the "Test Activation PDU Modifier Bitmap" registry as follows:</t>
0x02 Set for randomized &lt;this RFC&gt; <table anchor="init-test-act-pdu-mod-bit-val">
UDP payload <name>Initial Values of the Test Activation PDU Modifier Bitmap Registry</name
>
<thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0x00</td>
<td>No modifications</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>0x01</td>
<td>Set when srIndexConf is start rate for search</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>0x02</td>
<td>Set for randomized UDP payload</td>
<td>RFC 9946</td>
</tr>
</tbody>
</table>
</artwork>
</figure>Table 14: Initial Test Activation PDU Modifier Bitmap
values</t>
</section> </section>
<section anchor="Activation-rateAdjAlgo" numbered="true" toc="default">
<section anchor="Activation-rateAdjAlgo" <name>Test Activation PDU Rate Adjustment Algo.&nbsp;Registry</name>
title="Test Activation PDU Rate Adjustment Algo. Registry"> <t>IANA has created the "Test Activation PDU Rate Adjustment Algo."
<t>The Test Activation PDU layout contains a rateAdjAlgo field. The
table below defines the assigned Capitalized alphabetic UTF-8 values
in the registry.</t>
<t>IANA will create the "Test Activation PDU Rate Adjustment Algo."
registry under the "UDP Speed Test Protocol (UDPSTP)" registry registry under the "UDP Speed Test Protocol (UDPSTP)" registry
group. The Test Activation PDU layout contains a rateAdjAlgo field. group. The Test Activation PDU layout contains a rateAdjAlgo 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 <xref target="RFC8126"/> described in Table registration procedures <xref target="RFC8126" format="default"/> desc
15.</t> ribed in
<xref target="reg-proc-test-act-pdu-rate-adj-algo-reg"/>.</t>
<t><figure>
<artwork>Range(Capital alphabet. UTF-8) Registration Procedure
s
==========================================================
A-Y IETF review
Z Reserved
</artwork>
</figure>Table 15: Registration procedures for the Test Activation
PDU Rate Adjustment Algo. registry</t>
<t>Initially, IANA will assign the Capitalized alphabetic UTF-8
values, as well as the corresponding incremental numeric, defined by
Table 16 in the "Test Activation PDU Rate Adjustment Algo."
registry.</t>
<t><figure> <table anchor="reg-proc-test-act-pdu-rate-adj-algo-reg">
<artwork>Value(Numeric) Description Reference <name>Registration Procedures for the Test Activation PDU Rate Adjustment Algo
======================================================== . Registry</name>
A(n/a) Not used &lt;this RFC&gt; <thead>
<tr>
<th>Range(Capital alphabet / UTF-8)</th>
<th>Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td>A-Y</td>
<td>IETF Review</td>
</tr>
<tr>
<td>Z</td>
<td>Reserved</td>
</tr>
</tbody>
</table>
B(0) Rate algorithm Type B [Y.1540Amd2] <t>IANA has assigned capitalized alphabetic UTF-8
values, as well as the corresponding incremental numeric values, in th
e "Test Activation PDU Rate Adjustment Algo." registry as follows:</t>
C(1) Rate algorithm Type C [TR-471] <table anchor="init-test-activ-pdu-rate-adj-val">
<name>Initial Values of the Test Activation PDU Rate Adjustment Algo. Registry
</name>
<thead>
<tr>
<th>Value(Numeric)</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>A(n/a)</td>
<td>Not used</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>B(0)</td>
<td>Rate algorithm Type B</td>
<td><xref target="Y.1540Amd2"/></td>
</tr>
<tr>
<td>C(1)</td>
<td>Rate algorithm Type C</td>
<td><xref target="TR-471"/></td>
</tr>
</tbody>
</table>
</artwork>
</figure>Table 16: Initial Test Activation PDU Rate Adjustment
Algo. values</t>
</section> </section>
<section anchor="Activation-cmdResponse" numbered="true" toc="default">
<section anchor="Activation-cmdResponse" <name>Test Activation PDU Command Response Field Registry</name>
title="Test Activation PDU Command Response Field Registry"> <t>IANA has created the "Test Activation PDU Command Response Field"
<t>IANA will create the "Test Activation PDU Command Response Field"
registry under the "UDP Speed Test Protocol (UDPSTP)" registry registry under the "UDP Speed Test Protocol (UDPSTP)" registry
group. The Test Activation PDU layout (also) contains a cmdResponse group. The Test Activation PDU layout (also) contains a cmdResponse
field. The code points in this registry are allocated according to field. The code points in this registry are allocated according to
the registration procedures <xref target="RFC8126"/> described in the registration procedures <xref target="RFC8126" format="default"/>
Table 17.</t> described in
<xref target="reg-proc-test-act-pdu-command-response-field-reg"/>.</t>
<t><figure>
<artwork>Range(Decimal) Registration Procedures
===============================================================
0-127 IETF Review
128-239 Specification Required
240-249 Experimental
250-254 Private Use
255 Reserved
</artwork>
</figure>Table 17: Registration procedures for the Test Activation
PDU Command Response Field registry</t>
<t>Initially, IANA will assign the decimal values defined by Table
18 in the "Test Activation PDU Command Response Field" registry.</t>
<t><figure> <table anchor="reg-proc-test-act-pdu-command-response-field-reg">
<artwork>Value Description Reference <name>Registration Procedures for the Test Activation PDU Command Response Fie
=============================================================== ld Registry</name>
0 None (used by &lt;this RFC&gt; <thead>
client in Request) <tr>
<th>Range(Decimal)</th>
<th>Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td>0-127</td>
<td>IETF Review</td>
</tr>
<tr>
<td>128-239</td>
<td>Specification Required</td>
</tr>
<tr>
<td>240-249</td>
<td>Experimental Use</td>
</tr>
<tr>
<td>250-254</td>
<td>Private Use</td>
</tr>
<tr>
<td>255</td>
<td>Reserved</td>
</tr>
</tbody>
</table>
1 Server Acknowledgment &lt;this RFC&gt; <t>IANA has assigned decimal values
in the "Test Activation PDU Command Response Field" registry as follow
s:</t>
2 Server indicates an error &lt;this RFC&gt; <table anchor="init-test-act-pdu-command-resp-field-val">
<name>Initial Values of the Test Activation PDU Command Response Field
Registry</name>
<thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>None (used by client in Request)</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>1</td>
<td>Server acknowledgment</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>2</td>
<td>Server indicates an error</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>240-249</td>
<td>Reserved for Experimental Use</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>250-254</td>
<td>Reserved for Private Use</td>
<td>RFC 9946</td>
</tr>
<tr>
<td>255</td>
<td>Reserved</td>
<td>RFC 9946</td>
</tr>
</tbody>
</table>
</artwork>
</figure>Table 18: Initial Test Activation PDU Command Response
Field values</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Guidelines for the Designated Experts"> <name>Guidelines for Designated Experts</name>
<t>It is suggested that multiple designated experts be appointed for <t>It is suggested that multiple designated experts be appointed for
registry change requests.</t> registry change requests.</t>
<t>Criteria that should be applied by the designated experts include <t>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 the entries and whether the registration description is clear and fits the
purpose of this registry.</t> purpose of this registry.</t>
<t>Registration requests are evaluated within a two-week review period <t>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.</t> how to make the request successful.</t>
</section> </section>
</section> </section>
<section title="Acknowledgments">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.076 <name>References</name>
8.xml" <references>
xmlns:xi="http://www.w3.org/2001/XInclude"/> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.079 768.xml"/>
1.xml" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
xmlns:xi="http://www.w3.org/2001/XInclude"/> 791.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211 119.xml"/>
9.xml" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
xmlns:xi="http://www.w3.org/2001/XInclude"/> 044.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.504 234.xml"/>
4.xml" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
xmlns:xi="http://www.w3.org/2001/XInclude"/> 210.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.623 085.xml"/>
4.xml" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
xmlns:xi="http://www.w3.org/2001/XInclude"/> 126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.721 174.xml"/>
0.xml" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
xmlns:xi="http://www.w3.org/2001/XInclude"/> 899.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.808 097.xml"/>
5.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.812
6.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
4.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.889
9.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.909
7.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<reference anchor="TR-471"
target="https://www.broadband-forum.org/technical/download/TR-4
71.pdf">
<front>
<title>Broadband Forum TR-471: IP Layer Capacity Metrics and
Measurement, Issue 4</title>
<author fullname="" initials="Editor" surname="Morton, A,">
<organization>AT&amp;T Labs</organization>
</author>
<date day="" month="September" year="2024"/> <reference anchor="TR-471" target="https://www.broadband-forum.org/pdfs/
</front> tr-471-4-0-0.pdf">
</reference> <front>
<title>Maximum IP-Layer Capacity Metric, Related Metrics,
and Measurements</title>
<author>
<organization>Broadband Forum</organization>
</author>
<date month="September" year="2024"/>
</front>
<refcontent>TR-471, Issue 4</refcontent>
</reference>
<reference anchor="Y.1540" derivedAnchor="Y.1540" quoteTitle="true" <reference anchor="Y.1540" target="https://www.itu.int/rec/T-REC-Y.1540-
target="https://www.itu.int/rec/T-REC-Y.1540-201912-I/en"> 201912-I/en">
<front> <front>
<title>Internet protocol data communication service - IP packet <title>Internet protocol data communication service - IP packet
transfer and availability performance parameters</title> transfer and availability performance parameters</title>
<author>
<organization showOnFrontPage="true">ITU-T</organization>
</author>
<date month="December" year="2019"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="Y.1540"/>
</reference>
<author> <reference anchor="Y.1540Amd2" target="https://www.itu.int/rec/T-REC-Y.1
<organization showOnFrontPage="true">ITU-T</organization> 540-202303-I!Amd2/en">
</author> <front>
<title>Internet protocol data communication service - IP packet
<date month="December" year="2019"/> transfer and availability performance parameters, Amendment 2 -
</front>
<refcontent>ITU-T Recommendation Y.1540</refcontent>
</reference>
<reference anchor="Y.1540Amd2" derivedAnchor="Y.1540Amd2"
quoteTitle="true"
target="https://www.itu.int/rec/T-REC-Y.1540-201912-I/en">
<front>
<title>Internet protocol data communication service - IP packet
transfer and availability performance parameters Amendment 2 -
Revised Annex B: Additional search algorithms for IP-based capacity Revised Annex B: Additional search algorithms for IP-based capacity
parameters and methods of measurement</title> parameters and methods of measurement</title>
<author>
<organization showOnFrontPage="true">ITU-T</organization>
</author>
<date month="March" year="2023"/>
</front>
<refcontent>ITU-T Recommendation Y.1540 Amd. 2</refcontent>
</reference>
<author> <reference anchor="NIST800-108" target="https://nvlpubs.nist.gov/nistpub
<organization showOnFrontPage="true">ITU-T</organization> s/SpecialPublications/NIST.SP.800-108r1-upd1.pdf">
</author> <front>
<title>Recommendation for Key Derivation Using Pseudorandom
<date month="March" year="2023"/> Functions</title>
</front> <author fullname="Lily Chen">
<organization>National Institute of Standards and
<refcontent>ITU-T Recommendation Y.1540 Amd. 2</refcontent>
</reference>
<reference anchor="NIST800-108"
target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/N
IST.SP.800-108r1-upd1.pdf">
<front>
<title>Recommendation for Key Derivation Using Pseudorandom
Functions (Revised, Update 1)</title>
<author fullname="Lily Chen" initials="LC" surname="Chen">
<organization>National Institute of Standards and
Technology</organization> Technology</organization>
</author> </author>
<date month="August" year="2022"/>
<date month="August" year="2022"/> </front>
</front> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-108r1-upd1"/>
</reference> <seriesInfo name="NIST SP" value="800-108r1-upd1"/>
</reference>
<reference anchor="C-Prog">
<front>
<title>ISO/IEC 9899:1999 Programming languages - C</title>
<author>
<organization>ISO/IEC</organization>
</author>
<date year="1999"/>
</front>
</reference>
</references>
<references title="Informative References">
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.314
8.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.465
6.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.513 <!-- [rfced] This reference points to the C99 version of the C Standard,
6.xml" which has been withdrawn (see
xmlns:xi="http://www.w3.org/2001/XInclude"/> <https://www.open-std.org/jtc1/sc22/wg14/www/projects#9899>). Should
this reference point specifically to the C99 version or should it
point to the most up-to-date version (ISO/IEC 9899:2024) as shown
below?
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.535 Current:
7.xml" [C-Prog] ISO/IEC, "Programming languages - C", ISO/IEC 9899:1999,
xmlns:xi="http://www.w3.org/2001/XInclude"/> 1999, <https://www.iso.org/standard/29237.html>.
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.749 Perhaps:
7.xml" [C-Prog]
xmlns:xi="http://www.w3.org/2001/XInclude"/> ISO/IEC, "Information technology - Programming languages
- C", ISO/IEC 9899:2024, 2024,
<https://www.iso.org/standard/82075.html>.
-->
<reference anchor="C-Prog" target="https://www.iso.org/standard/29237.ht
ml">
<front>
<title>Programming languages -- C</title>
<author>
<organization>ISO/IEC</organization>
</author>
<date year="1999"/>
</front>
<seriesInfo name="ISO/IEC" value="9899:1999"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.759 <!-- Note to PE: XML for possible update to [C-Prog]
4.xml" (note I placed backslashes to avoid breaking XML comment)
xmlns:xi="http://www.w3.org/2001/XInclude"/> <reference anchor="C-Prog" target="https://www.iso.org/standard/82075.ht
ml">
<front>
<title>Information technology -/- Programming languages -/- C</title
>
<author>
<organization>ISO/IEC</organization>
</author>
<date year="2024"/>
</front>
<seriesInfo name="ISO/IEC" value="9899:2024"/>
</reference>
-->
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
148.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
656.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
136.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
357.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
497.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
594.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
337.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
762.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
145.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.833 <reference anchor="EVP_KDF-KB" target="https://docs.openssl.org/master/m
7.xml" an7/EVP_KDF-KB/">
xmlns:xi="http://www.w3.org/2001/XInclude"/> <front>
<title>EVP_KDF-KB - The Key-Based EVP_KDF implementation</title>
<author/>
</front>
<refcontent>OpenSSL Documentation</refcontent>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.876 </references>
2.xml"
xmlns:xi="http://www.w3.org/2001/XInclude"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.914 </references>
5.xml" <section anchor="KDF-Example" numbered="true" toc="default">
xmlns:xi="http://www.w3.org/2001/XInclude"/> <name>KDF Example (OpenSSL)</name>
<reference anchor="EVP_KDF-KB" <!--[rfced] The KDF Example in Appendix A has 7 lines over the character
target="https://docs.openssl.org/master/man7/EVP_KDF-KB/"> limit. Please let us know how you would like to break/wrap the
<front> following lines.
<title>The Key-Based EVP_KDF implementation</title>
<author/> Original:
</front> *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MODE, "COUNTER", 0); - 8
</reference> characters over
</references> *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MAC, "HMAC", 0); - 4 ove
r
*p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST, "SHA256", 0); -
9 over
*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_KEY, Kin, strlen(Kin));
- 12 over
*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SALT, "UDPSTP", 6); - 8
over
*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_INFO, context, var); -
9 over
*p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_USE_SEPARATOR, &var); - 7
over
-->
<section anchor="KDF-Example" title="KDF Example (OpenSSL)"> <figure anchor="KDFfigure">
<figure anchor="KDFfigure" title="KDF Example Code Snippet"> <name>KDF Example Code Snippet</name>
<artwork> <sourcecode name="" type="c" markers="true"><![CDATA[
&lt;CODE BEGINS&gt;
// //
// Output individual authentication keys of length SHA256_KEY_LEN // Output individual authentication keys of length SHA256_KEY_LEN
// from derived key material. // from derived key material.
// //
// Return Values: 0 = Failure, 1 = Success // Return Values: 0 = Failure, 1 = Success
// //
int kdf_hmac_sha256(char *Kin, uint32_t authUnixTime, int kdf_hmac_sha256(char *Kin, uint32_t authUnixTime,
unsigned char *cAuthKey, // Client key unsigned char *cAuthKey, // Client key
unsigned char *sAuthKey) { // Server key unsigned char *sAuthKey) { // Server key
skipping to change at line 3265 skipping to change at line 3877
*p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MAC, "HMAC", 0); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_MAC, "HMAC", 0);
*p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST, "SHA256", 0); *p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST, "SHA256", 0);
*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_KEY, Kin, strlen(Kin)) ; *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_KEY, Kin, strlen(Kin)) ;
*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SALT, "UDPSTP", 6); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SALT, "UDPSTP", 6);
var = snprintf(context, sizeof(context), "%u", authUnixTime); var = snprintf(context, sizeof(context), "%u", authUnixTime);
*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_INFO, context, var); *p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_INFO, context, var);
// //
// Confirm the following are enabled // Confirm the following are enabled
// //
var = 1; var = 1;
*p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_USE_L, &amp;var); *p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_USE_L, &var);
*p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_USE_SEPARATOR, &amp;var); *p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_USE_SEPARATOR, &var);
// //
// Set counter length in bits (available as of OpenSSL 3.1) // Set counter length in bits (available as of OpenSSL 3.1)
// //
var = 32; // Length of 32 is backward compatible with OpenSSL 3.0 var = 32; // Length of 32 is backward compatible with OpenSSL 3.0
*p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_R, &amp;var); *p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_R, &var);
*p++ = OSSL_PARAM_construct_end(); *p++ = OSSL_PARAM_construct_end();
// --------------------------------------------------------- // ---------------------------------------------------------
// //
// Derive key material // Derive key material
// //
if (EVP_KDF_derive(kctx, keybuf, keylen, params) &lt; 1) { if (EVP_KDF_derive(kctx, keybuf, keylen, params) < 1) {
EVP_KDF_CTX_free(kctx); EVP_KDF_CTX_free(kctx);
EVP_KDF_free(kdf); EVP_KDF_free(kdf);
return 0; return 0;
} }
// //
// Output individual keys // Output individual keys
// //
keyptr = keybuf; keyptr = keybuf;
memcpy(cAuthKey, keyptr, SHA256_KEY_LEN); memcpy(cAuthKey, keyptr, SHA256_KEY_LEN);
keyptr += SHA256_KEY_LEN; keyptr += SHA256_KEY_LEN;
memcpy(sAuthKey, keyptr, SHA256_KEY_LEN); memcpy(sAuthKey, keyptr, SHA256_KEY_LEN);
// //
// Cleanup // Cleanup
// //
EVP_KDF_CTX_free(kctx); EVP_KDF_CTX_free(kctx);
EVP_KDF_free(kdf); EVP_KDF_free(kdf);
return 1; return 1;
} }
&lt;CODE ENDS&gt; ]]></sourcecode>
</artwork>
</figure> </figure>
</section>
<section numbered="false" toc="default">
<!--[rfced] How may we clarify "further navigated the document". Would
"provided further comments" be clearer as shown below?
Original:
Mohamed Boucadair's AD review improved comprehensibility of the
document, and he further navigated the document well through the
final review stages.
Perhaps:
Mohamed Boucadair's AD review improved comprehensibility of the
document, and he provided further comments through the final
review stages.
-->
<name>Acknowledgments</name>
<t>This document was edited by <contact fullname="Al Morton"/>, who
passed away before being able to finalize this work. <contact
fullname="Ruediger Geib"/> only joined later to help finalize this
specification.</t>
<t>Thanks to <contact fullname="Lincoln Lavoie"/>, <contact
fullname="Can Desem"/>, <contact fullname="Greg Mirsky"/>, <contact
fullname="Bjoern Ivar Teigen"/>, <contact fullname="Ken Kerpez"/>, and
<contact fullname="Chen Li"/> for reviewing this specification and providi
ng
helpful suggestions and areas for further development. <contact
fullname="Mohamed Boucadair"/>'s AD review improved comprehensibility of
the document, and he further navigated the document well through the
final review stages. <contact fullname="Tommy Pauly"/> shepherded this
document. Further comments by <contact fullname="Gorry Fairhurst"/>,
<contact fullname="Éric Vyncke"/>, <contact fullname="Roman Danyliw"/>,
<contact fullname="Gunter Van de Velde"/>, <contact fullname="Deb
Cooley"/>, <contact fullname="Tianran Zhou"/>, <contact fullname="Andy
Newton"/>, <contact fullname="Giuseppe Fioccola"/>, <contact
fullname="Lars Eggert"/>, <contact fullname="Erik Kline"/>, and <contact
fullname="Benson Muite"/> helped to shape the document. <contact
fullname="David Dong"/> and <contact fullname="Amanda Baber"/> provided
early reviews of the IANA Considerations section.</t>
<t>Starting with the early SEC-DIR review, <contact fullname="Brian
Weis"/> provided constructive guidance regarding numerous security-related
protocol issues. The Crypto Forum Research Group reviewed these parts, aga
in
providing guidance. <contact fullname="Magnus Westerlund"/>'s review
resulted in further changes and refinements. Ultimately, <contact
fullname="Paul Wouters"/>' feedback was critical in finalizing the
chosen security approach.</t>
</section> </section>
</back> </back>
<!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside)
.
Example:
Note: When this specification is used for network debugging, it may
be useful for fragmentation to be under the control of the test
administrator.
-->
<!-- [rfced] Terminology
a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.
[byte] vs. byte
[ms] vs. ms vs. millisecond
[s] vs. second
[us] vs. us vs. microsecond
Loss vs. loss
Parameter vs. parameter
Range vs. range
Sending Rate Table vs. sending rate table
[Note: RFC 9097 uses the lowercase form. Also consider
whether the following terms need an update:
- Sending Rate structure
- Configured Sending Rate Table index]
b) FYI - We updated the following terms to reflect the forms on the
right for consistency within this document and/or with other
RFCs. Please let us know if any further updates are needed.
Bit rate -> bit rate
data phase -> Data phase
command response -> Command Response
Firewall -> firewall (per RFC 9097)
IP-layer Capacity metric -> IP-layer Capacity Metric (per RFC 9097)
Load Rate Adjustment Algorithm -> load rate adjustment algorithm
Maximum IP-Layer Capacity metric -> Maximum IP-Layer Capacity Metric
(per RFC 9097)
message verification procedure -> Message Verification Procedure
method of measurement -> Method of Measurement (Per 9097)
Payload Content -> payload content (per 9097)
Security mode of operation -> security mode of operation
Setup request -> Setup Request
test activation request -> Test Activation Request
Test traffic -> test traffic (per RFC 9097)
Traditional size -> traditional size
c) We note the following variances in the text - are these terms the
same or different? Please let us know if any updates are needed for
consistency.
Bulk Transport Capacity vs. Bulk Capacity
Command Server Response code vs. Command Response code
Maximum IP-Layer Capacity Metric vs. Maximum IP Capacity
Setup Request PDU (4 instances) vs. Request PDU (4 instances)
[Note: Is "Request PDU" correct or should it be updated to
"Setup Request PDU" or "Test Activation Request PDU"?]
d) "Sub-Interval" and "sisSav"
i) We note the following variances related to "sisSav" (placement and
inclusion of "saved"). Should these be made consistent?
Original:
sisSav: Sub-interval statistics saved (completed)
struct subIntStats sisSav; // Sub-interval saved stats
Sub-Interval Statistics structure (sisSav)
Perhaps:
sisSav: Sub-interval statistics saved (completed)
struct subIntStats sisSav; // Sub-interval stats saved
Sub-interval statistics saved (sisSav) structure
ii) We also note the following variances; please let us know
how we may make these consistent.
Sub-Interval vs. Sub-interval vs. sub-interval
Some examples:
Sub-interval sequence
Sub-interval period
Sub-Interval byte count
during the Sub-Interval
each sub-interval is
the last saved (completed) sub-interval
Sub-Interval Statistics vs. Sub-interval statistics
e) We note the use of "Null Request". Should this perhaps be
"NULL Request", "NULL request", or other? We ask as we only
see "NULL request" used in other RFCs.
f) We note that the following terms appear as uppercase in the running
text but as lowercase in the descriptions in Figures 3, 5, 7, 9, and/or
11. Should we update the figures to reflect the uppercase forms for
consistency or is the case okay as is?
Current:
Null request
Command request
command response
load PDU
Out-of-Order
Sending rate structure
Setup request
Setup response
Status feedback header
status PDU
Perhaps:
Null Request (or other per author response to the question above)
Command Request
Command Response
Load PDU
Out-of-order
Sending Rate structure
Setup Request
Setup Response
Status Feedback header
Status PDU
-->
<!-- [rfced] Abbreviations
a) FYI - We have added expansions for the following abbreviations per
Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review these as
well as each expansion in the document carefully to ensure
correctness.
Don't Fragment (DF)
Hashed Message Authentication Code (HMAC)
b) FYI - We updated the following expansion to the form on the right for
correctness. Please let us know of any concerns.
Packetization Layer Path MTU Discovery for Datagram Transports (DPLPMTUD) ->
Datagram Packetization Layer PMTU Discovery (DPLPMTUD)
c) FYI - We updated "UDPST" to "UDPSTP" (one instance) as follows. Please
let us know if that is not correct.
Original:
The number n may depend on the implementation and on typical
characteristics of environments, where UDPST is deployed (like
mobile networks or Wi-Fi).
Current:
The number n may depend on the implementation and on typical
characteristics of environments, where UDPSTP is deployed (like
mobile networks or Wi-Fi).
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Please consider whether "traditional" should be updated for clarity.
While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/
nist-research-library/nist-technical-series-publications-author-instructions#tab
le1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.
-->
</rfc> </rfc>
 End of changes. 622 change blocks. 
1823 lines changed or deleted 3020 lines changed or added

This html diff was produced by rfcdiff 1.48.