7. Test Activation Request and Response
Questa sezione conserva il testo RFC su UDPSTP, includendo One-Way IP Capacity metrics, Control and Data phases, Load and Status Feedback PDUs, KDF/HMAC authentication, optional checksum handling, IANA registries e security considerations.
Testo RFC originale
7. Test Activation Request and Response
This section is divided according to the sending and processing of
the client and server and again at the client.
7.1. Client Generates Test Activation Request
Upon a successful setup exchange, the client SHALL 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 standard UDPSTP port).
The UDP PDU format layout 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| txInterval1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| udpPayload1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burstSize1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| txInterval2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| udpPayload2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| burstSize2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| udpAddon2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pduId | protocolVer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmdRequest | cmdResponse | lowThresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| upperThresh | trialInt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| testIntTime | reserved1 | dscpEcn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| srIndexConf | useOwDelVar |highSpeedDelta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| slowAdjThresh | seqErrThresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ignoreOooDup |modifierBitmap | rateAdjAlgo | reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. srStruct (28 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subIntPeriod | reserved3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved4 | reserved5 | authMode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authUnixTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. authDigest (32 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| keyId | reservedAuth1 | checkSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Test Activation PDU Layout
Fields are populated based on default values or command-line options.
The authentication and checkSum fields follow the same methodology as
with the Setup Request and Response.
pduId: IANA has assigned the hex value 0xACE2 (Section 12.3.1).
cmdRequest: Set to CHTA_CREQ_TESTACTUS to indicate an upstream test
activation or alternatively to CHTA_CREQ_TESTACTDS to indicate a
downstream test activation. Note that CHTA_CREQ_NONE remains
unused. See Section 12.3.6.
cmdResponse: Three CHTA_CRSP_<Indication> values are defined; see
Figure 7.
lowThresh: A two-octet field. The lower threshold on the range of
Round-Trip Time (RTT) variation (the range is composed of values
above the minimum RTT); see also Table 3 [TR-471].
upperThresh: A two-octet field. The upper threshold on the range of
RTT variation (the range is composed of values above the minimum
RTT); see also Table 3 of [TR-471].
trialInt: A two-octet field indicating the Status Feedback / trial
interval in ms. The test interval Delta_t is subdivided into a
number of Sub-Intervals dt, and each Sub-Interval is further
divided into a number of trial intervals (see [TR-471]). Starts
by 1 and is continuously incremented during a single test interval
(testIntTime).
testIntTime: A two-octet field. Duration of the test (either
downlink or uplink) with search algorithm in use, which serves as
the maximum duration of the search process in seconds (see also
TestInterval in Table 3 of [TR-471]).
dscpEcn: Diffserv code point and ECN field; see also the DSCP field
specified by [TR-471]. This specification does not provide an
ECN-capable transport; therefore, the sender SHALL set the ECN
field to not_ECT.
srIndexConf: A two-octet field. The requested Configured Sending
Rate Table index, used in a Test Activation Request, of the
desired fixed or starting sending rate (depending on whether
CHTA_SRIDX_ISSTART is cleared or set, respectively). Because a
value of zero is a valid fixed or starting sending rate index, the
field SHALL be set to its maximum (CHTA_SRIDX_DEF) when requesting
the default behavior of the server (starting with the selected
load rate adjustment algorithm at its minimum/zero index). This
SHALL be equivalent to setting srIndexConf to zero and setting the
CHTA_SRIDX_ISSTART bit.
useOwDelVar: A one-octet field. Boolean, default True (if False,
use RTT=round-trip delay variation in the load rate adjustment
algorithm; if True, use EnableIPDV, which uses one-way delay
variation for the load rate adjustment algorithm). See EnableIPDV
in Table 1 of [TR-471].
highSpeedDelta: A one-octet field; see Appendix A of [RFC9097].
slowAdjThresh and seqErrThresh: Two two-octet fields; see Appendix A
of [RFC9097].
ignoreOooDup: A one-octet field. Ignore out-of-order duplicates,
Boolean. When True, only loss counts toward received packet
sequence number errors. When False, loss, out-of-order, and
duplicate totals are all counted as sequence number errors.
Default is True (see also Table 3 of [TR-471]).
modifierBitmap: A one-octet field. This document only assigns two
bits in this bitmap; see Section 12.3.7:
CHTA_SRIDX_ISSTART (0x01): Treat srIndexConf as the starting
sending rate to be used by the load rate adjustment algorithm.
CHTA_RAND_PAYLOAD (0x02): Randomize the payload content beyond
the Load PDU header.
Other bit positions are left unassigned per this document.
rateAdjAlgo: A one-octet field. The applied load rate adjustment
algorithm; see Section 12.3.8.
srStruct: Sending Rate structure. Used by the server in a Test
Activation Response for an upstream test to communicate the
(initial) Load PDU transmission parameters the client SHALL use.
For a Test Activation Request or a downstream test, this structure
SHALL be zeroed. Two sets of periodic transmission parameters are
available, allowing for dual independent transmitters (to support
a high degree of rate granularity). The fields are defined as
follows:
txInterval1 and txInterval2: Two four-octet fields indicating the
load rate transmit interval in us (microseconds). A 100 us
granularity is recommended for optimal rate selection.
udpPayload1 and udpPayload2: Two four-octet fields indicating the
UDP payload at load rate in bytes.
burstSize1 and burstSize2: Two four-octet fields indicating the
burst size at load rate by a dimensionless number (of
datagrams).
udpAddon2: A four-octet field indicating the size of a single
Load PDU to be sent at the end of the txInterval2 send
sequence, even when udpPayload2 or burstSize2 are zero and
result in no transmission of their own.
subIntPeriod: A two-octet field. Test Sub-Interval period in ms
(see also Table 3 of [TR-471]). Trials with subIntPeriod in a
range of 100 to 10000 ms resulted in a default value of 1000 ms.
authMode: Same as in Section 6.1.
authUnixTime: Same as in Section 6.1.
authDigest: Same as in Section 6.1.
keyId: Same as in Section 6.1.
reservedAuth1: Same as in Section 6.1.
checkSum: Same as in Section 6.1.
The Test Activation Request/Response message PDU (as well as the
included Sending Rate structure) SHALL be organized as follows:
<CODE BEGINS>
//
// Sending Rate structure for a single row of transmission parameters
//
struct sendingRate {
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)
};
//
// Control header for UDP payload of Test Act. Request/Response PDUs
//
struct controlHdrTA {
#define CHTA_ID 0xACE2
uint16_t pduId; // PDU ID
uint16_t protocolVer; // Protocol version
#define CHTA_CREQ_NONE 0
#define CHTA_CREQ_TESTACTUS 1 // Test activation upstream
#define CHTA_CREQ_TESTACTDS 2 // Test activation downstream
uint8_t cmdRequest; // Command Request
#define CHTA_CRSP_NONE 0 // (used with request)
#define CHTA_CRSP_ACKOK 1 // Acknowledgment
#define CHTA_CRSP_BADPARAM 2 // Bad/invalid test params
uint8_t cmdResponse; // Command Response
uint16_t lowThresh; // Low delay variation threshold (ms)
uint16_t upperThresh; // Upper delay variation threshold (ms)
uint16_t trialInt; // Status Feedback/trial interval (ms)
uint16_t testIntTime; // Test interval time (sec)
uint8_t reserved1; // (reserved for alignment)
uint8_t dscpEcn; // Diffserv and ECN field for testing
#define CHTA_SRIDX_DEF UINT16_MAX // Request default server search
uint16_t srIndexConf; // Configured Sending Rate Table index
uint8_t useOwDelVar; // Use one-way delay, not RTT (BOOL)
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/Dup (BOOL)
#define CHTA_SRIDX_ISSTART 0x01 // Use srIndexConf as starting index
#define CHTA_RAND_PAYLOAD 0x02 // Randomize payload
uint8_t modifierBitmap; // Modifier bitmap
#define CHTA_RA_ALGO_B 0 // Algorithm B
#define CHTA_RA_ALGO_C 1 // Algorithm C
uint8_t rateAdjAlgo; // Rate adjust. algorithm
uint8_t reserved2; // (reserved for alignment)
struct sendingRate srStruct; // Sending Rate structure
uint16_t subIntPeriod; // Sub-Interval period (ms)
uint16_t reserved3; // (reserved for alignment)
uint16_t reserved4; // (reserved for alignment)
uint8_t reserved5; // (reserved for alignment)
// ========== Integrity Verification ==========
uint8_t authMode; // Authentication mode
uint32_t authUnixTime; // Authentication timestamp
uint8_t authDigest[AUTH_DIGEST_LENGTH];
uint8_t keyId; // Key ID in shared table
uint8_t reservedAuth1; // (reserved for alignment)
uint16_t checkSum; // Header checksum
};
<CODE ENDS>
Figure 7: Test Activation PDU
7.2. Server Processes Test Activation Request and Generates Response
After the server receives the Test Activation Request on the new
connection, it chooses to accept, ignore, or modify any of the test
parameters. When the server replies to the Test Activation Request
message, the Test Activation Response PDU is structured identically
to the Request PDU and SHALL retain the original values received in
it unless they are explicitly coerced to a server-acceptable value.
When the server receives the Test Activation Request message, it
SHALL first follow the Message Verification Procedure listed in
Section 6.2, Paragraph 2.
7.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 via
srIndexConf.
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
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 rate adjustment algorithm: lowThresh, upperThresh,
useOwDelayVar, highSpeedDelta, slowAdjThresh, seqErrThresh,
highSpeedDelta, ignoreOooDup, and rateAdjAlgo
* Test duration/intervals: trialInt, testIntTime, and subIntPeriod
* Packet marking: dscpEcn
Coercion is a step towards 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. In these cases, the Command
Response value SHALL be CHTA_CRSP_ACKOK.
Note that the server also has the option of completely rejecting the
request and sending back an appropriate cmdResponse field value
(currently only CHTA_CRSP_BADPARAM; see Section 12.3.9).
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 Command
Response value being CHTA_CRSP_BADPARAM), and
* 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.
* If the authDigest is invalid, the Test Activation Request SHOULD
fail silently. The exception is for operations support: server
administrators are permitted to send an Activation Response to
support operations and troubleshooting.
The additional circumstances when a server SHALL NOT communicate the
appropriate Command Response code for an error condition (fail
silently) are when:
* the Test Activation Request PDU size is not equal to the 'struct
controlHdrTA' size shown in Figure 7,
* the PDU ID is not 0xACE2 (Test Activation PDU), or
* a directed attack has been detected.
In this case, the server will allow Test Activation Requests to
terminate silently. Attack detection is beyond the scope of this
specification.
7.2.2. Server Accepts Request and Generates Response
When the server sends the Test Activation Response, it SHALL set the
cmdResponse field to CHTA_CRSP_ACKOK (see Section 12.3.9).
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 (if requested by
setting srIndexConf to a value of CHTA_SRIDX_DEF), or
* include the transmission parameters from the designated Configured
Sending Rate Table index (srIndexConf) of the Sending Rate
Table where, if CHTA_SRIDX_ISSTART is set in modifierBitmap, this
will be used as the starting rate for the load rate adjustment
algorithm; else, it will be considered a fixed-rate test.
When generating the Test Activation Response (acceptance) for a
downstream test, the server SHALL set all octets of the Sending Rate
structure to zero.
If activation continues, the server prepares the new connection for
an upstream OR downstream test.
In the case of an upstream test, the server SHALL prepare to use a
single timer to send Status PDUs at the specified interval. For a
downstream test, the server SHALL prepare to utilize dual timers to
send Load PDUs based on:
* the transmission parameters directly from the first row of the
Sending Rate Table (if requested by srIndexConf having been set to
CHTA_SRIDX_DEF), or
* the transmission parameters from the designated Configured Sending
Rate Table index (srIndexConf) of the Sending Rate Table where, if
CHTA_SRIDX_ISSTART is set in modifierBitmap, this will be used as
the starting rate for the load rate adjustment algorithm; else, it
will be considered a fixed-rate test.
The server SHALL then send the Test Activation Response back to the
client, update the watchdog timer with a new timeout value, and set a
test duration timer to eventually stop the test.
7.3. Client Processes Test Activation Response
When the client receives the Test Activation Response message, it
SHALL first follow the Message Verification Procedure listed in
Section 6.2, Paragraph 2.
After the client receives the (vetted) Test Activation Response, it
first checks the Command Response value.
If the client receives a Test Activation cmdResponse field value that
indicates an error, the client SHALL display/report a relevant
message to the user or measurement system and exit.
If the client receives a Test Activation cmdResponse field value that
is not equal to one of the codes defined in Section 12.3.9, the
client MUST terminate the connection and terminate operation of the
current setup procedure.
If the client receives a Test Activation Command Response value that
indicates success (e.g., CHTA_CRSP_ACKOK; see Section 12.3.9), the
client SHALL update its configuration to use any test parameters
modified by the server. If the setup parameters coerced by the
server are not acceptable to the client, the client ends the test.
To finalize an accepted test activation, 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 and start a
watchdog timer to detect if the server goes quiet.
The connection is now ready for testing.