Test Protocol for One-way IP Capacity Measurement
draft-ietf-ippm-capacity-protocol-05
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Len Ciavattone , Ruediger Geib | ||
| Last updated | 2023-06-30 (Latest revision 2022-12-07) | ||
| Replaces | draft-morton-ippm-capacity-metric-protocol | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
SECDIR Early review
(of
-04)
by Brian Weis
Has issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-ippm-capacity-protocol-05
Network Working Group L. Ciavattone
Internet-Draft AT&T Labs
Intended status: Standards Track R. Geib
Expires: 1 January 2024 Deutsche Telekom
30 June 2023
Test Protocol for One-way IP Capacity Measurement
draft-ietf-ippm-capacity-protocol-05
Abstract
This memo addresses the problem of protocol support for measuring
Network Capacity metrics in RFC 9097, where the method deploys a
feedback channel from the receiver to control the sender's
transmission rate in near-real-time. This memo defines a simple
protocol to perform the RFC 9097 (and other) measurements.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 January 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Ciavattone & Geib Expires 1 January 2024 [Page 1]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Scope, Goals, and Applicability . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Parameters and Security-related Operations . . . . . . . . . 6
4.1. Parameters and Definitions . . . . . . . . . . . . . . . 6
4.2. Security Mode Operations . . . . . . . . . . . . . . . . 6
4.2.1. Mode 0: OPTIONAL unauthenticated mode . . . . . . . . 7
4.2.2. Mode 1: REQUIRED authentication mode . . . . . . . . 7
4.2.3. Mode 2: OPTIONAL authentication for Data phase . . . 8
4.2.4. Mode 3: OPTIONAL Partial Encryption - Control and
Status Feedback . . . . . . . . . . . . . . . . . . . 8
4.2.5. OPTIONAL Fully Encrypted mode . . . . . . . . . . . . 10
4.3. Key Management . . . . . . . . . . . . . . . . . . . . . 11
4.4. Firewall Configuration . . . . . . . . . . . . . . . . . 12
5. Test Setup Request and Response Exchange . . . . . . . . . . 12
5.1. Client Generates Test Setup Request . . . . . . . . . . . 12
5.1.1. Authenticated Modes . . . . . . . . . . . . . . . . . 15
5.1.2. Unauthenticated Mode . . . . . . . . . . . . . . . . 15
5.1.3. Partial Encrypted Mode . . . . . . . . . . . . . . . 15
5.2. Server Processes Test Setup Request and Generates
Response . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.1. Test Setup Request Processing - Rejection . . . . . . 16
5.2.2. Test Setup Request Processing - Acceptance . . . . . 19
5.3. Setup Response Processing at the Client . . . . . . . . . 22
6. Test Activation Request and Response . . . . . . . . . . . . 22
6.1. Client Generates Test Activation Request . . . . . . . . 23
6.1.1. Authenticated Modes . . . . . . . . . . . . . . . . . 26
6.1.2. Unauthenticated Mode . . . . . . . . . . . . . . . . 26
6.1.3. Partial Encrypted Mode . . . . . . . . . . . . . . . 26
6.2. Server Processes Test Activation Request and Generates
Response . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2.1. Server Rejects or Modifies Request . . . . . . . . . 26
6.2.2. Server Accepts Request and Generates Response . . . . 28
6.3. Client Processes Test Activation Response . . . . . . . . 30
7. Test Stream Transmission and Measurement Feedback Messages . 31
7.1. Test Packet PDU and Roles . . . . . . . . . . . . . . . . 31
7.2. Status PDU . . . . . . . . . . . . . . . . . . . . . . . 35
8. Stopping the Test . . . . . . . . . . . . . . . . . . . . . . 41
9. Method of Measurement . . . . . . . . . . . . . . . . . . . . 42
9.1. Notes on Interface Measurements . . . . . . . . . . . . . 42
9.2. Running Code . . . . . . . . . . . . . . . . . . . . . . 42
10. Security Considerations . . . . . . . . . . . . . . . . . . . 43
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
11.1. New System Port Assignment . . . . . . . . . . . . . . . 45
11.2. New UDPST Registry Group . . . . . . . . . . . . . . . . 45
Ciavattone & Geib Expires 1 January 2024 [Page 2]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
11.2.1. PDU Identifier Registry . . . . . . . . . . . . . . 45
11.2.2. Protocol Number Registry . . . . . . . . . . . . . . 46
11.2.3. Test Setup PDU Modifier Bitmap Registry . . . . . . 46
11.2.4. Test Setup PDU Authentication Mode Registry . . . . 47
11.2.5. Test Setup PDU Command Response Field Registry . . . 47
11.2.6. Test Activation PDU Modifier Bitmap Registry . . . . 48
11.2.7. Test Activation PDU Command Request Registry . . . . 49
11.2.8. Test Activation PDU Rate Adjustment Algo.
Registry . . . . . . . . . . . . . . . . . . . . . . 49
11.2.9. Test Activation PDU Command Response Field
Registry . . . . . . . . . . . . . . . . . . . . . . 49
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
13.1. Normative References . . . . . . . . . . . . . . . . . . 50
13.2. Informative References . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction
The IETF's efforts to define Network and Bulk Transport Capacity have
been chartered and finally progressed after over twenty years.
In that time, the performance community has seen development of
Informative definitions in [RFC3148] for Framework for Bulk Transport
Capacity (BTC), RFC 5136 for Network Capacity and Maximum IP-layer
Capacity, and the Experimental metric definitions and methods in
[RFC8337], Model-Based Metrics for BTC.
This memo looks at the problem of measuring Network Capacity metrics
defined in [RFC9097] where the method deploys a feedback channel from
the receiver to control the sender's transmission rate in near-real-
time.
Although there are several test protocols already available for
support and management of active measurements, this protocol is a
major departure from their operation:
1. UDP transport, not TCP, is used for Control phase messages (e.g.,
Test Setup, Test Activation) and Data phase messages (e.g., Load,
Status Feedback).
2. TWAMP [RFC5357] and STAMP [RFC8762] use the philosophy that one
host is a Session-Reflector, sending test packets every time they
receive a test packet. This protocol supports a one-way test
with periodic status messages returned to the sender. These
messages are also a basis for on-path Round-trip delay
measurements, which are a key input to the load adjustment search
algorithm.
Ciavattone & Geib Expires 1 January 2024 [Page 3]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
3. OWAMP [RFC4656] supports one-way testing with results Fetch at
the end of the test session. This protocol supports a one-way
test and requires periodic status messages returned to the sender
to support the load adjustment search algorithm.
4. The security features of OWAMP [RFC4656] and TWAMP [RFC5357] have
been described as "unusual", to the point that IESG approved
their use while also asking that these methods not be used again.
Further, the common OWAMP [RFC4656] and TWAMP [RFC5357] approach
to security is over 15 years old at this time.
Note: the -00 update of this draft will be the last that describes
version 8 of the protocol in the running code. Updates -01 and -02
of the draft correspond to version 9 of the protocol, which strives
to allow interoperability with version 8. The -03 and -04 updates of
the draft incorporate new security modes of operation, and correspond
to version 10 of the protocol.
Ruediger Geib joined the team of authors to help completing this
draft. He's not replacing Al Morton, as Al can't be replaced.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14[RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Scope, Goals, and Applicability
The scope of this memo is to define a protocol to measure the Maximum
IP-Layer Capacity metric and according to the standardized method.
We note that aspects of this protocol and end-host configuration can
lead to support of additional forms of measurement, such as
application emulation enabled by creative use of the Load Adjustment
algorithm.
The continued goal is to harmonize the specified IP-Layer Capacity
metric and method across the industry, and this protocol supports the
specifications of IETF and other Standards Development Organizations.
All active testing protocols currently defined by the IPPM WG are
UDP-based, but this protocol specifies both control and test
protocols using UDP transport. Also, a feedback message stream
continues operating during testing to convey results and dynamic
configurations.
Ciavattone & Geib Expires 1 January 2024 [Page 4]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
The primary application of the protocol described here is the same as
in Section 2 of [RFC7497] where:
* The access portion of the network is the focus of this problem
statement. The user typically subscribes to a service with
bidirectional access partly described by rates in bits per second.
3. Protocol Overview
This section gives an informative overview of the communication
protocol between two test end-points (without expressing requirements
or describing the authentication and encryption aspects; later
sections provide these details and requirements).
One end-point takes the role of server, listening for connection
requests on a well-known destination port from the other end-point,
the client.
The client requires configuration of a test direction parameter
(upstream or downstream test, where the client performs the role of
sender or receiver, respectively) as well as the hostname or IP
address of the server in order to begin the setup and configuration
exchanges with the server.
The protocol uses UDP transport and has four types of exchanges in
two phases. Exchanges 1 and 2 constitute the Control phase, while
exchanges 3 and 4 constitute the Data phase.
1. Setup Request and Response Exchange: The client requests to begin
a test by communicating its protocol version, intended security
mode, and jumbo datagram support. The server either confirms
matching configuration or rejects the connection. The server
also communicates the ephemeral port for further communication
when accepting the client's request.
2. Test Activation Request and Response: the client composes a
request conveying parameters such as the testing direction, the
duration of the test interval and test sub-intervals, and various
thresholds. 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. Note that the
client assumes that the Test Activation exchange has opened any
co-located firewalls and network address/port translators for the
test connection (in response to the Request packet on the
ephemeral port) and the traffic that follows. If the Test
Activation Request is rejected or fails, the client assumes that
the firewall will close the address/port combination after the
firewall's configured idle traffic time-out.
Ciavattone & Geib Expires 1 January 2024 [Page 5]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
3. Test Stream Transmission and Measurement Feedback Messages:
Testing proceeds with one end-point sending load PDUs and the
other end-point receiving the load PDUs and sending frequent
status messages to communicate status and transmission conditions
there. The feedback messages are input to a load-control
algorithm at the server, which controls future sending rates at
either end-point as needed. The choice to locate the load-
control algorithm at the server, regardless of transmission
direction, means that the algorithm can be updated more easily at
a host within the network, and at a fewer number of hosts than
the number of clients.
4. Stopping the Test: When the specified test duration has been
reached, the server initiates the exchange to stop the test by
setting the STOP1 indication in load PDUs or status feedback
messages. The client acknowledges by setting the STOP2 in
further load PDUs or messages, and a graceful connection
termination at each end-point follows. (Since the load PDUs and
feedback messages are used, this exchange is kind of a sub-
exchange of 3.) If the Test traffic stops or the communication
path fails, the client assumes that the firewall will close the
address/port combination after the firewall's configured idle
traffic time-out.
5. Both the client and server react to unexpected interruptions in
the Control phase or test traffic. Watchdog timers limit the
time a server or client will wait before stopping all traffic and
terminating a test.
4. Parameters and Security-related Operations
4.1. Parameters and Definitions
For Parameters related to the Maximum IP-Layer Capacity Metric and
Method, please see Section 4 of [RFC9097].
4.2. Security Mode Operations
There are four security modes of operation:
1. A REQUIRED mode with authentication during the Control phase:
Test Setup and Test Activation exchanges.
2. An OPTIONAL mode with additional authentication during the Data
phase: applicable only to the Status Feedback messages.
Ciavattone & Geib Expires 1 January 2024 [Page 6]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
3. An OPTIONAL unauthenticated mode for all messages.
4. An OPTIONAL mode with encryption of the Control phase exchanges
and the Status Feedback messages.
5. For full encryption, OPTIONAL operation of both Control and Data
phase exchanges inside an encrypted tunnel chosen and
instantiated via a bilateral agreement between the users.
The requirements below refer to the PDUs in the sections that follow,
primarily the authUnixTime field and the authDigest field. The roles
in this section have been generalized so that the requirements for
the PDU sender and receiver can be re-used and referred to elsewhere.
4.2.1. Mode 0: OPTIONAL unauthenticated mode
In the OPTIONAL unauthenticated mode, all PDU senders SHALL set the
authUnixTime field and the authDigest field of all packets to all
zeroes.
Any errors (configuration miss-match between client and server) found
in the Test Setup exchange or the Test Activation exchange SHOULD
result in silent rejection (no further packets sent on the address/
port pairs). The exception is when the testing hosts have been
configured for trouble-shooting Control phase failures and rejection
messages will aid in the process.
4.2.2. Mode 1: REQUIRED authentication mode
In the REQUIRED authentication mode, the client and the server SHALL
be configured to use one of a number of shared secret keys.
During the Control phase, the sender SHALL read the current time and
populate the authUnixTime field, then calculate the authDigest field
of the request packet (with the authDigest field set to all zeroes)
according to [RFC6234] and send the packet to the receiver.
Upon reception, the receiver SHALL validate the message PDU for
validity of the authDigest, the authUnixTime field for acceptable
immediacy, correct length, and formatting (PDU-specific fields are
also checked, such as protocol version).
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). The exception is when the testing hosts
have been configured for trouble-shooting Control phase failures and
rejection messages will aid in the process.
Ciavattone & Geib Expires 1 January 2024 [Page 7]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
If the validation succeeds, the receiver SHALL continue with the
Control phase and compose a successful response or a response
indicating the error conditions identified.
This process SHALL be executed for each request and response in the
Test Setup exchange (Section 5) and the Test Activation exchange
(Section 6), amounting to four packets exchanged (plus any "dummy"
packets needed).
4.2.3. Mode 2: OPTIONAL authentication for Data phase
When using the OPTIONAL authentication during the Data Phase, the
process SHALL be applied to the Status PDU only. The client sends
the Status PDU in a downstream test, and the server sends in an
upstream test.
The Status PDU sender reads the current time and populates the
authUnixTime field, then calculates the authDigest field of the
entire Status PDU (see Section 7.2). The Authentication Fields
appear at the end of the Status PDU.
Upon reception of a Status PDU in mode 2, the receiver SHALL validate
the message PDU for validity of the authDigest, the authUnixTime
field for acceptable immediacy, correct length, and formatting (PDU-
specific fields are also checked, such as protocol version).
If the authentication validation fails, the receiver SHALL ignore the
message. If the watchdog timer expires (due to successive failed
validations, the test session will prematurely terminate (no further
load traffic SHALL be transmitted).
If this optional mode has not been selected, then the authUnixTime
field and the authDigest field of the Status PDU (see Section 7.2)
SHALL be populated with all zeroes.
4.2.4. Mode 3: OPTIONAL Partial Encryption - Control and Status
Feedback
This mode is mutually exclusive with the Authenticated modes (1 and
2). The encryption algorithm specified includes integrity
protection. This mode re-uses several protocol fields beginning with
"auth", which is reasonable since both authentication and encryption
are provided (the field format is presented in later sections).
Ciavattone & Geib Expires 1 January 2024 [Page 8]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
When using the OPTIONAL Partial Encryption, the process SHALL be
applied to the Test Setup Request, the Test Setup Response, the Test
Activation Request, the Test Activation Response, and the Status PDU.
The client sends the Status PDU in a downstream test, and the server
sends it in an upstream test.
In the OPTIONAL Partial encryption mode, the client and the server
SHALL be configured to use one of a number of shared secret keys (see
keyID).
The following encryption specifications SHALL be used:
1. Advanced Encryption Standard, AES, according to Federal
Information Processing Standards Publication 197 [FIPS-197].
2. Galois/Counter Mode (GCM) [GCM]
3. Key size of 256 bits (fixed block size of 128 bits)
The sender (intending to use encryption) SHALL read the current time
and populate the authUnixTime field of the request packet. Then, the
sender SHALL encrypt the header up to but not including the
Initialization Vector (IV) field. The IV SHALL be stored in the IV
field as-is, with any unused bits as MBZ, and communicated in the
clear. Finally, the sender SHALL send the packet with encrypted PDU
to the receiver.
Upon reception, the receiver SHALL decrypt the PDU using the included
IV and shared key, and then validate the correct header length, ID,
and protocol version. Next, check the authUnixTime field for
acceptable immediacy, and testSessionID for uniqueness. Finally, the
PDU-specific fields that control the test are processed.
If the PDU validation fails in the Control phase, the receiver SHOULD
NOT continue with current exchange and implement silent rejection (no
further packets sent on the address/port pairs). The exception is
when the testing hosts have been configured for trouble-shooting
Control phase failures and rejection messages will aid in the
process.
If the validation succeeds in the Control phase, the receiver SHALL
continue with the current exchange and compose a successful response
or a response indicating the error conditions identified. The
response PDU SHALL be encrypted as described above, and the packet
with encrypted PDU SHALL be sent back to the originator.
Ciavattone & Geib Expires 1 January 2024 [Page 9]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
This process SHALL be executed for each request and response in the
Test Setup exchange (Section 5) and the Test Activation exchange
(Section 6), amounting to four packets exchanged (plus any "dummy"
packets needed).
The Status Feedback Message header PDU SHALL also be encrypted by the
sender, (with authUnixTime populated and the IV plus MBZ remainder in
the authDigest field) and subjected to header field validations at
the receiver after the decryption process.
If the PDU validation fails for a Status PDU, the receiver SHALL
ignore the message. If the watchdog timer expires (due to successive
failed validations, the test session will prematurely terminate (no
further load traffic SHALL be transmitted).
4.2.5. OPTIONAL Fully Encrypted mode
Two users may wish to make private measurements as part of a
bilateral agreement, and they might achieve this goal by encrypting
the traffic of this protocol. However, there is no advantage in a
native-protocol mode to encrypt all traffic when industry solutions
for encrypted tunnels are widespread and users can deploy the tunnel
technology of their choice ([RFC6071] for IPsec and [RFC8446] for
TLS).
Although it was suggested, DTLS [RFC9147] could not be the basis for
a mode with encryption of the all PDUs. The replay protection would
remove duplicated packets and prevent transparent measurement of this
impairment.
The protocol's operation is mostly independent from the tunnel
operation, but reject messages during the Control phase MAY be sent,
the same as when configuring the server for troubleshooting. Also,
the additional encapsulation header size will likely limit the
maximum UDP payload possible in the Full Encryption mode, and users
may need to account for the smaller limit.
Operation of both Control and Data phases inside an encrypted tunnel
would provide a measure of privacy for all protocol operations, but
the cost could be inaccurate measurements (from the additional
processing overhead on Load PDUs at Gigabit rates) and reduced scale
(when considering a server's capacity to host test sessions).
The primary scope of this protocol is Internet access measurement.
This scope greatly limits the geography of the eavesdropping attack
surface, and encourages user-selected encryption solutions when
needed (although this need may be more likely when the protocol is
used beyond its intended scope). IPPM protocols that have been
Ciavattone & Geib Expires 1 January 2024 [Page 10]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
deployed in this scope have not used the encryption option, and at
least one of these protocols [TWAMP] has been deployed at great scale
without using the encrypted mode.
The key pieces of information exposed by the protocol are found in
the feedback status messages which are transferred every 50ms with
default timing. The feedback status messages contain either detailed
measurements of the previous status interval in a downstream test, or
the next sending rate for the sender in an upstream test. If the
feedback status messages are encrypted and de-crypted, then the
processing time may affect the Round-Trip-Time measurements and
affect the protocol operation, especially the load adjustment search
algorithm. Thus, the processing time is a key concern for low cost
CPE (e.g., residential gateways hosting the client function). The
test configuration information exchanged elsewhere is considered
mundane.
The tunnel approach has some advantages. Some users may want to
characterize the encrypted tunnel in comparison to transport in the
clear. It is RECOMMENDED to use the Unauthenticated mode to maximize
server and client performance for the clear transport case, but some
may wish to use the Authenticated mode (1). Users can also leave the
encrypted tunnel up when conducting repeating tests, and reduce test
setup time to the minimum.
4.3. Key Management
Section 2 of [RFC7210] specifies a conceptual database for long-lived
cryptographic keys. The database is implemented as a plaintext
table, to allow text editor maintenance of the key table. The key
table SHALL be used with the REQUIRED authentication mode and the
OPTIONAL authentication mode (using the same key). The same key
table SHALL be used with the OPTIONAL Partial Encryption mode, when
used.
The Key table SHALL have (at least) the following fields, referring
to Section 2 of [RFC7210]:
* AdminKeyName
* LocalKeyName
* AlgID
* Key
* SendLifetimeStart
Ciavattone & Geib Expires 1 January 2024 [Page 11]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
* SendLifetimeEnd
* AcceptLifetimeStart
* AcceptLifetimeEnd
The LocalKeyName SHALL be determined from the corresponding protocol
field in the PDUs that follow, KeyID.
4.4. Firewall Configuration
Normal firewall configuration allows a host to open a bidirectional
connection using unique source and destination addresses and port
numbers by sending a packet using that set of 4-tuple values. The
client's interaction with its firewall depends on this configuration.
The firewall at the server MUST be configured with an open pinhole
for the server IP address and well-known UDP port of the server.
Assuming that the firewall administration at the server does not
allow an open UDP ephemeral port range, then the server MUST send a
dummy packet to the client with the ephemeral port selected by the
server and communicated to the client in the Test Setup Response.
The dummy packet may not reach the client: it may be discarded by the
client's firewall.
If the server firewall administration allows an open UDP ephemeral
port range, then the dummy packet operation is not strictly
necessary. However, the availability of an open port range policy
cannot be assumed.
5. Test Setup Request and Response Exchange
All messages defined in this section SHALL use UDP transport. The
hosts SHALL calculate and include the UDP checksum, or check the UDP
checksum as necessary.
5.1. Client Generates Test Setup Request
The client SHALL begin the Control phase exchanges by sending a Test
Setup Request message to the server's control (well-known) port.
Ciavattone & Geib Expires 1 January 2024 [Page 12]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
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).
Lost messages SHALL NOT be retransmitted. The test initiation timer
uses the watchdog timeout (for a no-traffic warning) and a longer
test termination timeout.
Note: In version 9 and 10, the watchdog timeout is configured as a 1
second interval to trigger a warning message that the received
traffic has stopped. The test termination timeout is based on the
watchdog interval, and implements a wait time of 2 additional seconds
before triggering a non-graceful termination.
The Setup Request message PDU SHALL be organized as follows:
uint16_t controlId; // Control ID = 0xACE1
uint16_t protocolVer; // Protocol version = 10
uint8_t cmdRequest; // Command request (=1 for Request)
uint8_t cmdResponse; // Command response (=0 for Request)
uint16_t maxBandwidth;// Required max. bit rate for the test
uint16_t testPort; // Test port on server (=0 for Request)
uint8_t modifierBitmap;// Modifier bitmap
uint8_t authMode; // Authentication mode (includes encryption)
uint16_t testSessionId; // a pseudo-random number, see below.
uint8_t keyId; // localKeyName, the numeric key identifier
in the shared Key table
uint8_t reserved; // reserved octet
uint32_t authUnixTime;// Authentication time stamp
unsigned char authDigest[AUTH_DIGEST_LENGTH] // 32 oct, also IV
Figure 1 Test Setup PDU with Request fields populated, others
explained below
The UDP PDU format layout SHALL be as follows (big-endian AB):
Ciavattone & Geib Expires 1 January 2024 [Page 13]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| controlId | protocolVer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmdRequest | cmdResponse | maxBandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| testPort |modifierBitmap | authMode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| testSessionId | keyId | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authUnixTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| authDigest[AUTH_DIGEST_LENGTH](256 bits) |
| or |
| Initialization Vector (IV)(up to 256 bits, remaining bits MBZ)|
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Test Setup Message PDU Format
maxBandwith: when this field is non-zero, it is a specification of
the maximum bit rate the client expects to send or receive during the
requested test. The server compares this value to a configured
limit.
modifierBitmap: There are two bits currently assigned in this bitmap:
0x01 Do not use Jumbo Frames above sending rates of 1Gbps
0x02 Use Traditional MTU (1500 bytes with IP-header)
Other bit positions are currently undefined. A new registry will be
needed for modifierBitmap assignments; see the IANA Considerations
Section.
testSessionId: This is a pseudo-random number used with
authentication or encryption. The client SHALL select an identifier
(ID) for the test session which is unlikely to match values used by
other clients or previous sessions of the local client (e.g., the
software's process ID or ephemeral source port number). Note: it is
even more unlikely to have collisions between two clients that
accidentaly choose the same testSessionID if the authUnixTime is also
stored with the testSessionID as a pair.
Ciavattone & Geib Expires 1 January 2024 [Page 14]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
keyId: This is a localKeyName, the numeric key identifier for a key
in the shared Key table.
authMode: The authMode field currently has four values assigned:
0: OPTIONAL unauthenticated mode
1: REQUIRED authentication for Control phase
2: OPTIONAL authentication for Data phase, in the Status Feedback
PDU (added to Mode 1 requirements)
3: OPTIONAL partial encrypted mode
plus, a range of values for experimentation: 60 through 63. A new
registry will be needed for mode values; see the IANA Considerations
Section.
authDigest or Initialization Vector field: In Authenticated mode,
this field contains the authDigest from the SHA-256 function. In
Partial Encrypted mode, this field begins with the Initialization
Vector (IV) bits and the remaining (unused) bits are MBZ.
5.1.1. Authenticated Modes
When operating in either of the authenticated modes (authMode 1 and
authMode 2), the client SHALL follow the requirements of
Section 4.2.2 (and 4.2.3 if applicable), and SHALL generate the
authDigest field. The SHA-256 calculation SHALL cover the 12
preceding fields. The current Unix time SHALL be read and inserted
immediately prior to the calculation (as immediately as possible).
Computation of authDigest SHA-256 is specified in [RFC6234].
5.1.2. Unauthenticated Mode
When operating in Unauthenticated mode (authMode 0), the requirements
of Section 4.2.1 SHALL be followed.
5.1.3. Partial Encrypted Mode
When operating in the partial encryption mode, the client SHALL
follow the requirements of Section 4.2.4 and SHALL encrypt the Test
Setup Request PDU through the authUnixTime field, but no further.
The current Unix time SHALL be read and inserted immediately prior to
the encryption processing (as immediately as possible).
Ciavattone & Geib Expires 1 January 2024 [Page 15]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
5.2. Server Processes Test Setup Request and Generates Response
This Section describes the processes at the server to evaluate the
Test Setup Request and determine the next steps.
5.2.1. Test Setup Request Processing - Rejection
When the server receives the Setup Request, it SHALL:
* process/validate the request message by checking the authDigest if
operating in one of the Authenticated modes as prescribed in
Section 4.2.2, or
* validate and decrypt the request message using the method
prescribed in Section 4.2.4 if operating in the Partial Encryption
mode,
and then proceed to evaluate the other fields in the protocol header,
such as the protocol version, the controlID (to validate the type of
message, Setup), the maximum Bandwidth requested for the test, and
the modifierBitmap for use of options such as Jumbo datagram status
and traditional MTU (1500 bytes). The value in the authUnixTime
field is a 32-bit time stamp and a 5 minute tolerance window (+/- 2.5
minutes) SHALL be used (if in one of the Authenticated modes) to
distinguish a subsequent replay of a Test Setup Request. Replay of
most other fields would remain valid if there was no authUnixTime
field in the PDU, although the testSessionId MUST be unique as well.
The authUnixTime is covered by the authDigest hash, as specified
earlier.
If the client has selected options for:
* Jumbo datagram support status (modifierBitmap),
* Traditional MTU (modifierBitmap),
* Authentication mode (authMode)
that do not match the server configuration, the server MUST reject
the Setup Request.
If the Setup Request must be rejected (due to the reasons in the
Command Response, CRSP, codes listed below), the conditions below
determine whether the server sends a response:
Ciavattone & Geib Expires 1 January 2024 [Page 16]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
* In Authenticated modes, if the authDigest is valid, a Test Setup
Response SHALL be sent back to the client with a corresponding
command response value indicating the reason for the rejection.
The server SHALL follow the requirements of Section 4.2.2 and
insert the autDigest in the response.
* In Authenticated modes, if the authDigest is invalid, then the
Test Setup Request SHOULD fail silently. The exception is for
operations support: server administrators using Authentication are
permitted to send a Setup Response to support operations and
troubleshooting.
* If unauthenticated mode is selected, the Test Setup Request SHALL
fail silently.
* If Partial Encrypted mode is used, only valid Test Setup Request
packets will be decrypted for server processing and a Test Setup
Response is REQUIRED. The server SHALL follow the requirements of
Section 4.2.4 to encrypt the response.
* If Full Encrypted mode is used, only valid Setup request packets
will be forwarded up the stack for server processing and a Test
Setup Response is possible if the server is configured to send
responses for troubleshooting.
The additional, non-authentication and non-encryption-related
circumstances when a server SHALL not communicate the appropriate
Command Response Code for an error condition (fail silently) are
when:
1. the Setup Request PDU size is not correct,
2. the control ID is invalid, or
3. a directed attack has been detected,
in which case the server will allow setup attempts to terminate
silently. Attack detection is beyond the scope of this
specification.
When the server replies to the Test Setup Request message, the PDU
SHALL be organized as follows:
Ciavattone & Geib Expires 1 January 2024 [Page 17]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
uint16_t controlId; // Control ID = 0xACE1
uint16_t protocolVer; // Protocol version = 10
uint8_t cmdRequest; // Command request = 2 (reply)
uint8_t cmdResponse; // Command response = <see table below>
uint16_t maxBandwidth;// Required bandwidth
uint16_t testPort; // Test port on server(available port in Resp)
uint8_t modifierBitmap;// Modifier bitmap (see table below)
uint8_t authMode; // Authentication mode
uint16_t testSessionId; // client-selected pseudo-random number
for the test session
uint8_t keyId; // localKeyName, an index to the
shared Key table
uint8_t reserved; // reserved octet
uint32_t authUnixTime;// Authentication time stamp
unsigned char authDigest[AUTH_DIGEST_LENGTH] //32 octets, also IV
cmdResponse Code Field: Command Server Response Codes (CSRP) (decimal)
CHSR_CRSP_NONE 0 = None (value used by client in Request)
CHSR_CRSP_ACKOK 1 = Acknowledgement
CHSR_CRSP_BADVER 2 = Bad Protocol Version
CHSR_CRSP_BADJS 3 = Invalid Jumbo datagram option
CHSR_CRSP_AUTHNC 4 = Unexpected Authentication in Setup Request
CHSR_CRSP_AUTHREQ 5 = Authentication missing in Setup Request
CHSR_CRSP_AUTHINV 6 = Invalid authentication method
CHSR_CRSP_AUTHFAIL 7 = Authentication failure
CHSR_CRSP_AUTHTIME 8 = Authentication time is invalid in Setup Request
CHSR_CRSP_NOMAXBW 9 = No Maximum test Bit rate specified
CHSR_CRSP_CAPEXC 10 = Server Maximum Bit rate exceeded
CHSR_CRSP_BADTMTU 11 = MTU option does not match Server
maxBandwidth Field MSB Code Bit:
CHSR_USDIR_BIT 0x8000 Bandwidth upstream direction bit, Set for Upstream
modifierBitmap Code Field: Setup
CHSR_JUMBO_STATUS 0x01 = set to use Jumbo datagram sizes above 1Gbps
CHSR_TRADITIONAL_MTU 0x02 = set to use datagrams for 1500 byte packets
Figure 3 Organization/Definitions of Server Test Setup Response -
Rejection
There is a set of Command Response codes, beginning with: "2 = Bad
Protocol Version", one of which SHOULD be communicated to indicate
the cause when an error condition detected and testing cannot
proceed:
Ciavattone & Geib Expires 1 January 2024 [Page 18]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
Decimal values
2 = Bad Protocol Version
3 = Invalid Jumbo datagram option
5 = Authentication missing in Setup Request
4 = Unexpected Authentication in Setup Request
6 = Invalid authentication method (SHA-256 not used)
7 = Authentication failure (both shared secret and time)
8 = Authentication time is invalid in Setup Request (replay attack)
9 = No Maximum test Bit rate specified
10 = Server Maximum Bit rate exceeded
11 = MTU option does not match Server
Figure 4 Command Response Error Codes
When indicating a Bad Protocol Version error and sending a response,
the server SHALL update the protocolVer field in the Test Setup
Response to indicate the current version supported.
5.2.2. Test Setup Request Processing - Acceptance
If the server finds that the Setup Request matches its configuration
and is otherwise acceptable, the server SHALL initiate a new
connection to receive the Test Activation Request and other traffic
from the client, using a new UDP socket allocated from the UDP
ephemeral port range. Then, the server SHALL start a watchdog timer
(to terminate the connection in case the client goes silent), and
sends the Setup Response back to the client (see below for
composition).
When the Setup Request is accepted by the server, a Setup Response
SHALL be sent back to the client with a corresponding command
response value indicating 1 = Acknowledgement.
Ciavattone & Geib Expires 1 January 2024 [Page 19]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
uint16_t controlId; // Control ID = 0xACE1
uint16_t protocolVer; // Protocol version = 10
uint8_t cmdRequest; // Command request = 2 (reply)
uint8_t cmdResponse; // Command response = 1 (ACK)
uint16_t maxBandwidth;// Required bandwidth (added in v9)
uint16_t testPort; // Test port on server
(available port in Response)
uint8_t modifierBitmap;// Modifier bitmap (see table below)
uint8_t authMode; // Authentication mode
uint16_t testSessionId; // client-selected pseudo-random
number for the test session
uint8_t keyId; // localKeyName, an index to the
shared Key table
uint8_t reserved; // reserved octet
uint32_t authUnixTime;// Authentication time stamp
unsigned char authDigest[AUTH_DIGEST_LENGTH] // 32 octets
uint8_t keyId; // localKeyName, a numeric identifier of
a key in the shared Key table
uint8_t reserved; // reserved octet
uint32_t authUnixTime;// Authentication time stamp
unsigned char authDigest[AUTH_DIGEST_LENGTH] //32 octets,also IV
Figure 5 Organization/Definitions of Server Test Setup Response -
Acceptance
The Setup Response SHALL include the server-selected ephemeral port
number (testPort field) for the new socket, and this server-selected
UDP port SHALL be used for all subsequent communication.
The server SHALL confirm, coerce, or populate the values of:
* protocolVersion
* Jumbo datagram support status (modifierBitmap),
* Traditional MTU (modifierBitmap),
* authMode (will be all zeroes if unauthenticated)
* maxBandwidth
* testPort (ephemeral port)
* testSessionId
* keyId
* authUnixTime (will be all zeroes if unauthenticated mode)
Ciavattone & Geib Expires 1 January 2024 [Page 20]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
* authDigest or IV (will be all zeroes if unauthenticated)
for the client's use on the new connection in its Setup Response, and
calculate authDigest in the authenticated modes.
When the server prepares to send the Test Setup Response, it SHALL:
* add the authUnixTime and calculate the authDigest for the response
message using the method prescribed in Section 4.2.2 if operating
in one of the Authenticated modes, or
* add the authUnixTime and encrypt the request message using the
method prescribed in Section 4.2.4 if operating in the Partial
Encryption mode,
and then send the Test Setup Response message to the client.
Finally, the new UDP connection associated with the new socket and
port number is opened, and the server awaits communication there.
To ensure that the server's local firewall will successfully deliver
packets received for the new ephemeral port, the server SHALL
immediately send a "dummy" packet with the corresponding 4-tuple
values including the source and destination IP addresses and port
numbers. The source port SHALL be the new ephemeral port. This
operation allows communication to the server even when the server's
local firewall prohibits open ranges of ephemeral ports. The packet
is not expected to arrive successfully at the client if the client-
side firewall blocks unexpected traffic. If the "dummy" packet
arrives at the client, it is a confirmation that further exchanges
are possible on the new port-pair (but this is not strictly
necessary).
The four Test Setup PDU fields shown below SHALL be used as the
"dummy" packet PDU.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| controlId | protocolVer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmdRequest | cmdResponse | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 The "dummy" Packet PDU Format
Ciavattone & Geib Expires 1 January 2024 [Page 21]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
If a Test Activation Request is not subsequently received from the
client on this new ephemeral port number before the watchdog timer
expires, the server SHALL close the socket and deallocate the port.
5.3. Setup Response Processing at the Client
When the client receives the Test Setup Response, it SHALL:
* process/validate the response message by checking the authDigest
if operating in one of the Authenticated modes as prescribed in
Section 4.2.2, or
* validate and decrypt the response message using the method
prescribed in Section 4.2.4 if operating in the Partial Encryption
mode,
and then proceed to evaluate the other fields in the protocol,
beginning with the protocol version, the controlID (to validate the
type of message, Test Setup), cmdRequest for the role of the message
(SHOULD be 2, Test Setup Response), the maxBandwidth requested for
the test (if in use), and the modifierBitmap for use of options such
as Jumbo datagram status and traditional MTU (1500 bytes). The value
in the authUnixTime field is a 32-bit time stamp and a 5 minute
tolerance window (+/- 2.5 minutes) SHALL be used (if in one of the
Authenticated or Encrypted modes) to distinguish a subsequent replay
of a Test Setup Response. Replay of most other fields would remain
valid if there was no authUnixTime field in the PDU, although the
testSessionId MUST be unique as well. The authUnixTime is covered by
the authDigest hash or encrypted, as specified earlier.
The authUnixTime field is expected to be MBZ in unauthenticated mode.
IF the cmdResponse value indicates an error (values >1) the client
SHALL display/report a relevant message to the user or management
process and exit. If the client receives a Command Server Response
code (CRSP) that is not equal to one of the codes defined above, then
the client MUST terminate the connection and terminate operation of
the current Setup Request. If the Command Server Response code
(CRSP) value indicates success (cmdResponse=1) the client SHALL
compose a Test Activation Request with all the test parameters it
desires, such as the test direction, the test duration, etc., as
described below.
6. Test Activation Request and Response
This section is divided according to the sending and processing of
the client, server, and again at the client.
Ciavattone & Geib Expires 1 January 2024 [Page 22]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
All messages defined in this section SHALL use UDP transport. The
hosts SHALL calculate and include the UDP checksum, or check the UDP
checksum as necessary.
6.1. Client Generates Test Activation Request
Upon a successful setup exchange, the client SHALL then compose and
send the Test Activation Request to the UDP port number the server
communicated in the Test Setup Response (the new ephemeral port, and
not the well-known port).
The client SHALL compose Test Activation Request as follows:
uint16_t controlId; // Control ID = 0xACE2
uint16_t protocolVer; // Protocol version = 10
uint8_t cmdRequest; // Command request, 1 = upstream,
2 = downstream
uint8_t cmdResponse; // Command response(set to 0 by client)
uint16_t lowThresh; // Low delay variation threshold
uint16_t upperThresh; // Upper delay variation threshold
uint16_t trialInt; // Status feedback/trial interval (ms)
uint16_t testIntTime; // Test interval time (sec) (duration, T)
uint8_t subIntPeriod; // Sub-interval period (sec)
uint8_t ipTosByte; // IP ToS byte for testing
uint16_t srIndexConf; // Configured sending rate index
(see Note below)
uint8_t useOwDelVar; // Use one-way delay instead of RTT
uint8_t highSpeedDelta; // High-speed row adjustment delta
uint16_t slowAdjThresh; // Slow rate adjustment threshold
uint16_t seqErrThresh; // Sequence error threshold
uint8_t ignoreOooDup; // Ignore Out-of-Order/Duplicate
datagrams
uint8_t modifierBitmap; // Modifier bitmap
uint8_t rateAdjAlgo; // Rate adjustment algo.
uint8_t reserved1; // reserved octet (alignment)
MBZ 28 Octets
uint16_t testSessionId; // a pseudo-random number, see below.
uint8_t keyId; // localKeyName, a numeric identifier of
a key in the shared Key table
uint8_t reserved2; // reserved octet (alignment)
uint32_t authUnixTime; // Authentication time stamp
unsigned char authDigest[AUTH_DIGEST_LENGTH] // 32 oct, also IV
Control Header Test Activation Command Request Values:
CHTA_CREQ_NONE 0 = No Request
CHTA_CREQ_TESTACTUS 1 = Request test in Upstream direction (client to
server, client in the role of sending test packets)
Ciavattone & Geib Expires 1 January 2024 [Page 23]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
CHTA_CREQ_TESTACTDS 2 = Request test in Downstream direction (server to
client, client's role is receiving test packets)
modifierBitmap Code Field: Test Activation
CHTA_SRIDX_ISSTART 0x01 = Set when srIndexConf IS START rate for search
CHTA_RAND_PAYLOAD 0x02 = Set for RANDOMIZED UDP payload
rateAdjAlgo Values:
CHTA_RA_ALGO_B = 0 // 0 = Algo. B, allows Algo. expansion
CHTA_RA_ALGO_MIN = CHTA_RA_ALGO_B // Limit check (with Algo B)
CHTA_RA_ALGO_MAX = CHTA_RA_ALGO_C// Limit check (with Algo C)
Control Header Test Activation Command Response Values:
CHTA_CRSP_NONE 0 = Used by client when making a Request
CHTA_CRSP_ACKOK 1 = Used by Server in affirmative Response
CHTA_CRSP_BADPARAM 2 = Used by Server to indicate an error;
bad parameter; reject;
Figure 7 Organization/Definitions of Client Test Activation Request
The content of many of the unique fields in Figure 7 is defined
above, or defined in Section 4 of [RFC9097] and Appendix A of
[RFC9097]. Additional definitions are given below.
srIndexConf srIndexConf is the Send Rate table index of the
configured fixed or starting send rate (depending on whether
CHTA_SRIDX_ISSTART is cleared or set respectively).
The UDP PDU format of the Test Activation Request is as follows (big-
endian AB):
Ciavattone & Geib Expires 1 January 2024 [Page 24]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| controlId | protocolVer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmdRequest | cmdResponse | lowThresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| upperThresh | trialInt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| testIntTime | subIntPeriod | ipTosByte |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| srIndexConf | useOwDelVar |highSpeedDelta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| slowAdjThresh | seqErrThresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ignoreOooDup |modifierBitmap | rateAdjAlgo | reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. MBZ (28 octets) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| testSessionId | keyId | reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authUnixTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| authDigest[AUTH_DIGEST_LENGTH](256 bits) |
| or |
| Initialization Vector (IV)(up to 256 bits, remaining bits MBZ)|
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The 28 MBZ octets are replaced by the Send Rate Structure
in a Test Activation Response for an upstream test.
Figure 8 Test Activation Request PDU Format
The client SHALL apply the configuration for
* testPort
* modifierBitmap
* authMode
* testSessionID
Ciavattone & Geib Expires 1 January 2024 [Page 25]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
* keyID
* and the remaining fields are populated based on default values or
command-line options
requested in the Test Setup Request and communicated/confirmed by the
server in the Test Setup Response.
6.1.1. Authenticated Modes
When operating in either of the authenticated modes (authMode 1 and
authMode 2), the client SHALL follow the requirements of
Section 4.2.2 (and 4.2.3 if applicable), and SHALL generate the
authDigest field. The SHA-256 calculation SHALL cover all the
preceding fields. The current Unix time SHALL be read and inserted
immediately prior to the calculation (as immediately as possible).
Computation of authDigest SHA-256 is specified in [RFC6234].
6.1.2. Unauthenticated Mode
When operating in Unauthenticated mode (authMode 0), the requirements
of Section 4.2.1 SHALL be followed.
6.1.3. Partial Encrypted Mode
When operating in the partial encryption mode, the client SHALL
follow the requirements of Section 4.2.4 and SHALL encrypt the Test
Activation Request PDU through the authUnixTime field, but no
further.
The current Unix time SHALL be read and inserted immediately prior to
the encryption processing (as immediately as possible).
6.2. Server Processes Test Activation Request and Generates Response
After the server receives the Test Activation Request on the new
connection, it MUST choose to accept, ignore or modify any of the
test parameters.
6.2.1. Server Rejects or Modifies Request
When evaluating the Test Activation Request, the server MAY allow the
client to specify its own fixed or starting send rate.
Alternatively, the server MAY enforce a maximum limit of the fixed or
starting send rate which the client can successfully request. If the
client's Test Activation Request exceeds the server's configured
maximum, the server MUST either reject the request or coerce the
Ciavattone & Geib Expires 1 January 2024 [Page 26]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
value to the configured maximum bit rate, and communicate that
maximum to the client in the Test Activation Response. The client
can of course choose to end the test, as appropriate.
Other parameters where the server has the OPTION to coerce the client
to use values other than those in the Test Activation Request are
(grouped by role):
* Load Adjustment Algo: lowThresh, upperThresh, useOwDelayVar,
highSpeedDelta, slowAdjThresh, seqErrThresh, highSpeedDelta,
ignoreOooDup, rateAdjAlgo.
* Test duration/intervals: trialInt, testIntTime, subIntPeriod
* Packet marking: ipTosByte
Coersion is a step toward performing a test with the server-
configured values; even though the client might prefer certain values
the server gives the client an opportunity to run a test with
different values than the preferred set.
Note that the server has the option of completely rejecting the
request and sending back an appropriate command response value:
uint8_t cmdResponse; // Command response (set to 2, error)
Whether this error response is sent or not depends on the Security
mode of operation and the outcome of authDigest validation.
If the Test Activation Request must be rejected (due to the reasons
in the Command Response value=2 listed above), and
* In Authenticated modes, if the authDigest is valid, a Test
Activation Response SHALL be sent back to the client with a
corresponding command response value indicating the reason for the
rejection. The server SHALL follow the requirements of
Section 4.2.2 and insert the autDigest in the response.
* In Authenticated modes, if the authDigest is invalid, then the
Test Activation Request SHOULD fail silently. The exception is
for operations support: server administrators using Authentication
are permitted to send a Setup Response to support operations and
troubleshooting.
* If unauthenticated mode is selected, the Test Setup Request SHALL
fail silently.
Ciavattone & Geib Expires 1 January 2024 [Page 27]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
* If Partial Encrypted mode is used, only valid Test Activation
Request packets will be decrypted for server processing and a Test
Activation Response is REQUIRED. The server SHALL follow the
requirements of Section 4.2.4 to encrypt the response.
* If Full Encrypted mode is used, only valid Test Activation Request
packets will be forwarded up the stack for server processing and a
Test Setup Response is possible if the server is configured to
send responses for troubleshooting.
The additional, non-authentication and non-encryption-related
circumstances when a server SHALL not communicate the appropriate
Command Response Code for an error condition (fail silently) are
when:
1. the Test Activation Request PDU size is not correct,
2. the control ID is invalid, or
3. a directed attack has been detected,
in which case the server will allow Test Activation Requests to
terminate silently. Attack detection is beyond the scope of this
specification.
6.2.2. Server Accepts Request and Generates Response
When the server sends the Test Activation Response, it SHALL set the
cmd Response field to:
uint8_t cmdResponse;// Command response (set to 1, ACK)
The server SHALL generate the Test Activation Response, populating
all parameters in the Test Activation Response to indicate each value
acceptance/changes/coersion to the client.
If the client has requested an upstream test, the server SHALL:
* include the transmission parameters from the first row of the
sending rate table in the Sending Rate Structure (defined below),
OR
* use the parameters from the configured send rate index
(srIndexConf) of the sending rate table for a fixed rate test, or
the starting rate index for a test with Load Adjustment (this
option indicated in the Test Activation modifierBitmap) when these
options are present.
Ciavattone & Geib Expires 1 January 2024 [Page 28]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
When generating the Test Activation Response (acceptance) for an
upstream test, the server SHALL replace the 28 MBZ octets of the of
the Test Activation Request with the Sending Rate Structure, which
SHALL be organized as follows:
uint32_t txInterval1; // Transmit interval (us)
uint32_t udpPayload1; // UDP payload (bytes)
uint32_t burstSize1; // UDP burst size per interval
uint32_t txInterval2; // Transmit interval (us)
uint32_t udpPayload2; // UDP payload (bytes)
uint32_t burstSize2; // UDP burst size per interval
uint32_t udpAddon2; // UDP add-on (bytes)
Figure 9 Sending Rate Structure Definitions
with
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| txInterval1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| udpPayload1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burstSize1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| txInterval2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| udpPayload2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burstSize2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| udpAdddon2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10 Sending Rate Structure Format
If activation continues, server prepares the new connection for an
upstream OR downstream test.
In the case of a downstream test, the server SHALL prepare to send
with either a single timer to send status PDUs at the specified
interval OR dual timers to send load PDUs based on
* the transmission parameters from the first row of the sending rate
table in the Sending Rate Structure, OR
Ciavattone & Geib Expires 1 January 2024 [Page 29]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
* the transmission parameters of the configured send rate index
(srIndexConf) of the sending rate table, or starting rate index
(indicated in the Test Activation modifierBitmap) when these
options are present.
The server SHALL then send the Test Activation Response back to the
client, update the watchdog timer with a new time-out value, and set
a test duration timer to eventually stop the test. Once the
requirements of the chosen security mode have been met, the Test
Activation Response is ready to be sent to the client:
6.2.2.1. Authenticated Modes
When operating in either of the authenticated modes (authMode 1 and
authMode 2), the server SHALL follow the requirements of
Section 4.2.2 (and 4.2.3 if applicable), and SHALL generate the
authDigest field. The SHA-256 calculation SHALL cover all the
preceding fields. The current Unix time SHALL be read and inserted
immediately prior to the calculation (as immediately as possible).
Computation of authDigest SHA-256 is specified in [RFC6234].
6.2.2.2. Unauthenticated Mode
When operating in Unauthenticated mode (authMode 0), the requirements
of Section 4.2.1 SHALL be followed.
6.2.2.3. Partial Encrypted Mode
When operating in the partial encryption mode, the client SHALL
follow the requirements of Section 4.2.4 and SHALL encrypt the Test
Activation Response PDU through the authUnixTime field, but no
further.
The current Unix time SHALL be read and inserted immediately prior to
the encryption processing (as immediately as possible).
6.3. Client Processes Test Activation Response
When the client receives the Test Activation Response, it SHALL:
* process/validate the response message by checking the authDigest
if operating in one of the Authenticated modes as prescribed in
Section 4.2.2, or
* validate and decrypt the response message using the method
prescribed in Section 4.2.4 if operating in the Partial Encryption
mode,
Ciavattone & Geib Expires 1 January 2024 [Page 30]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
and then proceed to evaluate the other fields in the protocol.
When the client receives the (vetted) Test Activation Response, it
first checks the command response value.
If the client receives a Test Activation Command Response value that
indicates an error, the client SHALL display/report a relevant
message to the user or management process and exit.
If the client receives a Test Activation Command Response value that
is not equal to one of the codes defined above, then the client MUST
terminate the connection and terminate operation of the current Setup
Request.
If the client receives a Test Activation Command Response value that
indicates success (CHTA_CRSP_ACKOK) the client SHALL update its
configuration to use any test parameters modified by the server.
Next, the client SHALL prepare its connection for either an upstream
test with dual timers set to send load PDUs (based on the starting
transmission parameters sent by the server), OR a downstream test
with a single timer to send status PDUs at the specified interval.
Then, the client SHALL stop the test initiation timer, set a new
time-out value for the watchdog timer and start the timer (to detect
if the server goes quiet).
The connection is now ready for testing.
7. Test Stream Transmission and Measurement Feedback Messages
This section describes the Data phase of the protocol. The roles of
sender and receiver vary depending whether the direction of testing
is from server to client, or the reverse.
All messages defined in this section SHALL use UDP transport. The
hosts SHALL calculate and include the UDP checksum, or check the
received UDP checksum before further processing, as necessary.
7.1. Test Packet PDU and Roles
Testing proceeds with one end point sending load PDUs, based on
transmission parameters from the sending rate table, and the other
end point receiving the load PDUs and sending status messages to
communicate the traffic measurements at the receiver (or to control
the receiver).
Ciavattone & Geib Expires 1 January 2024 [Page 31]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
The watchdog timer at the receiver SHALL be reset each time a test
PDU is received. See non-graceful test stop in Section 8 for
handling the watchdog/NOTRAFFIC time-out expiration at each end-
point.
When the server is sending Load PDUs in the role of sender, it SHALL
use the transmission parameters directly from the sending rate table
via the index that is currently selected (which was based on the
feedback in its received status messages).
However, when the client is sending load PDUs in the role of sender,
it SHALL use the discreet transmission parameters that were
communicated by the server in its periodic status messages (and not
referencing a sending rate table row). This approach allows the
server to control the individual sending rates as well as the
algorithm used to decide when and how to adjust the rate.
The server uses a load adjustment algorithm which evaluates
measurements, either its local measurements or the contents of
received feedback messages. This approach is unique to this
protocol; it provides the ability to search for the Maximum IP
Capacity and specify specific sender behaviors that is absent from
other testing tools. Although the algorithm depends on the protocol,
it is not part of the protocol per se.
The default algorithm (B) has three paths to its decision on the next
sending rate:
1. When there are no impairments present (no sequence errors, low
delay variation), resulting in sending rate increase.
2. When there are low impairments present (no sequence errors but
higher levels of delay variation), so the same sending rate is
retained.
3. When the impairment levels are above the thresholds set for this
purpose and "congestion" is inferred, resulting in sending rate
decrease.
Algorithm (B) also has two modes for increasing/decreasing the
sending rate:
Ciavattone & Geib Expires 1 January 2024 [Page 32]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
* A high-speed mode (fast) to achieve high sending rates quickly,
but also back-off quickly when "congestion" is inferred from the
measurements. Consecutive feedback intervals that have a supra-
threshold count of sequence number anomalies and/or contain an
upper delay variation threshold exception in all of the
consecutive intervals are sufficient to declare "congestion"
within a test. The threshold of consecutive feedback intervals
SHALL be configurable with a default of 3 intervals.
* A single-step (slow) mode where all rate adjustments use the
minimum increase or decrease of one step in the sending rate
table. The single step mode continues after the first inference
of "congestion" from measured impairments.
An OPTIONAL load adjustment algorithm (designated C) has been defined
in [TR-471]. Algorithm C operation and modes are similar to B, but C
uses multiplicative increases in the fast mode to reach the 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).
On the other hand, the test configuration MAY use a fixed sending
rate requested by the client, using the field below:
uint16_t srIndexConf; // Configured sending rate index
The client MAY communicate the desired fixed rate in its activation
request. The reasons to conduct a fixed-rate test include stable
measurement at the maximum determined by the load adjustment (search)
algorithm, or the desire to test at a known subscribed rate without
searching.
The Load PDU SHALL have the following format and field definitions:
Ciavattone & Geib Expires 1 January 2024 [Page 33]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
uint16_t loadId; // Load ID (=0xBEEF for the Load PDU)
uint8_t testAction; // Test action (= 0x00 normally,
until test stop)
uint8_t rxStopped; // Receive traffic stopped indicator (BOOL)
uint32_t lpduSeqNo; // Load PDU sequence number (starts at 1)
uint16_t udpPayload; // UDP payload LENGTH (bytes)
uint16_t spduSeqErr; // Status PDU sequence error count
//
uint32_t spduTime_sec; // Send time in last received status PDU
uint32_t spduTime_nsec; // Send time in last received status PDU
uint32_t lpduTime_sec; // Send time of this load PDU
uint32_t lpduTime_nsec; // Send time of this load PDU
Test Action Codes
TEST_ACT_TEST 0 // normal
TEST_ACT_STOP1 1 // normal stop at end of test: server sends in STATUS or Test PDU
TEST_ACT_STOP2 2 // ACK of STOP1: sent by client in STATUS or Test PDU
The Test Load UDP PDU format is as follows (big-endian AB):
Figure 11 Load PDU Field Definitions
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| loadId | testAction | rxStopped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lpduSeqNo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| udpPayload | spduSeqErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spduTime_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spduTime_nsec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lpduTime_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lpduTime_nsec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. udpPayloadContent = udpPayload minus 28 octets .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
Figure 12 Load PDU Format
The field udpPayloadContent is all zeroes, all ones, or a pseudo
random binary sequence.
Ciavattone & Geib Expires 1 January 2024 [Page 34]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
7.2. Status PDU
The receiver SHALL send a Status PDU to the sender during a test at
the configured feedback interval.
The watchdog timer at the test PDU sender SHALL be reset each time a
Status PDU is received. See non-graceful test stop in Section 8 for
handling the watchdog/NOTRAFFIC time-out expiration at each end-
point.
The Status PDUs are a key part of the server-client control loop. To
protect against bit errors (checksum) or on-path attacks (something
stronger), there is a requirement to calculate and include/check the
UDP checksum. Also, AUTHENTICATED mode 2 that covers the Status PDU
and will detect bit errors or attempts to replace values in the
original packets.
The Status PDU SHALL have the following format and field definitions:
Ciavattone & Geib Expires 1 January 2024 [Page 35]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
uint16_t statusId; // Status ID = 0xFEED
uint8_t testAction; // Test action
uint8_t rxStopped; // Receive traffic stopped indicator (BOOL)
uint32_t spduSeqNo; // Status PDU sequence number (starts at 1)
//
struct sendingRate srStruct; // Sending Rate Structure (28 octets)
//
uint32_t subIntSeqNo; // Sub-interval sequence number
struct subIntStats sisSav; // Sub-interval Saved Stats Structure
(52 octets)
//
uint32_t seqErrLoss; // Loss sum
uint32_t seqErrOoo; // Out-of-Order sum
uint32_t seqErrDup; // Duplicate sum
//
uint32_t clockDeltaMin; // Clock delta minimum (either RTT
or 1-way delay)
uint32_t delayVarMin; // Delay variation minimum
uint32_t delayVarMax; // Delay variation maximum
uint32_t delayVarSum; // Delay variation sum
uint32_t delayVarCnt; // Delay variation count
uint32_t rttMinimum; // Minimum round-trip time sampled
uint32_t rttSample; // Last round-trip time sample
uint8_t delayMinUpd; // Delay minimum(s) updated observed,
communicated in both directions.
uint8_t reserved2; // (alignment)
uint16_t reserved3; // (alignment)
//
uint32_t tiDeltaTime; // Trial interval time duration, usec
uint32_t tiRxDatagrams; // Trial interval receive datagram count
uint32_t tiRxBytes; // Trial interval receive byte count
//
uint32_t spduTime_sec; // Send time of this status PDU, sec
uint32_t spduTime_nsec; // Send time of this status PDU, nanosec
Figure 13 Status PDU Field Definitions
The Status (UDP payload) PDUs format is as follows (big-endian AB):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| statusId | testAction | rxStopped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spduSeqNo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Sending Rate Structure (28 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ciavattone & Geib Expires 1 January 2024 [Page 36]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
| subIntSeqNo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Sub-interval Saved Stats Structure (52 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqErrLoss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqErrOoo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqErrDup |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| clockDeltaMin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarMin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarMax |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarCnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rttMinimum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rttSample |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayMinUpd | reserved2 | reserved3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tiDeltaTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tiRxDatagrams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tiRxBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spduTime_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spduTime_nsec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Authentication Fields (40 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14 Status PDU Format
Note that the Sending Rate Structure (28 octets) is defined in the
Test Activation section.
More details on the Status PDU measurement fields are provided in
[RFC9097].
Ciavattone & Geib Expires 1 January 2024 [Page 37]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
Also note that the Sub-interval Saved Stats Structure (52 octets)
SHALL be included (and populated as required when the server is in
the receiver role in an upstream test) as defined below.
The Sub-interval saved statistics structure for received traffic
measurements SHALL be organized and formatted as follows:
Ciavattone & Geib Expires 1 January 2024 [Page 38]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
uint32_t rxDatagrams; // Received datagrams
uint32_t rxBytes; // Received bytes
uint32_t deltaTime; // Time delta
uint32_t seqErrLoss; // Loss sum
uint32_t seqErrOoo; // Out-of-Order sum
uint32_t seqErrDup; // Duplicate sum
uint32_t delayVarMin; // Delay variation minimum
uint32_t delayVarMax; // Delay variation maximum
uint32_t delayVarSum; // Delay variation sum
uint32_t delayVarCnt; // Delay variation count
uint32_t rttMinimum; // Minimum round-trip time
uint32_t rttMaximum; // Maximum round-trip time
uint32_t accumTime; // Accumulated time
----------------------------------------------------------------------------
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rxDatagrams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rxBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| deltaTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqErrLoss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqErrOoo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqErrDup |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarMin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarMax |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarCnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rttMinimum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rttMaximum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| accumTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15 Saved Interval Statistics Structure, Definitions and Format
Ciavattone & Geib Expires 1 January 2024 [Page 39]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
Note that the 52 octet saved statistics structure above has slight
differences from the 40 octets that follow in the status feedback
PDU, particularly the time-related fields.
The Authentication (and Encryption) Fields appear at the end of the
Status PDU and SHALL be organized as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| testSessionId | keyId | reserved4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authUnixTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| authDigest[AUTH_DIGEST_LENGTH](256 bits) |
| or |
| Initialization Vector (IV)(up to 256 bits, remaining bits MBZ)|
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16 Organization of Authentication Field Format
The Authentication (and Encryption) Fields and their operation are as
defined previously in Sections 5 and 6.
When a client or server prepares to send the Status PDU, it SHALL:
* add the authUnixTime and calculate the authDigest for the response
message using the method prescribed in Section 4.2.2 if operating
in one of the Authenticated modes, or
* add the authUnixTime and encrypt the request message using the
method prescribed in Section 4.2.4 if operating in the Partial
Encryption mode,
and then sends the Status PDU message to the other end-point.
Upon receiving a Status Feedback PDU which has been validated and
vetted according to the mode of operation (Authenticated mode 2 or
Partial Encryption mode 3), the server SHALL
* perform calculations required by the selected Load adjustment
algorithm (see Appendix A of [RFC9097] or Annex B of [TR-471]) and
adjust its sending rate, or
Ciavattone & Geib Expires 1 January 2024 [Page 40]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
* signal that the client adjust its sending rate in its role as as
sender (via the Status PDU Sending Rate Structure).
8. Stopping the Test
When the test duration timer on the server expires, it SHALL set the
connection test action to STOP and mark all outgoing load or status
PDUs with a test action of STOP1.
uint8_t testAction; // Test action (server sets STOP1)
This is simply a non-reversible state for all future messages sent
from the server.
When the client receives a load or status PDU with the STOP1
indication, it SHALL finalize testing, display the test results, and
also mark its connection with a test action of STOP (so that any PDUs
received subsequent to the STOP1 are ignored).
With the test action of the client's connection set to STOP, the very
next expiry of a send timer for either a load or status PDU SHALL
cause the client to schedule an immediate end time to exit.
The client SHALL then send all subsequent load or status PDUs with a
test action of STOP2.
uint8_t testAction; // Test action (client sets STOP2)
as confirmation to the server, and a graceful termination of the test
can begin.
When the server receives the STOP2 confirmation in the load or status
PDU, the server SHALL schedule an immediate end time for the
connection which closes the socket and deallocates it.
In a non-graceful test stop due to path failure, the watchdog/
NOTRAFFIC time-outs at each end-point will expire (sometimes at one
end-point first), notifications in logs, STDOUT, and/or formatted
output SHALL be made, and the test action of each end-point's
connection SHALL be set to STOP.
If an attacker clears STOP1 or STOP2 bits, then the configured
testIntTime (test duration) value at the server and/or client will
take action and stop sending its test stream.
Ciavattone & Geib Expires 1 January 2024 [Page 41]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
9. Method of Measurement
The architecture of the method REQUIRES two cooperating hosts
operating in the roles of Src (test packet sender) and Dst
(receiver), with a measured path and return path between them.
The duration of a test duration, parameter I, MUST be constrained in
a production network, since this is an active test method and it will
likely cause congestion on the Src to Dst host path during a test.
9.1. Notes on Interface Measurements
Additional measurements may be useful in specific circumstances. For
example, interface byte counters measured by a client at a
residential gateway are possible when the client application has
access to an interface that sees all traffic to/from a service
subscriber's location. Adding a byte counter at the client for
download or upload directions could be used to measure total traffic
and possibly detect when non-test traffic is present (and using
capacity). The client may not have the CPU cycles available to count
both the interface traffic and IP-layer Capacity simultaneously, so
this form of diagnostic measurement may not be possible.
9.2. Running Code
This section is for the benefit of the Document Shepherd's form, and
will be deleted prior to publication.
Much of the development of the method and comparisons with existing
methods conducted at IETF Hackathons and elsewhere have been based on
the example udpst Linux measurement tool (which is a working
reference for further development) [udpst]. The current project:
* is a utility that can function as a client or server daemon
* requires a successful client-initiated setup handshake between
cooperating hosts and allows firewalls to control inbound
unsolicited UDP which either go to a control port [expected and w/
authentication] or to ephemeral ports on the client and server
that are only created as needed.
Ciavattone & Geib Expires 1 January 2024 [Page 42]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
* permits firewalls protecting each host to continue to do their job
normally. This aspect is similar to many other test utilities
available. The firewall at the server will need to open a pin-
hole for the control port, the dynamic ephemeral port in response
to the "dummy packet" (or open a limited range of ephemeral ports)
to complete the second control exchange: Test Activation, where
the client communicates to the server on an ephemeral destination
port *assigned by the server*.
* has Authentication modes that require a secret key included in the
SHA-256 HMAC calculation which utilizes the OpenSSL HMAC macro
(https://www.openssl.org/docs/man3.0/man3/HMAC.html).
* is written in C, and built with gcc (release 9.3) and its standard
run-time libraries
* allows configuration of most of the parameters described in
Sections 4 through 8.
* supports IPv4 and IPv6 address families.
* supports IP-layer packet marking.
* supports the upstream and downstream interface byte counter
measurements at the client, and the results are available in the
Text and JSON output at the end of a test.
10. Security Considerations
Active metrics and measurements have a long history of security
considerations. The security considerations that apply to any active
measurement of live paths are relevant here. See [RFC4656] and
[RFC5357].
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. Passive observations of user
traffic for measurement purposes raise many privacy issues. We refer
the reader to the privacy considerations described in the Large Scale
Measurement of Broadband Performance (LMAP) Framework [RFC7594],
which covers active and passive techniques.
There are some new considerations for Capacity measurement as
described in this memo.
Ciavattone & Geib Expires 1 January 2024 [Page 43]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
1. Cooperating client and server hosts and agreements to test the
path between the hosts are REQUIRED. Hosts perform in either the
server or client roles. One way to assure a cooperative
agreement employs the optional Authorization mode through the use
of the authDigest field and the known identity associated with
the key used to create the authDigest field. Other means are
also possible, such as access control lists at the server.
2. It is REQUIRED to have a user client-initiated setup handshake
between cooperating hosts that allows firewalls to control
inbound unsolicited UDP traffic which either goes to a control
port [expected and w/authentication] or to ephemeral ports that
are only created as needed. Firewalls protecting each host can
both continue to do their job normally.
3. Client-server authentication and integrity protection for
feedback messages conveying measurements is REQUIRED. To
accommodate different host limitations and testing circumstances,
different modes of operation are recommended, as described in
Section 4 above.
4. Hosts MUST limit the number of simultaneous tests to avoid
resource exhaustion and inaccurate results.
5. Senders MUST be rate-limited. This can be accomplished using a
pre-built table defining all the offered load rates that will be
supported (Section 8.1). The default and optional load-control
search algorithm result in "ramp up" from the lowest rate in the
table.
6. Service subscribers with limited data volumes who conduct
extensive capacity testing might experience the effects of
Service Provider controls on their service. Testing with the
Service Provider's measurement hosts SHOULD be limited in
frequency and/or overall volume of test traffic (for example, the
range of test interval duration values SHOULD be limited).
One specific attack that has been recognized is an on-path attack on
the Test STOP bits where the attacker would clear or set the bits.
Adding the STOP bits to successive packets terminates the test
prematurely, with no threat to the Internet but annoyance for the
testers. If an attacker clears the STOP bits, the mitigation relies
on knowledge of the test duration at the client and server, where
these hosts cease all traffic when the specified test duration is
complete.
Ciavattone & Geib Expires 1 January 2024 [Page 44]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
11. IANA Considerations
This memo requests IANA to assign a "well-known" UDP port for the
Test Setup exchange in the Control phase of protocol operation, and
to create a new registry group for the UDP Speed Test (UDPST)
protocol.
11.1. New System Port Assignment
Service: udpst-control
Transport Protocol: UDP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: UDP-based IP-Layer Capacity and performance measurement
protocol
Reference: This RFC, RFCYYYY. The protocol uses IP-Layer Unicast.
Port Number: <left blank, as instructed>
11.2. New UDPST Registry Group
This section describes the design of the UDP Speed Test (UDPST)
registry group.
The new registry group SHALL be named, "UDPST Registry".
The following applies to each registry in the sub-sections below:
Registration Procedure: Specification Required
Reference: <This RFC>
Experts: Performance Metrics Experts
Note: TBD
11.2.1. PDU Identifier Registry
The first two octets of the PDUs used in the UDPST protocol identify
the role and format of PDU that follows.
Ciavattone & Geib Expires 1 January 2024 [Page 45]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
Identifier Value Reference Change Description
Name Controller
===================================================================
controlId 0xACE1 <this RFC> IETF Test Setup PDU
controlId 0xACE2 <this RFC> IETF Test Activation PDU
loadId 0xBEEF <this RFC> IETF Load PDU
statusId 0xFEED <this RFC> IETF Status Feedback PDU
Other values are unassigned.
11.2.2. Protocol Number Registry
The second two octets of the PDUs used in the UDPST protocol identify
the version of the protocol in use. The table below defines the
assigned decimal values in the registry.
Field Value Reference Change Description
Name Controller
===================================================================
protocolVer 0-7 <this RFC> IETF Reserved
protocolVer 8 <this RFC> IETF Protocol version 8
protocolVer 9 <this RFC> IETF Protocol version 9
protocolVer 10 <this RFC> IETF Protocol version 10
Other values are unassigned, with an upper value of 65535.
11.2.3. Test Setup PDU Modifier Bitmap Registry
The Test Setup PDU layout contains a modifierBitmap field. The table
below defines the initial bit assignments in the registry.
Ciavattone & Geib Expires 1 January 2024 [Page 46]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
Field Value Reference Change Description
Name Controller
===================================================================
modifierBitmap 0x00 <this RFC> IETF No modifications
modifierBitmap 0x01 <this RFC> IETF Do not use Jumbo
Frames above sending
rates of 1Gbps
modifierBitmap 0x02 <this RFC> IETF Use Traditional MTU
(1500 bytes with
IP-header)
modifierBitmap 0x03-0xFF IETF Unassigned
11.2.4. Test Setup PDU Authentication Mode Registry
The Test Setup PDU layout contains an authMode field. The table
below defines the assigned decimal values in the registry, and a
range for experimentation.
Field Value Reference Change Description
Name Controller
=====================================================================
authMode 0 <this RFC> IETF OPTIONAL unauthenticated mode
authMode 1 <this RFC> IETF REQUIRED authentication
for the Control phase
authMode 2 <this RFC> IETF OPTIONAL authentication
for the Data phase, in
addition to the Control phase
authMode 3 <this RFC> IETF OPTIONAL partial encrypted
mode
authMode 60-63 <this RFC> IETF Range for experimentation
Other values are unassigned, with the upper boundary of 255.
11.2.5. Test Setup PDU Command Response Field Registry
The Test Setup PDU layout contains an cmdResponse field. The table
below defines the assigned decimal values in the registry.
Ciavattone & Geib Expires 1 January 2024 [Page 47]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
Field Value Reference Change Description
Name Controller
===================================================================
cmdResponse 0 <this RFC> IETF None (value used by client in Request)
cmdResponse 1 <this RFC> IETF Acknowledgement
cmdResponse 2 <this RFC> IETF Bad Protocol Version
cmdResponse 3 <this RFC> IETF Invalid Jumbo datagram option
cmdResponse 4 <this RFC> IETF Unexpected Authentication in Setup Request
cmdResponse 5 <this RFC> IETF Authentication missing in Setup Request
cmdResponse 6 <this RFC> IETF Invalid authentication method
cmdResponse 7 <this RFC> IETF Authentication failure
cmdResponse 8 <this RFC> IETF Authentication time is invalid in Setup Request
cmdResponse 9 <this RFC> IETF No Maximum test Bit rate specified
cmdResponse 10 <this RFC> IETF Server Maximum Bit rate exceeded
cmdResponse 11 <this RFC> IETF MTU option does not match Server
Other values are unassigned, with the upper boundary of 255.
11.2.6. Test Activation PDU Modifier Bitmap Registry
The Test Activation PDU layout (also) contains a modifierBitmap
field. The table below defines the initial bit assignments in the
registry.
Field Value Reference Change Description
Name Controller
===================================================================
modifierBitmap 0x00 <this RFC> IETF No modifications
modifierBitmap 0x01 <this RFC> IETF Set when srIndexConf is
START rate for search
modifierBitmap 0x02 <this RFC> IETF Set for RANDOMIZED
UDP payload
modifierBitmap 0x03-0xFF IETF Unassigned
Ciavattone & Geib Expires 1 January 2024 [Page 48]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
11.2.7. Test Activation PDU Command Request Registry
The Test Activation PDU layout contains a cmdRequest field. The
table below defines the assigned decimal values in the registry.
Field Value Reference Change Description
Name Controller
===================================================================
cmdRequest 0 <this RFC> IETF No Request
cmdRequest 1 <this RFC> IETF Request test in Upstream
direction (client to server)
cmdRequest 2 <this RFC> IETF Request test in Downstream
direction (server to client)
Other values are unassigned, with the upper boundary of 255.
11.2.8. Test Activation PDU Rate Adjustment Algo. Registry
The Test Activation PDU layout contains a rateAdjAlgo field. The
table below defines the assigned Capitalized alphabetic UTF-8 @@@@
values in the registry.
Field Value Reference Change Description
Name Controller
===================================================================
rateAdjAlgo A <this RFC> IETF Not used
rateAdjAlgo B <this RFC> IETF Rate algorithm Type B
rateAdjAlgo C <this RFC> IETF Rate algorithm Type C
Other values are unassigned, with the upper boundary of Z.
11.2.9. Test Activation PDU Command Response Field Registry
The Test Activation PDU layout (also) contains a cmdResponse field.
The table below defines the assigned decimal values in the registry.
Field Value Reference Change Description
Name Controller
===================================================================
cmdResponse 0 <this RFC> IETF None (value used by client in Request)
cmdResponse 1 <this RFC> IETF Server Acknowledgement
cmdResponse 2 <this RFC> IETF Server indicates an error
Ciavattone & Geib Expires 1 January 2024 [Page 49]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
Other values are unassigned, with the upper boundary of 255.
12. Acknowledgments
This specification has been edited by Al Morton. Al Morton died
before he was able to finalise this work. As Al can't complete
author tasks during the IETF standardisation process anymore, it was
decided not to keep him as an author in the proper section.
Respecting, that almost all of the content here has been edited or
created by Al, it seems fair not just to give him credit for his
work, but also list him as editor, if this document reaches RFC
status.
Thanks to Lincoln Lavoie, Can Desem, and Greg Mirsky for reviewing
this draft and providing helpful suggestions and areas for further
development. Ken Kerpez and Chen Li have provided helpful reviews.
Amanda Baber provided early reviews of the IANA Considerations
section.
Brian Weis provided an early SEC-DIR review; version 02 captures
clarifications and version 03 takes on the protocol changes the Brian
suggested.
13. References
13.1. Normative References
[FIPS-197] National Institute of Standards and Technology, NIST.,
"Federal Information Processing Standards Publication 197
(FIPS-197), ADVANCED ENCRYPTION STANDARD (AES)", 26
November 2001, <https://nvlpubs.nist.gov/nistpubs/fips/
nist.fips.197.pdf>.
[I-D.ietf-ippm-capacity-metric-method]
Morton, A. C., Geib, R., and L. Ciavattone, "Metrics and
Methods for One-Way IP Capacity", Work in Progress,
Internet-Draft, draft-ietf-ippm-capacity-metric-method-12,
9 June 2021, <https://datatracker.ietf.org/doc/html/draft-
ietf-ippm-capacity-metric-method-12>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Ciavattone & Geib Expires 1 January 2024 [Page 50]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/info/rfc2330>.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
September 1999, <https://www.rfc-editor.org/info/rfc2681>.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
DOI 10.17487/RFC6071, February 2011,
<https://www.rfc-editor.org/info/rfc6071>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>.
[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys",
RFC 7210, DOI 10.17487/RFC7210, April 2014,
<https://www.rfc-editor.org/info/rfc7210>.
[RFC7497] Morton, A., "Rate Measurement Test Protocol Problem
Statement and Requirements", RFC 7497,
DOI 10.17487/RFC7497, April 2015,
<https://www.rfc-editor.org/info/rfc7497>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/info/rfc7680>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
Ciavattone & Geib Expires 1 January 2024 [Page 51]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
[RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V.
Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for
the IP Performance Metrics (IPPM) Framework", RFC 8468,
DOI 10.17487/RFC8468, November 2018,
<https://www.rfc-editor.org/info/rfc8468>.
[RFC9097] Morton, A., Geib, R., and L. Ciavattone, "Metrics and
Methods for One-Way IP Capacity", RFC 9097,
DOI 10.17487/RFC9097, November 2021,
<https://www.rfc-editor.org/info/rfc9097>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
13.2. Informative References
[copycat] Edleine, K., Kuhlewind, K., Trammell, B., and B. Donnet,
"copycat: Testing Differential Treatment of New Transport
Protocols in the Wild (ANRW '17)", 15 July 2017,
<https://irtf.org/anrw/2017/anrw17-final5.pdf>.
[GCM] Dworkin, M., "NIST Special Publication 800-38D:
Recommendation for Block Cipher Modes of Operation:
Galois/Counter Mode (GCM) and GMAC, U.S. National
Institute of Standards and Technology", November 2007,
<https://csrc.nist.gov/publications/detail/sp/800-38d/
final>.
[LS-SG12-A]
12, I. S., "LS - Harmonization of IP Capacity and Latency
Parameters: Revision of Draft Rec. Y.1540 on IP packet
transfer performance parameters and New Annex A with Lab
Evaluation Plan", May 2019,
<https://datatracker.ietf.org/liaison/1632/>.
[LS-SG12-B]
12, I. S., "LS on harmonization of IP Capacity and Latency
Parameters: Consent of Draft Rec. Y.1540 on IP packet
transfer performance parameters and New Annex A with Lab &
Field Evaluation Plans", March 2019,
<https://datatracker.ietf.org/liaison/1645/>.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544,
DOI 10.17487/RFC2544, March 1999,
<https://www.rfc-editor.org/info/rfc2544>.
Ciavattone & Geib Expires 1 January 2024 [Page 52]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
[RFC3148] Mathis, M. and M. Allman, "A Framework for Defining
Empirical Bulk Transfer Capacity Metrics", RFC 3148,
DOI 10.17487/RFC3148, July 2001,
<https://www.rfc-editor.org/info/rfc3148>.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
2003, <https://www.rfc-editor.org/info/rfc3610>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<https://www.rfc-editor.org/info/rfc4656>.
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity",
RFC 5136, DOI 10.17487/RFC5136, February 2008,
<https://www.rfc-editor.org/info/rfc5136>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>.
[RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton,
"Applicability Statement for RFC 2544: Use on Production
Networks Considered Harmful", RFC 6815,
DOI 10.17487/RFC6815, November 2012,
<https://www.rfc-editor.org/info/rfc6815>.
[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling
Framework for IP Performance Metrics (IPPM)", RFC 7312,
DOI 10.17487/RFC7312, August 2014,
<https://www.rfc-editor.org/info/rfc7312>.
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A Framework for Large-Scale
Measurement of Broadband Performance (LMAP)", RFC 7594,
DOI 10.17487/RFC7594, September 2015,
<https://www.rfc-editor.org/info/rfc7594>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8337] Mathis, M. and A. Morton, "Model-Based Metrics for Bulk
Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March
2018, <https://www.rfc-editor.org/info/rfc8337>.
Ciavattone & Geib Expires 1 January 2024 [Page 53]
Internet-Draft Test Protocol: IP Capacity Measurement June 2023
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
Two-Way Active Measurement Protocol", RFC 8762,
DOI 10.17487/RFC8762, March 2020,
<https://www.rfc-editor.org/info/rfc8762>.
[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A.,
and E. Ruffini, "Simple Two-Way Active Measurement
Protocol Optional Extensions", RFC 8972,
DOI 10.17487/RFC8972, January 2021,
<https://www.rfc-editor.org/info/rfc8972>.
[TR-471] Morton, A,, Editor., "Broadband Forum TR-471: IP Layer
Capacity Metrics and Measurement, Issue 3", December 2022,
<https://www.broadband-forum.org/technical/download/TR-
471.pdf>.
[udpst] udpst Project Collaborators, "UDP Speed Test Open
Broadband project", December 2020,
<https://github.com/BroadbandForum/obudpst>.
[Y.1540] Y.1540, I. R., "Internet protocol data communication
service - IP packet transfer and availability performance
parameters", December 2019,
<https://www.itu.int/rec/T-REC-Y.1540-201912-I/en>.
[Y.Sup60] Morton, A., Rapporteur., "Recommendation Y.Sup60, (09/20)
Interpreting ITU-T Y.1540 maximum IP-layer capacity
measurements", 11 September 2020,
<https://www.itu.int/rec/T-REC-Y.Sup60/en>.
Authors' Addresses
Len Ciavattone
AT&T Labs
St. Johns, FL
United States of America
Email: lencia@att.com
Ruediger Geib
Deutsche Telekom
Heinrich Hertz Str. 3-7
64295 Darmstadt
Germany
Phone: +49 6151 5812747
Email: Ruediger.Geib@telekom.de
Ciavattone & Geib Expires 1 January 2024 [Page 54]