[要約] RFC 9946は、一方向IP容量メトリック（RFC 9097）を測定するためのUDPスピードテストプロトコル（UDPSTP）を定義する標準トラック文書です。受信側からのリアルタイムなフィードバックを基に送信レートを制御する測定手法をサポートし、ネットワークの有効帯域幅を正確に把握するためのプロトコル仕様を提供します。一方向の容量測定における一貫性と精度の向上を目指しています。
Internet Engineering Task Force (IETF) A. Morton
Request for Comments: 9946 L. Ciavattone
Category: Standards Track AT&T Labs
ISSN: 2070-1721 R. Geib, Ed.
Deutsche Telekom
April 2026
This document addresses the problem of protocol support for measuring One-Way IP Capacity metrics specified by RFC 9097. The Method of Measurement discussed in that RFC requires a feedback channel from the receiver to control the sender's transmission rate in near real-time. This document defines the UDP Speed Test Protocol (UDPSTP) for conducting measurements as described in RFC 9097 and other related measurements.
この文書は、RFC 9097 で指定された一方向 IP 容量メトリクスを測定するためのプロトコル サポートの問題を扱います。RFC で説明されている測定方法では、送信側の送信レートをほぼリアルタイムで制御するために受信側からのフィードバック チャネルが必要です。この文書は、RFC 9097 に記載されている測定およびその他の関連測定を実行するための UDP スピード テスト プロトコル (UDPSTP) を定義します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9946.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9946 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Conventions and Terminology
3. Scope, Goals, and Applicability
4. Protocol Overview
4.1. Fixed-Rate Testing
4.2. Handling of and Safeguards Required by Self-Induced
Congestion
5. Requirements, Security Operations, and Optional Checksum
5.1. Load Rate Adjustment Algorithm Requirements
5.2. Parameters and Definitions
5.3. Security Mode Operations
5.3.1. Mode 1: Required Authenticated Mode
5.3.2. Mode 2: Optional Authenticated Mode for Data Phase
5.4. Key Management
5.4.1. Key Derivation Function (KDF)
5.5. Configuration of Network Functions with Stateful Filtering
5.6. Optional Checksum
6. Test Setup Request and Response
6.1. Client Generates Test Setup Request
6.2. Server Test Setup Request Processing and Response
Generation
6.2.1. Test Setup Request Processing -- Rejection
6.2.2. Test Setup Request Processing -- Acceptance
6.3. Setup Response Processing at the Client
7. Test Activation Request and Response
7.1. Client Generates Test Activation Request
7.2. Server Processes Test Activation Request and Generates
Response
7.2.1. Server Rejects or Modifies Request
7.2.2. Server Accepts Request and Generates Response
7.3. Client Processes Test Activation Response
8. Test Load Stream Transmission and Measurement Status Feedback
Messages
8.1. Load PDU and Roles
8.2. Status PDU
9. Stopping a Test
10. Operational Considerations for the Measurement Method
10.1. Notes on Interface Measurements
11. Security Considerations
12. IANA Considerations
12.1. New User Port Number Assignment
12.2. New KeyTable KDF
12.3. New UDPSTP Registry Group
12.3.1. PDU Identifier Registry
12.3.2. Protocol Version Registry
12.3.3. Test Setup PDU Modifier Bitmap Registry
12.3.4. Test Setup PDU Authentication Mode Registry
12.3.5. Test Setup PDU Command Response Field Registry
12.3.6. Test Activation PDU Command Request Registry
12.3.7. Test Activation PDU Modifier Bitmap Registry
12.3.8. Test Activation PDU Rate Adjustment Algo Registry
12.3.9. Test Activation PDU Command Response Field Registry
12.4. Guidelines for Designated Experts
13. References
13.1. Normative References
13.2. Informative References
Appendix A. KDF Example (OpenSSL)
Acknowledgments
Authors' Addresses
The performance community has seen the development of informative Bulk Transport Capacity (BTC) definitions in "A Framework for Defining Empirical Bulk Transfer Capacity Metrics" [RFC3148] and "Defining Network Capacity" [RFC5136] as well as experimental metric definitions and methods in "Model-Based Metrics for Bulk Transport Capacity" [RFC8337].
パフォーマンスコミュニティは、「経験的なバルク転送容量メトリクスを定義するためのフレームワーク」[RFC3148] および「ネットワーク容量の定義」[RFC5136] における有益なバルク転送容量 (BTC) 定義の開発、および「バルク転送容量のモデルベースのメトリクス」[RFC8337] における実験的なメトリクス定義と手法の開発を見てきました。
This document specifies the UDP Speed Test Protocol (UDPSTP) to enable the measurement of One-Way IP Capacity metrics as defined by [RFC9097]. The Method of Measurement discussed in that RFC deploys a feedback channel from the receiver to control the sender's transmission rate in near real-time. Section 8.1 of [RFC9097] specifies requirements for this method.
この文書は、[RFC9097] で定義されている一方向 IP 容量メトリクスの測定を可能にする UDP スピード テスト プロトコル (UDPSTP) を規定します。RFC では、送信側の送信速度をほぼリアルタイムで制御するために受信側からのフィードバック チャネルを展開するという測定方法について説明されています。[RFC9097] のセクション 8.1 では、このメソッドの要件が指定されています。
UDPSTP supports measurement features that weren't available via TCP-based speed tests and standard measurement protocols, such as the One-Way Active Measurement Protocol (OWAMP) [RFC4656], Two-Way Active Measurement Protocol (TWAMP) [RFC5357], and Simple Two-Way Active Measurement Protocol (STAMP) [RFC8762], prior to this work. The controlled BTC measurement or Speed Test, respectively, is based on UDP rather than TCP. The bulk measurement load is unidirectional. These specifications did support the creation of asymmetric traffic in combination with some two-way communication, as supported by TWAMP and STAMP, when work on UDPSTP started. Further, two-way communications of TWAMP and STAMP are limited to reflection or unidirectional load properties, but they lack support for closed loop feedback operation. The latter enables limiting congestion of a bottleneck, whose capacity is measured, to a short time range. Support of such a control loop is the main purpose of UDPSTP.
UDPSTP は、この作業以前には、TCP ベースの速度テストや標準測定プロトコル (One-Way Active Measurement Protocol (OWAMP) [RFC4656]、Two-Way Active Measurement Protocol (TWAMP) [RFC5357]、Simple Two-Way Active Measurement Protocol (STAMP) [RFC8762] など) では利用できなかった測定機能をサポートしています。制御された BTC 測定または速度テストは、それぞれ TCP ではなく UDP に基づいています。バルク測定負荷は一方向です。これらの仕様は、UDPSTP の作業が開始されたときに、TWAMP および STAMP でサポートされているような、いくつかの双方向通信と組み合わせた非対称トラフィックの作成をサポートしていました。さらに、TWAMP と STAMP の双方向通信は反射または一方向負荷特性に限定されますが、閉ループ フィードバック動作はサポートされていません。後者では、容量を計測するボトルネックの輻輳を短時間の範囲に限定することが可能となる。このような制御ループのサポートが UDPSTP の主な目的です。
Apart from measurement functionality, a Key Derivation Function (KDF) has been added to provide cryptographic separation of key material for authentication of protocol messages in a standardized and cryptographically secure manner. This is a secondary improvement reached by UDPSTP and may simplify its reuse for other measurement purposes. Additionally, because the protocol uses synthetic payload data and contains no direct user information, a decision was made to forgo encryption support. This is also expected to increase the number of low-end devices that can support the test methodology.
測定機能とは別に、標準化された暗号的に安全な方法でプロトコル メッセージの認証のためのキー素材を暗号的に分離するために、キー導出機能 (KDF) が追加されました。これは UDPSTP によって達成された二次的な改善であり、他の測定目的での再利用が簡素化される可能性があります。さらに、このプロトコルでは合成ペイロード データが使用され、直接のユーザー情報が含まれていないため、暗号化のサポートを省略することが決定されました。これにより、このテスト方法をサポートできるローエンド デバイスの数も増加すると予想されます。
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.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Downstream UDP Speed Test:
ダウンストリーム UDP 速度テスト:
A client-initiated Network Capacity measurement between a server acting as sender and a client acting as receiver.
送信者として機能するサーバーと受信者として機能するクライアントの間で、クライアントによって開始されるネットワーク キャパシティ測定。
Upstream UDP Speed Test:
アップストリーム UDP 速度テスト:
A client-initiated Network Capacity measurement between a client acting as sender and a server acting as receiver.
送信者として機能するクライアントと受信者として機能するサーバーの間で、クライアントによって開始されるネットワーク キャパシティ測定。
In this document, the term "message" and the term "Protocol Data Unit", or "PDU" [RFC5044], are used interchangeably.
この文書では、「メッセージ」という用語と「プロトコル データ ユニット」または「PDU」[RFC5044] という用語は同じ意味で使用されます。
The scope of this document is to define a protocol to measure the Maximum IP-Layer Capacity Metric according to the Method of Measurement standardized by Section 8 of [RFC9097]. As such, this document adheres to the applicability scope defined in Section 2 of [RFC9097].
この文書の範囲は、[RFC9097] のセクション 8 で標準化された測定方法に従って、最大 IP 層容量メトリックを測定するプロトコルを定義することです。したがって、この文書は [RFC9097] のセクション 2 で定義されている適用範囲に準拠します。
Some 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 rate adjustment algorithm. Per [RFC9097], that algorithm must not be used as a general Congestion Control Algorithm (CCA). Instead, the load rate adjustment algorithm's goal is to help determine the Maximum IP-Layer Capacity in the context of an infrequent, diagnostic, short-term measurement.
このプロトコルとエンドホスト構成のいくつかの側面は、負荷率調整アルゴリズムの創造的な使用によって可能になるアプリケーション エミュレーションなど、追加形式の測定のサポートにつながる可能性があります。[RFC9097] によれば、そのアルゴリズムは一般的な輻輳制御アルゴリズム (CCA) として使用してはなりません。代わりに、負荷率調整アルゴリズムの目標は、頻度の低い、診断用の短期間の測定のコンテキストで最大 IP 層キャパシティを決定するのに役立つことです。
The goal is to harmonize the specified IP-Layer Capacity Metric and Method across the industry, and this protocol supports the specifications of IETF (see [RFC9097]) and other Standards Development Organizations (SDOs) (see, e.g., [TR-471]).
目標は、業界全体で指定された IP 層容量のメトリクスと方法を調和させることであり、このプロトコルは IETF ([RFC9097] を参照) および他の標準開発組織 (SDO) (例: [TR-471] を参照) の仕様をサポートしています。
The primary application of UDPSTP described here is the same as in Section 2 of [RFC7497] where:
ここで説明する UDPSTP の主なアプリケーションは、[RFC7497] のセクション 2 と同じです。
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.
ネットワークのアクセス部分がこの問題ステートメントの焦点です。ユーザーは通常、双方向アクセスを備えたサービスに加入します。このサービスは部分的にビット/秒のレートで表されます。
UDPSTP is a client-based protocol. It may be applied by consumers to measure their own access bandwidth. Consumers may prefer an independent third-party domain hosting the measurement server for this purpose. UDPSTP may be deployed in Large-scale Measurement of Broadband Performance (LMAP) environments (see [RFC7497]) and other independent third-party domain measurement server deployments. A network operator may support operation and maintenance by UDPSTP, a typical intra-domain deployment. All these deployments require or benefit from trusting the results, which are ensured by authenticated communication.
UDPSTP はクライアントベースのプロトコルです。消費者は、自身のアクセス帯域幅を測定するために適用できます。消費者は、この目的のために測定サーバーをホストする独立したサードパーティのドメインを好む場合があります。UDPSTP は、大規模ブロードバンド パフォーマンス測定 (LMAP) 環境 ([RFC7497] を参照) およびその他の独立したサードパーティ ドメイン測定サーバーの展開に展開できます。ネットワーク オペレータは、典型的なドメイン内展開である UDPSTP による運用と保守をサポートする場合があります。これらすべての展開では、認証された通信によって保証される結果を信頼する必要があるか、その結果を信頼することで利益が得られます。
All messages defined by this document SHALL use UDP transport [RFC0768].
この文書で定義されるすべてのメッセージは UDP トランスポート [RFC0768] を使用するものとします (SHALL)。
The remainder of this section gives an informative overview of the communication protocol between two test endpoints (without expressing requirements or elaborating on the authentication aspects).
このセクションの残りの部分では、2 つのテスト エンドポイント間の通信プロトコルの有益な概要を説明します (要件の表明や認証の側面の詳細は省略します)。
One endpoint takes the role of server, listening for connection requests on a standard UDP Speed Test Protocol port number from the other endpoint, the client.
一方のエンドポイントはサーバーの役割を果たし、標準の UDP スピード テスト プロトコル ポート番号で、もう一方のエンドポイントであるクライアントからの接続要求をリッスンします。
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(es) of the server(s) in order to begin the setup and configuration exchanges with the server(s). By default, the client uses the single, standard UDPSTP port number per connection (see Section 6). If the default port number is not used, the client may require configuration of the control port number used by each server. This would be the case if multiple server instances (processes) operate on one or more machines.
クライアントは、サーバーとのセットアップおよび構成の交換を開始するために、テスト方向パラメーター (クライアントがそれぞれ送信者または受信者の役割を実行するアップストリームまたはダウンストリームのテスト) およびサーバーのホスト名または IP アドレスの構成を必要とします。デフォルトでは、クライアントは接続ごとに単一の標準 UDPSTP ポート番号を使用します (セクション 6 を参照)。デフォルトのポート番号が使用されない場合、クライアントは各サーバーで使用される制御ポート番号の構成を必要とする場合があります。これは、複数のサーバー インスタンス (プロセス) が 1 つ以上のマシン上で動作している場合に当てはまります。
Additionally, multi-connection (multi-flow) testing is supported by the protocol. Each connection is independent and attempts to maximize its own individual traffic rate. For multi-connection tests, a single client process would replicate the connection setup and test procedure multiple times (once for each flow) to one or more server instances. The server instance(s) would process each connection independently, as if they were coming from separate clients. It is the responsibility of the client process to manage the inter-related connections such as handling the individual connection setup successes and failures, cleaning up connections during a test (should some fail), and aggregating the individual test results into an overall set of performance statistics. Fields in the Setup Request (i.e., mcIndex, mcCount, and mcIdent; see Section 6.1) are used to both differentiate and associate the multiple connections that comprise a single test.
さらに、このプロトコルではマルチ接続 (マルチフロー) テストがサポートされています。各接続は独立しており、それぞれの個別のトラフィック レートを最大化しようとします。複数接続テストの場合、単一のクライアント プロセスは、接続セットアップとテスト手順を 1 つ以上のサーバー インスタンスに複数回 (フローごとに 1 回) 複製します。サーバー インスタンスは、あたかも別のクライアントから送信されているかのように、各接続を独立して処理します。個々の接続セットアップの成功と失敗の処理、テスト中の接続のクリーンアップ (一部が失敗した場合)、個々のテスト結果を全体的なパフォーマンス統計セットに集約するなど、相互に関連する接続を管理するのはクライアント プロセスの責任です。セットアップ リクエストのフィールド (つまり、mcIndex、mcCount、および mcIdent、セクション 6.1 を参照) は、単一のテストを構成する複数の接続を区別し、関連付けるために使用されます。
The protocol uses UDP transport with two connection phases (Control and Data). As shown below, exchanges 1 and 2 constitute the Control phase, while exchanges 3 and 4 constitute the Data phase. In this document, the term "message" and the term "Protocol Data Unit", or "PDU" [RFC5044], are used interchangeably.
このプロトコルは、2 つの接続フェーズ (制御とデータ) で UDP トランスポートを使用します。以下に示すように、交換機 1 と 2 は制御フェーズを構成し、交換機 3 と 4 はデータ フェーズを構成します。この文書では、「メッセージ」という用語と「プロトコル データ ユニット」または「PDU」[RFC5044] という用語は同じ意味で使用されます。
1. Test Setup Request and Response: If a server instance is identified with a host name that resolves to both IPv4/IPv6 addresses, it is recommended to use the first address returned in the name resolution response, regardless of whether it is IPv4 or IPv6. Thus, the decision on the preferred IP address family is left to the name resolver's default behavior. Support for separate IPv4 and IPv6 measurements or an IPv4 and IPv6 multi-connection setup are left for future improvement. The client then requests to begin a test by communicating its UDPSTP protocol version, intended security mode, and datagram size support. The server either confirms matching a configuration or rejects the connection request. If the request is accepted, the server provides a unique ephemeral port number for each test connection, allowing further communication. In a multi-connection setup, distinct UDP port numbers may be assigned with each Setup Response from a server instance. Distinct UDP port numbers will be assigned if all Setup Response messages originate from the same server in that case.
1. セットアップの要求と応答のテスト: サーバー インスタンスが IPv4/IPv6 アドレスの両方に解決されるホスト名で識別される場合は、IPv4 か IPv6 かに関係なく、名前解決応答で返された最初のアドレスを使用することをお勧めします。したがって、優先 IP アドレス ファミリの決定はネーム リゾルバーのデフォルトの動作に委ねられます。個別の IPv4 と IPv6 の測定、または IPv4 と IPv6 のマルチ接続セットアップのサポートは、将来の改善のために残されています。次に、クライアントは、UDPSTP プロトコルのバージョン、対象のセキュリティ モード、およびデータグラム サイズのサポートを伝えることによって、テストの開始を要求します。サーバーは、構成の一致を確認するか、接続要求を拒否します。要求が受け入れられると、サーバーは各テスト接続に一意の一時ポート番号を提供し、その後の通信が可能になります。複数接続セットアップでは、サーバー インスタンスからの各セットアップ応答に個別の UDP ポート番号が割り当てられる場合があります。すべてのセットアップ応答メッセージが同じサーバーから発信されている場合、個別の UDP ポート番号が割り当てられます。
2. Test Activation Request and Response: After having received a confirmation of the configuration by a server, 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 (for a detailed discussion, see [RFC9097] and [TR-471]). 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 number) and the traffic that follows. See [RFC9097] for a more detailed discussion of firewall and NAT-related features. If the Test Activation Request is rejected or fails, the client assumes that the firewall will close the address/port number pinhole entry after the firewall's configured idle traffic timeout.
2. テストアクティベーションのリクエストとレスポンス: サーバーから設定の確認を受け取った後、クライアントは、テストの方向、テスト間隔とテストサブ間隔の継続時間、およびさまざまなしきい値などのパラメータを伝えるリクエストを作成します (詳細については、[RFC9097] および [TR-471] を参照)。次に、サーバーはテスト パラメータのいずれかを受け入れるか、無視するか、変更するかを選択し、クライアントが変更を拒否しない限り、使用されるセットを通信します。クライアントは、テスト アクティベーション交換により、テスト接続 (一時ポート番号の要求パケットに応答して) とそれに続くトラフィック用に、同じ場所にあるファイアウォールとネットワーク アドレス/ポート トランスレータが開かれたと想定していることに注意してください。ファイアウォールと NAT 関連の機能の詳細については、[RFC9097] を参照してください。テスト アクティベーション要求が拒否または失敗した場合、クライアントは、ファイアウォールの設定されたアイドル トラフィック タイムアウト後にファイアウォールがアドレス/ポート番号のピンホール エントリを閉じると想定します。
3. Test Stream Transmission and Measurement Feedback Messages: Testing proceeds with one endpoint sending the Load PDUs and the other endpoint receiving the Load PDUs and sending frequent status messages to communicate the status and reception conditions. The data in the feedback messages, whether received from the client or when being sent to the client, is input to a load rate adjustment algorithm at the server, which controls future sending rates at either end. The choice to locate the load rate adjustment 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. Note that the status messages also help keep the pinhole (or mapping, respectively) active at on-path stateful devices. UDPSTP is at least partially compliant to Section 3.1 of [RFC8085] if the bottleneck is congested, but pending congestion is avoided by limiting the duration of that congestion to the minimum required to determine the bottleneck capacity.
3. テスト ストリーム送信および測定フィードバック メッセージ: テストは、一方のエンドポイントが Load PDU を送信し、もう一方のエンドポイントが Load PDU を受信してステータス メッセージを頻繁に送信してステータスと受信状態を伝達することで進行します。フィードバック メッセージ内のデータは、クライアントから受信した場合でも、クライアントに送信した場合でも、サーバーの負荷レート調整アルゴリズムに入力され、どちらの側でも将来の送信レートが制御されます。送信方向に関係なく、負荷率調整アルゴリズムをサーバーに配置するという選択は、ネットワーク内のホストで、クライアントの数よりも少ないホストでアルゴリズムをより簡単に更新できることを意味します。ステータス メッセージは、パス上のステートフル デバイスでピンホール (またはそれぞれマッピング) をアクティブに保つのにも役立つことに注意してください。ボトルネックが輻輳している場合、UDPSTP は [RFC8085] のセクション 3.1 に少なくとも部分的に準拠しますが、その輻輳の継続時間をボトルネックの容量を決定するために必要な最小限に制限することによって保留中の輻輳が回避されます。
4. Stopping the Test: When the specified test duration has been reached, the server initiates the exchange to stop the test by setting a STOP indication in its outgoing Load PDUs or Status Feedback messages. After being received, the client acknowledges it by also setting a STOP indication in its outgoing Load PDUs or Status Feedback messages. A graceful connection termination at each end then follows. Since the Load PDUs and Status Feedback messages are used, this exchange is considered a sub-exchange of 3 above. If the test traffic stops or the communication path fails, the client assumes that the firewall will close the address/port number combination after the firewall's configured idle traffic timeout.
4. テストの停止: 指定されたテスト期間に達すると、サーバーは発信ロード PDU またはステータス フィードバック メッセージに STOP 指示を設定することにより、テストを停止するための交換を開始します。受信後、クライアントは発信ロード PDU またはステータス フィードバック メッセージに STOP 表示を設定することによって、それを確認します。その後、各端で正常に接続が終了します。Load PDU とステータス フィードバック メッセージが使用されるため、この交換は上記 3 のサブ交換とみなされます。テスト トラフィックが停止するか、通信パスに障害が発生した場合、クライアントは、ファイアウォールの設定されたアイドル トラフィック タイムアウト後にファイアウォールがアドレスとポート番号の組み合わせを閉じると想定します。
5. Both the client and server react to unexpected interruptions in the Control or Data phase, respectively. Watchdog timers limit the time a server or client will wait before stopping all traffic and terminating a test.
5. クライアントとサーバーは両方とも、それぞれ制御フェーズまたはデータフェーズでの予期せぬ割り込みに反応します。ウォッチドッグ タイマーは、すべてのトラフィックを停止してテストを終了するまでにサーバーまたはクライアントが待機する時間を制限します。
Figure 1 provides an example exchange of control and measurement PDUs for both downstream and upstream UDP Speed Tests (always client initiated):
図 1 は、ダウンストリームとアップストリームの両方の UDP 速度テスト (常にクライアントが開始) の制御 PDU と測定 PDU の交換の例を示しています。
=========== Downstream Test ===========
+---------+ +---------+
| Client | Test Setup Request -----> | Server |
+---------+ +---------+
<----- Test Setup Response (Accept)
<----- Null Request PDU
Test Activation Request ----->
<----- Test Activation Response (Accept)
<----- Load PDUs
Status Feedback PDUs ----->
After expiry of server's test duration timer...
<----- Load PDU (TEST_ACT_STOP)
Status Feedback PDU (TEST_ACT_STOP) ----->
============ Upstream Test ============
+---------+ +---------+
| Client | Test Setup Request -----> | Server |
+---------+ +---------+
<----- Test Setup Response (Accept)
<----- Null Request PDU
Test Activation Request ----->
<----- Test Activation Response (Accept)
Load PDUs ----->
<----- Status Feedback PDUs
After expiry of server's test duration timer...
<----- Status Feedback PDU (TEST_ACT_STOP)
Load PDU (TEST_ACT_STOP) ----->
Figure 1: Successful UDPSTP Message Exchanges
図 1: 成功した UDPSTP メッセージ交換
A network operator who is certain of the IP-Layer Capacity to be validated can execute a fixed-rate test of the IP-Layer Capacity and avoid activating the measurement load rate adjustment algorithm (see Section 8.1 of [RFC9097]). Fixed-rate testing SHOULD only be activated for operation and maintenance purposes by operators within their local network domain.
IP 層容量が検証されることを確信しているネットワーク オペレータは、IP 層容量の固定レート テストを実行し、測定負荷率調整アルゴリズムのアクティブ化を回避できます ([RFC9097] のセクション 8.1 を参照)。固定料金テストは、ローカル ネットワーク ドメイン内のオペレータによって、運用およびメンテナンスの目的でのみアクティブ化されるべきです(SHOULD)。
If a subscriber requests a diagnostic test from the network operator, it strongly implies that there is no certainty on the bottleneck capacity and initiating a UDP Speed Test based on the load adjustment algorithm is RECOMMENDED. To protect against misuse, a client (and in general, a consumer) MUST NOT be able to initiate a fixed-rate test. A network operator may conduct a fixed-rate test for a stable measurement at or near the maximum determined by the load rate adjustment algorithm for debugging purposes. This may be valuable for post-installation or post-repair verification.
加入者がネットワーク オペレータに診断テストを要求した場合、ボトルネック キャパシティに確実性がないことを強く意味しており、負荷調整アルゴリズムに基づいて UDP 速度テストを開始することが推奨されます。悪用を防ぐために、クライアント (および一般に消費者) は固定レートのテストを開始できてはなりません。ネットワーク オペレータは、デバッグ目的で、負荷率調整アルゴリズムによって決定される最大値またはそれに近い値で安定した測定を行うための固定レート テストを実施する場合があります。これは、インストール後または修理後の検証に役立つ場合があります。
Active capacity measurement requires inducing intentional congestion. On paths where the capacity bottleneck is not shared with other flows, this self-congestion will be observed as loss and/or delay. However, when a path is shared by other flows, the measurement traffic can congest the bottleneck on the path and therefore degrade the performance of other flows. Unrestricted use of UDPSTP could lead to traffic starvation and significant issues.
アクティブ キャパシティの測定には、意図的に輻輳を引き起こす必要があります。容量のボトルネックが他のフローと共有されていないパスでは、この自己輻輳が損失や遅延として観察されます。ただし、パスが他のフローによって共有されている場合、測定トラフィックによってパス上のボトルネックが輻輳し、他のフローのパフォーマンスが低下する可能性があります。UDPSTP を無制限に使用すると、トラフィックの枯渇や重大な問題が発生する可能性があります。
Measurements that generate traffic on shared paths (including Wi-Fi and Internet paths) need to consider the impact on other traffic. Fixed-rate testing operates without congestion control and therefore must not be executed over other operators' network segments. Fixed-rate testing, therefore, is limited to paths within a domain entirely managed and operated section-wise and end-to-end by the network operator performing the measurement. When the risks of disruption to other flows has been considered, testing could be extended to include adjacent operational domains for which there is also a testing agreement.
共有パス (Wi-Fi やインターネット パスを含む) 上でトラフィックを生成する測定では、他のトラフィックへの影響を考慮する必要があります。固定レートのテストは輻輳制御なしで動作するため、他の事業者のネットワーク セグメント上で実行してはなりません。したがって、固定レートのテストは、測定を実行するネットワーク オペレータによってセクション単位およびエンドツーエンドで完全に管理および運用されるドメイン内のパスに限定されます。他のフローへの中断のリスクを考慮した場合、テスト契約が締結されている隣接する運用ドメインを含めてテストを拡張することができます。
Concurrent tests that congest a common bottleneck will impair the measurement and result in additional congestion. Concurrent measurements to measure the maximum capacity on a single path are counterproductive. The number of concurrent independent tests of a path SHALL be limited to one, regardless of the number of flows.
共通のボトルネックを輻輳させるテストを同時に実行すると、測定が損なわれ、さらなる輻輳が発生します。単一パスの最大容量を測定するための同時測定は逆効果です。パスの同時独立テストの数は、フローの数に関係なく、1 つに制限されるものとします (SHALL)。
A load rate adjustment algorithm (see Section 5.1) is required to mitigate the impact of this congestion and to limit the duration of any congestion by terminating the test when sudden impairments or a loss of connectivity is detected.
この輻輳の影響を軽減し、突然の障害や接続の喪失が検出されたときにテストを終了することで輻輳の継続時間を制限するには、負荷率調整アルゴリズム (セクション 5.1 を参照) が必要です。
Security and checksum operations aren't covered by [RFC9097], which only defines the Method of Measurement. This section adds the operational specification related to security and the optional checksum. Due to the additional complexities, and loss of the direct mapping of packets to datagrams between Layer 3 and Layer 4, it is recommended that Layer 3 fragmentation be avoided. A simplified approach is to choose the default datagram size that is small enough to prevent fragmentation. This version of the specification does not support Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) [RFC8899]. A future version could specify how to support this. DPLPMTUD support will require a carefully adapted protocol design to ensure interoperability. Unless IP fragmentation is expected, and is one of the attributes being measured, the IPv4 Don't Fragment (DF) bit SHOULD be set for all tests.
セキュリティとチェックサム操作は、測定方法のみを定義する [RFC9097] ではカバーされていません。このセクションでは、セキュリティとオプションのチェックサムに関連する動作仕様を追加します。複雑さが増し、レイヤー 3 とレイヤー 4 の間でデータグラムへのパケットの直接マッピングが失われるため、レイヤー 3 のフラグメンテーションを回避することをお勧めします。簡素化されたアプローチは、断片化を防ぐのに十分小さいデフォルトのデータグラム サイズを選択することです。このバージョンの仕様は、Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) [RFC8899] をサポートしていません。将来のバージョンでは、これをサポートする方法が指定される可能性があります。DPLPMTUD のサポートには、相互運用性を確保するために注意深く調整されたプロトコル設計が必要です。IP フラグメンテーションが予期され、測定対象の属性の 1 つである場合を除き、IPv4 Don't Fragment (DF) ビットをすべてのテストに設定する必要があります (SHOULD)。
Note: When this specification is used for network debugging, it may be useful for fragmentation to be under the control of the test administrator.
注: この仕様をネットワーク デバッグに使用する場合、フラグメンテーションをテスト管理者の制御下に置くと便利な場合があります。
This section specifies generic requirements, which a measurement load rate adjustment algorithm conforming to this specification MUST fulfill.
このセクションでは、この仕様に準拠する測定負荷率調整アルゴリズムが満たさなければならない一般的な要件を指定します。
This document specifies an active capacity measurement method using a load rate adjustment algorithm. The requirements listed in this section and the currently standardized load rate adjustment algorithms B [Y.1540Amd2] and C [TR-471] result from years of experiments and testing by the original authors. These tests were performed in labs, and also in the Internet, and covered a set of different fixed, broadband, mobile, and wireless access types and technologies in different countries and continents. Further, the load rate adjustment algorithm requirements listed below reflect feedback from performance measurement experts, as well as changes resulting from the standardization of [RFC9097] (reflected also in algorithm B [Y.1540Amd2], which updates a prior version of this algorithm).
この文書は、負荷率調整アルゴリズムを使用した有効容量の測定方法を規定します。このセクションに記載されている要件と、現在標準化されている負荷率調整アルゴリズム B [Y.1540Amd2] および C [TR-471] は、元の作成者による長年の実験とテストの結果です。これらのテストは研究室だけでなくインターネットでも実施され、さまざまな国や大陸の一連のさまざまな固定、ブロードバンド、モバイル、ワイヤレス アクセス タイプとテクノロジーを対象としました。さらに、以下に挙げる負荷率調整アルゴリズムの要件は、パフォーマンス測定の専門家からのフィードバックと、[RFC9097] の標準化に起因する変更を反映しています (このアルゴリズムの以前のバージョンを更新するアルゴリズム B [Y.1540Amd2] にも反映されています)。
Load rate adjustment algorithms for capacity measurement MUST comply with the requirements specified by this section. New standard load rate adjustment algorithms for capacity measurement MUST be reviewed by IETF designated experts prior to assignment of a code point in the "Test Activation PDU Rate Adjustment Algo" registry.
容量測定のための負荷率調整アルゴリズムは、このセクションで指定された要件に準拠しなければなりません。容量測定のための新しい標準負荷率調整アルゴリズムは、「Test Activation PDU Rate Adjustment Algo」レジストリにコード ポイントを割り当てる前に、IETF 指定の専門家によってレビューされなければなりません。
The load rate adjustment algorithm for capacity measurement requirements are as follows:
容量測定要件の負荷率調整アルゴリズムは次のとおりです。
1. The measurement load rate adjustment algorithm described in this section MUST NOT be used as a general CCA.
1. このセクションで説明する測定負荷率調整アルゴリズムは、一般的な CCA として使用してはなりません。
2. This specification MUST only be used in the application of diagnostic and operations measurements.
2. この仕様は、診断および運用測定のアプリケーションでのみ使用しなければなりません (MUST)。
3. Both Load PDU messages and Status Feedback PDU messages MUST contain sequence numbers.
3. ロード PDU メッセージとステータス フィードバック PDU メッセージの両方にシーケンス番号が含まれなければなりません (MUST)。
4. The nominal duration of a measurement interval at the Destination, parameter testIntTime ("I" in [RFC9097]), MUST default to a value of no more than 10 seconds.
4. 宛先での測定間隔の公称期間、パラメータ testIntTime ([RFC9097] の「I」) は、デフォルトで 10 秒以下の値に設定されなければなりません (MUST)。
5. A high-speed mode to achieve high sending rates quickly MUST reduce the measurement load below a level for which the first feedback interval inferred "congestion" 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 indicate "congestion" within a test. The threshold of consecutive feedback intervals SHALL be configurable with a default of 3 intervals and a maximum duration to infer congestion of 500 ms (milliseconds).
5. 高い送信レートを迅速に達成するための高速モードは、最初のフィードバック間隔が測定値から「輻輳」を推定するレベルよりも測定負荷を低減しなければなりません。シーケンス番号異常のしきい値を超えるカウントが連続するフィードバック間隔、および/または連続間隔のすべてに遅延変動上限しきい値例外が含まれる連続フィードバック間隔は、テスト内の「輻輳」を示します。連続フィードバック間隔のしきい値は、デフォルトの 3 間隔と、輻輳を推定する最大期間 500 ms (ミリ秒) で構成可能であるものとします (SHALL)。
6. Congestion MUST be indicated if the Status Feedback PDUs indicate that either sequence number anomalies were detected OR the delay range was above the upper delay variation threshold. The RECOMMENDED threshold values are 10 for sequence number gaps, 30 ms for lower delay variation thresholds, and 90 ms for upper delay variation thresholds.
6. ステータスフィードバック PDU が、シーケンス番号の異常が検出されたか、遅延範囲が遅延変動上限閾値を超えていたことを示す場合、輻輳を示さなければなりません (MUST)。推奨されるしきい値は、シーケンス番号ギャップの場合は 10、下位の遅延変動しきい値の場合は 30 ミリ秒、上位の遅延変動しきい値の場合は 90 ミリ秒です。
7. The load rate adjustment algorithm MUST include a Load PDU timeout and a Status PDU timeout, which both stop the test when received PDU streams cease unexpectedly.
7. 負荷率調整アルゴリズムには、Load PDU タイムアウトと Status PDU タイムアウトを含めなければなりません (MUST)。これらは両方とも、受信した PDU ストリームが予期せず停止した場合にテストを停止します。
8. The Load PDU timeout SHALL be reset to the configured value each time a Load PDU is received. If the Load PDU timeout expires, the receiver SHALL be closed and no further Status PDU feedback sent. The default Load PDU timeout MUST be no more than 1 second.
8. Load PDU タイムアウトは、Load PDU を受信するたびに設定された値にリセットされるものとします (SHALL)。Load PDU タイムアウトが経過した場合、受信機は閉じられ、それ以上ステータス PDU フィードバックは送信されないものとします (SHALL)。デフォルトの Load PDU タイムアウトは 1 秒以下でなければなりません。
9. The Status PDU timeout SHALL be reset to the configured value each time a feedback message is received. If the Status PDU timeout expires, the sender SHALL be closed and no further load packets sent. The default Status PDU timeout MUST be no more than 1 second.
9. ステータス PDU タイムアウトは、フィードバック メッセージが受信されるたびに、設定された値にリセットされるものとします (SHALL)。Status PDU タイムアウトが経過した場合、送信者は閉じられ、それ以上ロード パケットは送信されないものとします(SHALL)。デフォルトのステータス PDU タイムアウトは 1 秒以下でなければなりません。
10. A network operator who is certain of the IP-Layer Capacity to be validated MAY start with a fixed-rate test at the IP-Layer Capacity and avoid activating the measurement load rate adjustment algorithm (see Section 8.1 of [RFC9097]). However, the stimulus for a diagnostic test (such as a subscriber request) strongly implies that there is no certainty, and the load adjustment algorithm is RECOMMENDED.
10. IP 層キャパシティが検証されることを確信しているネットワークオペレータは、IP 層キャパシティでの固定レートテストから開始し、測定負荷率調整アルゴリズムのアクティブ化を回避してもよい(MAY) ([RFC9097] のセクション 8.1 を参照)。ただし、診断テストの刺激 (加入者リクエストなど) は確実性がないことを強く示唆しており、負荷調整アルゴリズムが推奨されます。
11. This specification MUST only be used in circumstances consistent with Section 10 (Security Considerations) of [RFC9097].
11. この仕様は、[RFC9097] のセクション 10 (セキュリティに関する考慮事項) と一致する状況でのみ使用しなければなりません (MUST)。
12. Further measurement load rate adjustment algorithm requirements are specified by [RFC9097].
12. さらなる測定負荷率調整アルゴリズム要件は [RFC9097] で指定されています。
The following measurement load rate adjustment algorithms are subject to these requirements:
次の測定負荷率調整アルゴリズムには、次の要件が適用されます。
* Measurement load rate adjustment algorithm B [Y.1540Amd2].
* 測定負荷率調整アルゴリズム B [Y.1540Amd2]。
* Measurement load rate adjustment algorithm C [TR-471].
* 測定負荷率調整アルゴリズムC [TR-471]。
Please refer to Section 4 of [RFC9097] for an overview of parameters related to the Maximum IP-Layer Capacity Metric and Method. A set of error codes to support debugging are provided in Section 12.3.5.
最大 IP 層容量のメトリクスと方法に関連するパラメータの概要については、[RFC9097] のセクション 4 を参照してください。デバッグをサポートするための一連のエラー コードは、セクション 12.3.5 に記載されています。
There are two security modes of operation that perform authentication of the client/server messaging. The two modes are:
クライアント/サーバー メッセージングの認証を実行する 2 つのセキュリティ動作モードがあります。2 つのモードは次のとおりです。
1. A REQUIRED mode with authentication during the Control phase (Test Setup and Test Activation exchanges). This mode may be preferred for large-scale servers or low-end client devices where processing power is a consideration (see Section 3).
1. 制御フェーズ (テスト セットアップおよびテスト アクティベーション交換) での認証を伴う必須モード。このモードは、処理能力が考慮される大規模サーバーまたはローエンド クライアント デバイスに適しています (セクション 3 を参照)。
2. An OPTIONAL mode with the additional authentication of the Status Feedback messages during the Data phase. This mode may be preferred for environments that desire an additional level of message integrity verification throughout the test (see Section 3).
2. データフェーズ中のステータスフィードバックメッセージの追加認証を備えたオプションモード。このモードは、テスト全体を通じて追加レベルのメッセージ完全性検証を必要とする環境に適しています (セクション 3 を参照)。
The requirements discussed hereafter refer to the PDUs in Sections 6 and 7 below, primarily the authMode, keyId, authUnixTime, and authDigest fields. 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 by other sections within this document. Each successive mode increases security but comes with additional performance impacts and complexity. The protocol is used with unsubstantial payload, and it may operate on very low-end devices. Offering the flexibility of various security operation modes allows for accommodation of available end-device resources. In general, an active measurement technique as the one defined by this document is better suited to protect the privacy of those involved in measurements [RFC7594].
これ以降で説明する要件は、以下のセクション 6 および 7 の PDU、主に authMode、keyId、authUnixTime、および authDigest フィールドを参照します。このセクションの役割は一般化されており、PDU の送信者と受信者の要件をこのドキュメント内の他のセクションで再利用および参照できるようにしています。連続する各モードではセキュリティが強化されますが、パフォーマンスへの影響と複雑さがさらに増します。このプロトコルは実質的ではないペイロードで使用され、非常にローエンドのデバイスで動作する可能性があります。さまざまなセキュリティ操作モードの柔軟性を提供することで、利用可能なエンドデバイス リソースに対応できます。一般に、この文書で定義されているようなアクティブな測定技術は、測定に関与する人のプライバシーを保護するのに適しています [RFC7594]。
A load rate adjustment method needs to satisfy the requirements listed in Section 5.1. This is necessary also to avoid potentially inducing congestion after there is an overload or loss (including loss on the control path).
負荷率の調整方法は、5.1 項に記載の要件を満たす必要があります。これは、過負荷または損失（制御パス上の損失を含む）が発生した後に輻輳を引き起こす可能性を回避するためにも必要です。
In this mode, the client and the server SHALL be configured to use one of a number of shared secret keys, designated via the numeric keyId field (see Section 5.4). This key SHALL be used as input to the KDF, as specified in Section 5.4.1, to obtain the actual keys used by the client and server for authentication.
このモードでは、クライアントとサーバーは、数値 keyId フィールドで指定された多数の共有秘密鍵の 1 つを使用するように構成されなければなりません (セクション 5.4 を参照)。この鍵は、セクション 5.4.1 で指定されているように、クライアントとサーバーが認証に使用する実際の鍵を取得するために、KDF への入力として使用されるものとします (SHALL)。
During the Control phase, the sender SHALL read the current system (wall-clock) time and populate the authUnixTime field and next calculate the 32-octet HMAC-SHA-256 hash of the entire PDU according to Section 6 of [RFC6234] (with the authDigest and checkSum preset to all zeroes). The authDigest field is filled by the result, then the packet is sent to the receiver. The value in the authUnixTime field is a 32-bit timestamp, and a 10-second tolerance window (+/- 5 seconds) SHALL be used by the receiver to distinguish a subsequent replay of a PDU. See Table 2 of [TR-471] for a recommended timestamp resolution.
制御フェーズ中、送信者は現在のシステム（実時間）時刻を読み取り、authUnixTime フィールドに値を設定し、次に [RFC6234] のセクション 6 に従って PDU 全体の 32 オクテットの HMAC-SHA-256 ハッシュを計算するものとします（authDigest と checkSum はすべて 0 にプリセットされています）。authDigest フィールドに結果が入力され、パケットが受信者に送信されます。authUnixTime フィールドの値は 32 ビットのタイムスタンプであり、受信側は後続の PDU の再生を区別するために 10 秒の許容範囲 (+/- 5 秒) を使用する必要があります (SHALL)。推奨されるタイムスタンプ解像度については、[TR-471] の表 2 を参照してください。
Upon reception, the receiver SHALL validate the message PDU for correct length, validity of authDigest, immediacy of authUnixTime, and expected formatting (PDU-specific fields are also checked, such as protocol version). Validation of the authDigest requires that it be extracted from the PDU and the field, along with the checkSum field, zeroed prior to the Hashed Message Authentication Code (HMAC) calculation used for comparison (see Section 7.2 of [RFC9145]).
受信時に、受信者はメッセージ PDU が正しい長さ、authDigest の有効性、authUnixTime の即時性、および予期されるフォーマットであることを検証するものとします (プロトコル バージョンなどの PDU 固有のフィールドもチェックされます)。authDigest の検証では、authDigest が PDU から抽出され、比較に使用されるハッシュ メッセージ認証コード (HMAC) 計算の前に checkSum フィールドとともにゼロ化される必要があります ([RFC9145] のセクション 7.2 を参照)。
If the validation fails, the receiver SHOULD NOT continue with the Control phase and SHOULD implement silent rejection (no further packets sent on the address/port pairs). The exception is when the testing hosts have been configured for troubleshooting Control phase failures and rejection messages will aid in the process.
検証が失敗した場合、受信者は制御フェーズを続行すべきではなく、サイレント拒否を実装すべきです(アドレス/ポートのペアでそれ以上パケットを送信しない)。例外は、テスト ホストがトラブルシューティング用に構成されている場合です。制御フェーズの失敗と拒否メッセージがプロセスに役立ちます。
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 (if any).
検証が成功した場合、受信者は制御フェーズを続行し、成功応答または識別されたエラー状態(存在する場合)を示す応答を作成するものとします(SHALL)。
This process SHALL be executed for the request and response in the Test Setup exchange, including the Null Request (Section 6) and the Test Activation exchange (Section 7).
このプロセスは、Null リクエスト (セクション 6) とテスト アクティベーション交換 (セクション 7) を含む、テスト セットアップ交換のリクエストと応答に対して実行されるものとします(SHALL)。
This mode incorporates Authenticated mode 1. When using the optional authentication during the Data phase, authentication SHALL also be applied to the Status Feedback PDU (see Section 8.2). The client sends the Status PDU in a downstream test, and the server sends it in an upstream test.
このモードには認証モード 1 が組み込まれています。データフェーズ中にオプションの認証を使用する場合、認証はステータス フィードバック PDU にも適用されるものとします (セクション 8.2 を参照)。クライアントはダウンストリーム テストでステータス PDU を送信し、サーバーはアップストリーム テストでステータス PDU を送信します。
The Status PDU sender SHALL 1) read the current system (wall-clock) time and populate the authUnixTime field, 2) calculate the authDigest field of the entire Status PDU (with the authDigest and checkSum preset to all zeroes), and 3) send the packet to the receiver. The values of authUnixTime field and authDigest field are determined as defined by Section 5.3.1.
Status PDU 送信者は、1) 現在のシステム (壁時計) 時間を読み取り、authUnixTime フィールドに値を設定し、2) Status PDU 全体の authDigest フィールドを計算し (authDigest と checkSum をすべて 0 にプリセットして)、3) パケットを受信者に送信するものとします(SHALL)。authUnixTime フィールドと authDigest フィールドの値は、セクション 5.3.1 の定義に従って決定されます。
Upon reception, the receiver SHALL validate the message PDU for correct length, validity of authDigest, immediacy of authUnixTime, and expected formatting (PDU-specific fields are also checked, such as protocol version). Validation of the authDigest will require that it be extracted from the PDU and the field, along with the checkSum field, zeroed prior to the HMAC calculation used for comparison.
受信時に、受信者はメッセージ PDU が正しい長さ、authDigest の有効性、authUnixTime の即時性、および予期されるフォーマットであることを検証するものとします (プロトコル バージョンなどの PDU 固有のフィールドもチェックされます)。authDigest を検証するには、それが PDU から抽出され、比較に使用される HMAC 計算の前に checkSum フィールドとともにゼロ化される必要があります。
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 (and no further load traffic SHALL be transmitted). This is necessary also to avoid potentially inducing congestion after there is an overload or loss on the control path.
認証の検証が失敗した場合、受信者はメッセージを無視するものとします(SHALL)。ウォッチドッグ タイマーが期限切れになった場合 (検証が連続して失敗したため)、テスト セッションは途中で終了します (これ以上の負荷トラフィックは送信されません)。これは、制御パスに過負荷または損失が発生した後に輻輳が誘発される可能性を回避するためにも必要です。
If this optional mode has not been selected, then the keyId, authUnixTime, and authDigest fields of the Status PDU (see Section 8.2) SHALL be set to all zeroes.
このオプションのモードが選択されていない場合、Status PDU (セクション 8.2 を参照) の keyId、authUnixTime、および authDigest フィールドはすべて 0 に設定されるものとします (SHALL)。
Section 2 of [RFC7210] specifies a conceptual database for long-lived cryptographic keys. The key table SHALL be used with the REQUIRED authentication mode and the OPTIONAL authentication mode (using the same key). For authentication, this key SHALL only be used as input to the KDF, as specified in Section 5.4.1, to derive the actual keys used for authentication processing. Key rotation and related management specifics are beyond the scope of this document.
[RFC7210] のセクション 2 では、有効期間の長い暗号鍵の概念データベースを指定しています。キーテーブルは、REQUIRED 認証モードと OPTIONAL 認証モード (同じキーを使用) で使用されるものとします(SHALL)。認証の場合、この鍵は、セクション 5.4.1 で指定されているように、認証処理に使用される実際の鍵を導出するために KDF への入力としてのみ使用されるものとします (SHALL)。キーのローテーションと関連する管理の詳細については、このドキュメントの範囲外です。
The key table SHALL have (at least) the following fields per Section 2 of [RFC7210]:
キーテーブルには、[RFC7210] のセクション 2 に従って、(少なくとも) 以下のフィールドがなければなりません (SHALL)。
* AdminKeyName
* 管理者キー名
* LocalKeyName
* ローカルキー名
* KDF
* KDF
* AlgID
* AlgID
* Key
* 鍵
* SendLifetimeStart
* SendLifetimeStart
* SendLifeTimeEnd
* ライフタイムエンドの送信
* AcceptLifeTimeStart
* AcceptLifeTimeStart
* AcceptLifeTimeEnd
* ライフタイムエンドを受け入れる
The LocalKeyName SHALL be determined from the corresponding keyId field in the PDUs that follow.
LocalKeyName は、後続の PDU の対応する keyId フィールドから決定されるものとします (SHALL)。
A KDF is a one-way function that provides cryptographic separation of key material. The protocol requires a KDF to securely derive cryptographic keys used for authentication of protocol messages. The inclusion of a KDF ensures that keys are generated in a standardized, cryptographically secure manner, reducing the risk of key compromise and enabling interoperability across implementations. The benefits of using a KDF include:
KDF は、キーマテリアルの暗号分離を提供する一方向関数です。このプロトコルでは、KDF がプロトコル メッセージの認証に使用される暗号キーを安全に導出する必要があります。KDF を組み込むことで、キーが標準化された暗号的に安全な方法で生成されることが保証され、キー侵害のリスクが軽減され、実装間の相互運用性が可能になります。KDF を使用する利点は次のとおりです。
* Security: A KDF produces keys with high entropy, resistant to brute-force and related-key attacks, ensuring robust protection for protocol communications.
* セキュリティ: KDF は、ブルート フォース攻撃や関連キー攻撃に耐性のある高エントロピーのキーを生成し、プロトコル通信の堅牢な保護を保証します。
* Flexibility: The KDF allows derivation of multiple keys from a single shared secret, supporting distinct keys for client and server authentication.
* 柔軟性: KDF では、単一の共有シークレットから複数のキーを導出でき、クライアントとサーバーの認証用に個別のキーをサポートします。
* Standardization: By adhering to established cryptographic standards, the KDF ensures compatibility with existing security frameworks and facilitates implementation audits.
* 標準化: KDF は確立された暗号化標準に準拠することで、既存のセキュリティ フレームワークとの互換性を確保し、実装監査を容易にします。
* Efficiency: The KDF enables efficient key generation without requiring additional key exchange mechanisms, minimizing protocol overhead.
* 効率: KDF により、追加の鍵交換メカニズムを必要とせずに効率的な鍵生成が可能になり、プロトコルのオーバーヘッドが最小限に抑えられます。
The KDF algorithm SHALL be a Key Derivation Function in Counter Mode, as specified in Section 4.1 of [NIST800-108]. This algorithm uses a counter-based mechanism to generate key material from a shared secret, ensuring deterministic and secure key derivation. The Pseudorandom Function (PRF) used in the KDF SHALL be HMAC-SHA-256, as defined in Section 6 of [RFC6234]. IANA has assigned "HMAC-SHA-256" as a new KeyTable KDF (Section 12.2).
KDF アルゴリズムは、[NIST800-108] のセクション 4.1 で指定されているように、カウンター モードの鍵導出関数であるものとします (SHALL)。このアルゴリズムは、カウンターベースのメカニズムを使用して共有シークレットからキーマテリアルを生成し、決定論的で安全なキー導出を保証します。KDF で使用される擬似乱数関数 (PRF) は、[RFC6234] のセクション 6 で定義されているように、HMAC-SHA-256 でなければなりません (SHALL)。IANA は、新しい KeyTable KDF として「HMAC-SHA-256」を割り当てました (セクション 12.2)。
The KDF SHALL use the following parameters:
KDF は次のパラメータを使用するものとします(SHALL)。
* Kin (key-derivation key): The shared key as identified by the keyId field in the PDU.
* Kin (キー導出キー): PDU の keyId フィールドによって識別される共有キー。
* Label: The fixed string "UDPSTP" (without quotes), encoded as a UTF-8 string, used to bind the derived keys to this specific protocol.
* ラベル: UTF-8 文字列としてエンコードされた固定文字列「UDPSTP」(引用符なし)。派生キーをこの特定のプロトコルにバインドするために使用されます。
* Context: The UTF-8 string representation of the authUnixTime field received in the very first Setup Request PDU sent from the client to the server. This ensures that the derived keys are unique to the session and tied to the temporal context of the initial setup exchange. The authUnixTime field serves as a nonce and is protected from modification by the HMAC-SHA-256 hash present in the authDigest field.
* コンテキスト: クライアントからサーバーに送信された最初のセットアップ要求 PDU で受信された authUnixTime フィールドの UTF-8 文字列表現。これにより、派生キーがセッションに固有であり、初期セットアップ交換の時間的コンテキストに関連付けられることが保証されます。authUnixTime フィールドは nonce として機能し、authDigest フィールドに存在する HMAC-SHA-256 ハッシュによる変更から保護されています。
* r: The length of the binary encoding of the counter SHALL be 32 (bits).
* r: カウンタのバイナリエンコーディングの長さは 32 (ビット) とする。
The total derived key material SHALL be 512 bits (64 octets) in length. The key material SHALL be structured as follows, from most significant bit (MSB) to least significant bit (LSB):
派生鍵マテリアルの合計の長さは 512 ビット (64 オクテット) でなければなりません。鍵マテリアルは、最上位ビット (MSB) から最下位ビット (LSB) まで、次のように構造化されているものとします。
* Client Authentication Key: 256 bits (32 octets); used for authenticating messages sent by the client.
* クライアント認証キー: 256 ビット (32 オクテット)。クライアントによって送信されたメッセージを認証するために使用されます。
* Server Authentication Key: 256 bits (32 octets); used for authenticating messages sent by the server.
* サーバー認証キー: 256 ビット (32 オクテット)。サーバーによって送信されたメッセージを認証するために使用されます。
This structure ensures that the derived keys are sufficient for securing authentication operations within the protocol, while maintaining clear separation of function and directionality.
この構造により、機能と方向性の明確な分離を維持しながら、派生キーがプロトコル内の認証操作を保護するのに十分であることが保証されます。
If authentication of the initial Setup Request PDU received by the server fails, due to an invalid authDigest field, any and all derived keying material and keys SHALL be considered invalid.
無効な authDigest フィールドにより、サーバーが受信した最初の Setup Request PDU の認証が失敗した場合、派生したすべての鍵マテリアルと鍵は無効であるとみなされるものとします(SHALL)。
The key material derived from the initial Setup Request PDU, either at the client prior to transmission or at the server upon reception, SHALL be used for all subsequent PDUs sent between them for that test connection. As such, the KDF is only required to be executed once by the client and server for each test connection.
最初の Setup Request PDU から導出されたキーマテリアルは、送信前のクライアントまたは受信時のサーバーのいずれかで、そのテスト接続のためにクライアント間で送信される後続のすべての PDU に使用されるものとします (SHALL)。そのため、KDF は、テスト接続ごとにクライアントとサーバーによって 1 回だけ実行する必要があります。
Appendix A, Figure 12 provides a code snippet demonstrating derivation of the specified keys from key material using the OpenSSL cryptographic library, specifically the high-level Key-Based EVP_KDF implementation (Key-Based Envelope Key Derivation Function); see [EVP_KDF-KB] for details.
付録 A の図 12 は、OpenSSL 暗号化ライブラリ、特に高レベルのキーベースの EVP_KDF 実装 (キーベースのエンベロープキー導出関数) を使用してキーマテリアルから指定されたキーを導出するコード スニペットを示しています。詳細については、[EVP_KDF-KB] を参照してください。
Successful interaction with a local firewall assumes the firewall is configured to allow a host to open a bidirectional connection using unique source and destination addresses as well as port numbers (i.e., a 4-tuple) by sending a packet using that 4-tuple for a given transport protocol. The client's interaction with its firewall depends on this configuration.
ローカル ファイアウォールとの対話が成功するには、ホストが特定のトランスポート プロトコルの 4 タプルを使用してパケットを送信することにより、一意の送信元アドレスと宛先アドレス、およびポート番号 (つまり 4 タプル) を使用して双方向接続を開くことができるようにファイアウォールが設定されていることを前提としています。クライアントとそのファイアウォールとの対話は、この構成に依存します。
The firewall at the server MUST be configured with an open pinhole for the server IP address and standard UDP port number of the server. All messages sent by the client to the server use this standard UDP port number.
サーバーのファイアウォールは、サーバーの IP アドレスとサーバーの標準 UDP ポート番号に対してオープン ピンホールを使用して構成する必要があります。クライアントからサーバーに送信されるすべてのメッセージは、この標準の UDP ポート番号を使用します。
The server uses one ephemeral UDP port number per test connection. Assuming that the firewall administration at the server does not allow an open UDP ephemeral port range, then the server MUST send a Null Request to the client from the ephemeral port number communicated to the client in the Test Setup Response. The Null Request may not reach the client: it may be discarded by the client's firewall.
サーバーは、テスト接続ごとに 1 つの一時的な UDP ポート番号を使用します。サーバーのファイアウォール管理がオープンな UDP 一時ポート範囲を許可しないと仮定すると、サーバーは、テスト セットアップ応答でクライアントに通知された一時ポート番号からクライアントに Null 要求を送信しなければなりません (MUST)。Null リクエストはクライアントに届かない可能性があります。クライアントのファイアウォールによって破棄される可能性があります。
If the server firewall administration allows an open UDP ephemeral port range, then the Null Request is not strictly necessary. However, the availability of an open port range policy cannot be assumed.
サーバーのファイアウォール管理がオープンな UDP 一時ポート範囲を許可している場合、Null 要求は厳密には必要ありません。ただし、オープン ポート範囲ポリシーが利用できるかどうかは想定できません。
Network Address Translators (NATs) are expected to offer support of a wider set of operational configurations as compared to firewalls. Specifications covering NAT behavior, apart from the above, are out of the scope of this document, as are combined implementations of NAT and firewalls too.
ネットワーク アドレス トランスレータ (NAT) は、ファイアウォールと比較して、より広範な運用構成のサポートを提供することが期待されています。上記以外の NAT の動作に関する仕様は、NAT とファイアウォールの組み合わせ実装と同様に、このドキュメントの範囲外です。
The protocol MUST utilize the standard UDP checksum for all IPv4 and IPv6 datagrams it sends. The purpose of this checksum is to protect the intended recipient as well as other recipients to whom a corrupted packet may be delivered. This provides:
プロトコルは、送信するすべての IPv4 および IPv6 データグラムに対して標準の UDP チェックサムを利用しなければなりません (MUST)。このチェックサムの目的は、意図した受信者だけでなく、破損したパケットが配信される可能性のある他の受信者を保護することです。これにより、以下が提供されます。
* Protection of the endpoint transport state from unnecessary extra state (e.g., Invalid state from rogue packets).
* エンドポイントのトランスポート状態を不要な余分な状態（不正なパケットからの無効な状態など）から保護します。
* Protection of the endpoint transport state from corruption of internal state.
* 内部状態の破損からエンドポイントのトランスポート状態を保護します。
* Pre-filtering by the endpoint of erroneous data, to protect the transport from unnecessary processing and from corruption that it cannot itself reject.
* 誤ったデータのエンドポイントによる事前フィルタリングにより、トランスポートを不必要な処理や、トランスポート自体が拒否できない破損から保護します。
* Pre-filtering of incorrectly addressed destination packets, before responding to a source address.
* 送信元アドレスに応答する前に、誤ってアドレス指定された宛先パケットを事前にフィルタリングします。
All of the PDUs exchanged between the client and server support an optional header checksum that covers the various fields in the UDPSTP PDU (excluding the payload content of the Load PDU and, to be clear, also the IP and UDP headers). The calculation is the same as the 16-bit one's complement Internet checksum used in the IPv4 packet Header Checksum specification (see Section 3.1 of [RFC0791]). This checksum is intended for environments where UDP data integrity may be uncertain. This includes situations where the standard UDP checksum is not verified upon reception or a nonstandard network API is in use (things typically done to improve performance on low-end devices). However, all UDPSTP datagrams transmitted via IPv4 or IPv6 SHALL include a standard UDP checksum to protect other potential recipients to whom a corrupted packet may be delivered. In the case of a nonstandard network API, one option to reduce processing overhead may be to restrict testing to only utilize a payload content of all zeros so that the UDP checksum calculation need not include it for Load PDUs.
クライアントとサーバー間で交換されるすべての PDU は、UDPSTP PDU のさまざまなフィールドをカバーするオプションのヘッダー チェックサムをサポートしています (Load PDU のペイロード コンテンツと、明確に言うと、IP ヘッダーと UDP ヘッダーも除きます)。この計算は、IPv4 パケットのヘッダー チェックサム仕様で使用される 16 ビットの 1 の補数インターネット チェックサムと同じです ([RFC0791] のセクション 3.1 を参照)。このチェックサムは、UDP データの整合性が不確実な可能性がある環境を対象としています。これには、標準の UDP チェックサムが受信時に検証されない状況や、非標準のネットワーク API が使用されている状況 (通常、ローエンド デバイスのパフォーマンスを向上させるために行われる) が含まれます。ただし、IPv4 または IPv6 経由で送信されるすべての UDPSTP データグラムには、破損したパケットが配信される可能性のある他の潜在的な受信者を保護するために、標準の UDP チェックサムが含まれているものとします (SHALL)。非標準ネットワーク API の場合、処理オーバーヘッドを削減する 1 つのオプションは、テストをすべてゼロのペイロード コンテンツのみを利用するように制限し、UDP チェックサム計算にロード PDU のペイロード コンテンツを含める必要がないようにすることです。
If a PDU sender is populating the checkSum field, it SHALL do so as the last step after the PDU is built in all other respects (with the checkSum field set to zero prior to the calculation). The PDU receiver SHALL subsequently verify the PDU checksum whenever checksum processing has been configured and the field is populated. If PDU checksum validation fails, the PDU SHALL be discarded.
PDU 送信者が checkSum フィールドに値を設定する場合、他のすべての点で PDU が構築された後の最後のステップとしてこれを行うものとします (計算前に checkSum フィールドをゼロに設定します)。PDU 受信者は、その後、チェックサム処理が設定され、フィールドが設定されるたびに、PDU チェックサムを検証するものとします(SHALL)。PDU チェックサムの検証が失敗した場合、PDU は破棄されるものとします (SHALL)。
Because of the redundancy when used in conjunction with authentication, it is OPTIONAL for a PDU sender to utilize the UDPSTP checkSum field. However, because authentication is not applicable to the Load PDU, the checkSum field SHALL be utilized by the sender whenever UDP data integrity may be uncertain (as outlined above).
認証と併用すると冗長性が得られるため、PDU 送信者が UDPSTP checkSum フィールドを利用することはオプションです。ただし、認証は Load PDU には適用できないため、(上で概説したように) UDP データの整合性が不確実な可能性がある場合には、送信者は checkSum フィールドを利用するものとします(SHALL)。
The client source IP address and the server destination IP address MUST NOT be a broadcast or multicast address. Any Test Setup Request or Test Setup Response packet containing a multicast or broadcast source or destination IP address MUST be silently dropped and ignored.
クライアントの送信元 IP アドレスとサーバーの宛先 IP アドレスは、ブロードキャスト アドレスまたはマルチキャスト アドレスであってはなりません。マルチキャストまたはブロードキャストの送信元または宛先 IP アドレスを含むテスト セットアップ要求またはテスト セットアップ応答パケットは、サイレントにドロップされ、無視されなければなりません (MUST)。
The measurement method and the protocol specified by this document are expected to function with unicast and anycast IP addresses.
この文書で指定された測定方法とプロトコルは、ユニキャストおよびエニーキャスト IP アドレスで機能することが期待されます。
The client SHALL begin the Control phase exchange by sending a Test Setup Request message to the server's (standard) control port. This standard UDPSTP port number is utilized for each connection of a multi-connection test.
クライアントは、サーバーの（標準）制御ポートにテストセットアップ要求メッセージを送信することによって、制御フェーズ交換を開始するものとします（SHALL）。この標準の UDPSTP ポート番号は、多重接続テストの各接続に使用されます。
The client SHALL simultaneously start a test initiation timer so that if the Control phase fails to complete Test Setup and Test Activation exchanges in the allocated time, the client software SHALL exit (i.e., the UDP socket will be closed and an error message will be displayed to the user). Lost messages result in a Test Setup and Test Activation failure. The test initiation timer MAY reuse the test termination timeout value.
クライアントは、割り当てられた時間内に制御フェーズがテストセットアップとテストアクティベーションの交換を完了できなかった場合、クライアントソフトウェアが終了するように、テスト開始タイマーを同時に開始するものとします(SHALL)(つまり、UDPソケットが閉じられ、エラーメッセージがユーザーに表示されます)。メッセージが失われると、テスト セットアップとテスト アクティベーションが失敗します。テスト開始タイマーは、テスト終了タイムアウト値を再利用してもよい(MAY)。
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.
ウォッチドッグ タイムアウトは、受信トラフィックが停止したことを示す警告メッセージをトリガーするために 1 秒間隔として設定されます。テスト終了タイムアウトはウォッチドッグ間隔に基づいており、非正常終了をトリガーする前にさらに 2 秒の待機時間を実装します。
Note: Any field labeled as 'reserved for alignment', in any PDU, MUST be set to 0 and MUST be ignored upon receipt.
注: PDU 内の「アライメント用に予約」とラベル付けされたフィールドはすべて 0 に設定しなければならず、受信時に無視しなければなりません。
The UDP PDU format layout SHALL be as follows (big-endian AB, starting with the most significant byte and ending with the least significant byte):
UDP PDU フォーマットのレイアウトは次のようにするものとします (ビッグエンディアン 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pduId | protocolVer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mcIndex | mcCount | mcIdent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmdRequest | cmdResponse | maxBandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| testPort |modifierBitmap | authMode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authUnixTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. authDigest (32 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| keyId | reservedAuth1 | checkSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Test Setup PDU Layout
図 2: テスト セットアップ PDU のレイアウト
Additional details regarding the Setup Request and Response fields are as follows:
Setup Request および Response フィールドに関する追加の詳細は次のとおりです。
pduId:
pduId:
A two-octet field. IANA has assigned the hex value 0xACE1 (Section 12.3.1).
2 オクテットのフィールド。IANA は 16 進値 0xACE1 を割り当てました (セクション 12.3.1)。
protocolVer:
プロトコルVer:
A two-octet field identifying the actual protocol version. IANA has assigned 20 as the value (Section 12.3.2).
実際のプロトコルのバージョンを識別する 2 オクテットのフィールド。IANA は値として 20 を割り当てました (セクション 12.3.2)。
mcIndex:
マックインデックス:
A one-octet field indicating the index of a connection relative to all connections that make up a single test (starting at 0, incremented by 1 per connection). It is used to differentiate separate connections within a multi-connection test. An implementation may restrict the number of connections supported for a single test to a value less than or equal to 255.
単一のテストを構成するすべての接続に対する接続のインデックスを示す 1 オクテットのフィールド (0 から始まり、接続ごとに 1 ずつ増加します)。これは、複数接続テスト内で個別の接続を区別するために使用されます。実装によっては、1 つのテストでサポートされる接続の数が 255 以下の値に制限される場合があります。
mcCount:
マックカウント:
A one-octet field indicating the total count of connections that the client is attempting to set up.
クライアントがセットアップしようとしている接続の総数を示す 1 オクテットのフィールド。
mcIdent:
マックアイデント:
A two-octet field containing a pseudorandom non-zero identifier (via a Random Number Generator, source port number, ...) that is common to all connections of a single test. It is used by clients/servers to associate separate connections with a single multi-connection test.
1 つのテストのすべての接続に共通する、ゼロ以外の擬似乱数識別子 (乱数ジェネレーター、送信元ポート番号などを介した) を含む 2 オクテットのフィールド。これは、個別の接続を単一の複数接続テストに関連付けるためにクライアント/サーバーによって使用されます。
cmdRequest:
cmdRequest:
A one-octet field set to CHSR_CREQ_SETUPREQ to indicate a Setup Request message. Note that CHSR_CREQ_NONE remains unused.
セットアップ要求メッセージを示すために CHSR_CREQ_SETUPREQ に設定される 1 オクテットのフィールド。CHSR_CREQ_NONE は未使用のままであることに注意してください。
cmdResponse:
cmdResponse:
A one-octet field. All Request PDUs always have a Command Response of XXXX_CRSP_NONE (i.e., CHSR_CRSP_NONE, CHNR_CRSP_NONE, or CHTA_CRSP_NONE).
1 オクテットのフィールド。すべてのリクエスト PDU は常に XXXX_CRSP_NONE (つまり、CHSR_CRSP_NONE、CHNR_CRSP_NONE、または CHTA_CRSP_NONE) のコマンド応答を持ちます。
maxBandwidth:
最大帯域幅:
A two-octet field. A non-zero value of this field specifies the maximum bit rate the client expects to send or receive during the requested test in Mbps. The server compares this value to its currently available configured limit for test admission control. This field MAY be used to rate-limit the maximum rate the server should attempt. The maxBandwidth field's most significant bit, the CHSR_USDIR_BIT, is set to 0 by default to indicate "downstream" and has to be set to 1 to indicate "upstream".
2 オクテットのフィールド。このフィールドのゼロ以外の値は、要求されたテスト中にクライアントが送受信すると予想される最大ビット レートを Mbps 単位で指定します。サーバーは、この値を、テスト アドミッション コントロールに対して現在利用可能な設定済みの制限と比較します。このフィールドは、サーバーが試行すべき最大レートをレート制限するために使用してもよい(MAY)。maxBandwidth フィールドの最上位ビットである CHSR_USDIR_BIT は、「ダウンストリーム」を示すにはデフォルトで 0 に設定され、「アップストリーム」を示すには 1 に設定する必要があります。
testPort:
テストポート:
A two-octet field set to zero in the Test Setup Request and populated by the server in the Test Setup Response. It contains the UDP ephemeral port number on the server that the client has to use for the Test Activation Request and subsequent Load or Status PDUs.
テスト セットアップ要求でゼロに設定され、サーバーによってテスト セットアップ応答で設定される 2 オクテットのフィールド。これには、クライアントがテスト アクティベーション要求および後続のロード PDU またはステータス PDU に使用する必要があるサーバー上の UDP 一時ポート番号が含まれています。
modifierBitmap:
修飾子ビットマップ:
A one-octet field. This document only assigns two bits in this bitmap; see Section 12.3.3:
1 オクテットのフィールド。このドキュメントでは、このビットマップに 2 つのビットのみを割り当てます。セクション12.3.3を参照してください。
CHSR_JUMBO_STATUS (0x01):
CHSR_JUMBO_STATUS (0x01):
This bit SHALL be set by default. By default, sending rates up to 1 Gbps SHALL NOT produce IP packet sizes greater than 1250 bytes (unless CHSR_TRADITIONAL_MTU is set), while rates above 1 Gbps MAY produce IP packet sizes up to 9000 bytes. When CHSR_JUMBO_STATUS is not set, all sending rates SHALL NOT produce IP packet sizes greater than 1250 bytes (unless CHSR_TRADITIONAL_MTU is set).
このビットはデフォルトで設定されるものとします(SHALL)。デフォルトでは、最大 1 Gbps の送信速度では、1250 バイトを超える IP パケット サイズが生成されません (SHALL NOT) (CHSR_TRADITIONAL_MTU が設定されている場合を除く)。一方、1 Gbps を超える送信速度では、最大 9000 バイトの IP パケット サイズが生成されてもよい(MAY)。CHSR_JUMBO_STATUS が設定されていない場合、(CHSR_TRADITIONAL_MTU が設定されていない限り) すべての送信レートで 1250 バイトを超える IP パケット サイズが生成されてはなりません (SHALL NOT)。
CHSR_TRADITIONAL_MTU (0x02):
CHSR_TRADITIONAL_MTU (0x02):
This bit SHALL NOT be set by default. If set, sending rates up to 1 Gbps MAY produce IP packets up to the traditional size of 1500 bytes. If CHSR_JUMBO_STATUS is simultaneously not set, all sending rates SHALL NOT produce IP packets greater than the traditional size of 1500 bytes.
このビットはデフォルトでは設定しないでください。設定されている場合、最大 1 Gbps の送信速度で、最大 1500 バイトの従来のサイズの IP パケットを生成できます。CHSR_JUMBO_STATUS が同時に設定されていない場合、すべての送信レートは、従来のサイズの 1500 バイトを超える IP パケットを生成してはなりません (SHALL NOT)。
Other bit positions are left unassigned per this document.
このドキュメントに従って、他のビット位置は割り当てられないままになります。
authMode:
認証モード:
A one-octet field. The authMode field currently has two values assigned (see Section 12.3.4). One of the following has to be set (see Section 5.3 for requirements and details of operation):
1 オクテットのフィールド。authMode フィールドには現在 2 つの値が割り当てられています (セクション 12.3.4 を参照)。次のいずれかを設定する必要があります (要件と操作の詳細については、セクション 5.3 を参照してください)。
AUTHMODE_1:
認証モード_1:
Required authentication for the Control phase.
制御フェーズに必要な認証。
AUTHMODE_2:
認証モード_2:
Required authentication for the Control and Data phases (Status Feedback PDU only).
制御フェーズとデータ フェーズに必要な認証 (ステータス フィードバック PDU のみ)。
A range of 60 through 63 is reserved for experimentation. IANA has created the "Test Setup PDU Authentication Mode" registry for the assigned values; see Section 12.3.4.
60 ～ 63 の範囲は実験用に予約されています。IANA は、割り当てられた値に対して「Test Setup PDU Authentication Mode」レジストリを作成しました。セクション12.3.4を参照してください。
authUnixTime:
認証Unix時間:
A 32-bit timestamp of the current system (wall-clock) time since the Unix Epoch on January 1, 1970 at 00:00:00 UTC.
1970 年 1 月 1 日の 00:00:00 UTC の Unix エポック以降の現在のシステム (実時間) 時刻の 32 ビット タイムスタンプ。
authDigest:
認証ダイジェスト:
This field contains the 32-octet HMAC-SHA-256 hash that covers the entire PDU. Normally, the calculation is done as the last step of building the PDU. However, if the optional checkSum field is being utilized, it becomes the penultimate step and is done just prior to the checksum calculation (with the checkSum field set to zero).
このフィールドには、PDU 全体をカバーする 32 オクテットの HMAC-SHA-256 ハッシュが含まれています。通常、計算は PDU 構築の最後のステップとして実行されます。ただし、オプションの checkSum フィールドが使用されている場合、それは最後から 2 番目のステップとなり、チェックサム計算の直前に実行されます (checkSum フィールドはゼロに設定されます)。
keyId:
キーID:
A one-octet field carrying localKeyName, the numeric key identifier for a key in the shared key table.
共有キー テーブル内のキーの数値キー識別子である localKeyName を保持する 1 オクテットのフィールド。
reservedAuth1:
予約済み認証1:
A one-octet field. This field MUST be set to 0 and MUST be ignored upon receipt. Consistent naming and placement of the reservedAuth1 field across all PDUs is done to minimize authentication-related changes in future UDPSTP versions.
1 オクテットのフィールド。このフィールドは 0 に設定しなければならず、受信時に無視しなければなりません。将来の UDPSTP バージョンでの認証関連の変更を最小限に抑えるために、すべての PDU にわたって、reservedAuth1 フィールドの一貫した名前付けと配置が行われます。
checkSum:
チェックサム:
A two-octet field containing an optional checksum of the entire PDU (see Section 5.6 for guidance). The calculation is done as the very last step of building the PDU, with the checkSum field set to zero.
PDU 全体のオプションのチェックサムを含む 2 オクテットのフィールド (ガイダンスについてはセクション 5.6 を参照)。この計算は、checkSum フィールドをゼロに設定して、PDU 構築の最後のステップとして実行されます。
This section describes the processes at the server that are used to evaluate the Test Setup Request and determine the next steps. When the server receives the Setup Request, it SHALL first perform the following:
このセクションでは、テスト セットアップ リクエストを評価し、次のステップを決定するために使用されるサーバーでのプロセスについて説明します。サーバーはセットアップリクエストを受信すると、まず次のことを実行するものとします(SHALL)。
Message Verification Procedure:
メッセージ検証手順:
1. Verify that the size of the message is correct.
1. メッセージのサイズが正しいことを確認してください。
2. If the optional checkSum field is being utilized, validate the checksum as described in Section 5.6 and (if valid) zero the checkSum field prior to authentication verification.
2. オプションの checkSum フィールドが使用されている場合は、セクション 5.6 で説明されているようにチェックサムを検証し、(有効な場合は) 認証検証の前に checkSum フィールドをゼロにします。
3. Verify that the authMode value is valid and appropriate (per Section 5.3) for the message type.
3. authMode 値が有効であり、メッセージ タイプに対して (セクション 5.3 に従って) 適切であることを確認します。
4. If the authMode is valid and appropriate, authenticate the message by checking the authDigest as prescribed in Section 5.3.
4. authMode が有効かつ適切な場合、セクション 5.3 の規定に従って authDigest をチェックしてメッセージを認証します。
5. If the message is authentic, check the authUnixTime field for acceptable immediacy.
5. メッセージが本物である場合は、許容できる即時性について authUnixTime フィールドを確認してください。
Note: If any of the above checks fail, the message SHALL be considered invalid.
注: 上記のチェックのいずれかが失敗した場合、メッセージは無効であると見なされます。
The server SHALL then evaluate the other fields in the protocol header, such as the protocol version, the PDU ID (to validate the type of message), the maximum bandwidth requested for the test, and the modifierBitmap for use of options such as Jumbo datagram status and Traditional MTU (1500 bytes).
次にサーバーは、プロトコル バージョン、PDU ID (メッセージのタイプを検証するため)、テストに要求された最大帯域幅、ジャンボ データグラム ステータスや従来型 MTU (1500 バイト) などのオプションを使用するための modifierBitmap など、プロトコル ヘッダー内の他のフィールドを評価するものとします (SHALL)。
If the client has selected options for
クライアントがオプションを選択した場合
* Jumbo datagram support (modifierBitmap),
* ジャンボ データグラムのサポート (modifierBitmap)、
* Traditional MTU (modifierBitmap), and
* 従来の MTU (modifierBitmap)、および
* Authentication mode (authMode)
* 認証モード（authMode）
that do not match the server configuration, the server MUST reject the Setup Request.
サーバー設定と一致しない場合、サーバーはセットアップ要求を拒否しなければなりません。
If the Setup Request must be rejected, the conditions below determine whether the server sends a response:
セットアップ リクエストを拒否する必要がある場合、サーバーが応答を送信するかどうかは以下の条件によって決まります。
* 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.
* authDigest が有効な場合、テスト セットアップ応答は、拒否の理由を示す対応するコマンド応答値とともにクライアントに返送されるものとします (SHALL)。
* If the authDigest is invalid, then the Test Setup Request SHOULD fail silently. The exception is for operations support: server administrators are permitted to send a Setup Response to support operations and troubleshooting.
* authDigest が無効な場合、テスト セットアップ リクエストはサイレントに失敗する必要があります (SHOULD)。例外は運用サポートです。サーバー管理者は、運用とトラブルシューティングをサポートするためにセットアップ応答を送信することが許可されています。
The additional circumstances when a server SHALL NOT communicate the appropriate Command Response code for an error condition (fail silently) are when:
サーバーがエラー状態に対して適切なコマンド応答コードを通信してはならない (通知せずに失敗する) 追加の状況は、次のような場合です。
* the Setup Request PDU size is not equal to the 'struct controlHdrSR' size shown in Figure 3,
* Setup Request PDU サイズは、図 3 に示す「struct controlHdrSR」サイズと等しくありません。
* the PDU ID is not 0xACE1 (Test Setup PDU), or
* PDU ID が 0xACE1 (テスト セットアップ PDU) ではない、または
* a directed attack has been detected.
* 指向性攻撃が検出されました。
In this case, the server will allow setup attempts to terminate silently. Attack detection is beyond the scope of this specification.
この場合、サーバーはセットアップの試行をサイレントに終了することを許可します。攻撃の検出はこの仕様の範囲外です。
When the server replies to a Test Setup Request message, the Test Setup Response PDU is structured identically to the Test Setup Request PDU and SHALL retain the original values received in it, with the following exceptions:
サーバーがテスト セットアップ要求メッセージに応答する場合、テスト セットアップ応答 PDU はテスト セットアップ要求 PDU と同じ構造になっており、次の例外を除いて、そこで受信した元の値を保持するものとします。
* The cmdRequest field is set to CHSR_CREQ_SETUPRSP, indicating a response.
* cmdRequest フィールドは CHSR_CREQ_SETUPRSP に設定され、応答を示します。
* The cmdResponse field is set to an error code (starting at cmdResponse 2, Bad Protocol Version; see Section 12.3.5), indicating the reason for rejection. If cmdResponse indicates a bad protocol version (CHSR_CRSP_BADVER), the protocolVer field is also updated to indicate the current expected version.
* cmdResponse フィールドには、拒否の理由を示すエラー コード (cmdResponse 2、不正なプロトコル バージョンから始まります。セクション 12.3.5 を参照) が設定されます。cmdResponse が不正なプロトコル バージョン (CHSR_CRSP_BADVER) を示している場合、protocolVer フィールドも更新されて、現在の予期されるバージョンを示します。
* The authUnixTime field is updated to the current system (wall-clock) time and, after the authDigest and checkSum fields are zeroed, the authDigest is recalculated and inserted. If the optional checkSum field is being utilized, it is then also calculated and inserted.
* authUnixTime フィールドは現在のシステム (壁時計) 時間に更新され、authDigest フィールドと checkSum フィールドがゼロに設定された後、authDigest が再計算されて挿入されます。オプションの checkSum フィールドが使用されている場合は、それも計算されて挿入されます。
The Setup Request/Response message PDU SHALL be organized as follows (here and in all following code figures coded by programming language C [C-Prog]):
セットアップ要求/応答メッセージ PDU は次のように構成されます (ここおよび以下のすべてのコード図はプログラミング言語 C [C-Prog] でコード化されています)。
<CODE BEGINS>
//
// Control header for UDP payload of Setup Request/Response PDUs
//
struct controlHdrSR {
#define CHSR_ID 0xACE1
uint16_t pduId; // PDU ID
#define PROTOCOL_VER 20
uint16_t protocolVer; // Protocol version
uint8_t mcIndex; // Multi-connection index
uint8_t mcCount; // Multi-connection count
uint16_t mcIdent; // Multi-connection identifier
#define CHSR_CREQ_NONE 0
#define CHSR_CREQ_SETUPREQ 1 // Setup Request
#define CHSR_CREQ_SETUPRSP 2 // Setup Response
uint8_t cmdRequest; // Command Request
#define CHSR_CRSP_NONE 0 // (used with request)
#define CHSR_CRSP_ACKOK 1 // Acknowledgment
#define CHSR_CRSP_BADVER 2 // Bad version
#define CHSR_CRSP_BADJS 3 // Jumbo setting mismatch
#define CHSR_CRSP_AUTHNC 4 // Auth. not configured
#define CHSR_CRSP_AUTHREQ 5 // Auth. required
#define CHSR_CRSP_AUTHINV 6 // Auth. (mode) invalid
#define CHSR_CRSP_AUTHFAIL 7 // Auth. failure
#define CHSR_CRSP_AUTHTIME 8 // Auth. time invalid
#define CHSR_CRSP_NOMAXBW 9 // Max bandwidth required
#define CHSR_CRSP_CAPEXC 10 // Capacity exceeded
#define CHSR_CRSP_BADTMTU 11 // Trad. MTU mismatch
#define CHSR_CRSP_MCINVPAR 12 // Multi-conn. invalid params
#define CHSR_CRSP_CONNFAIL 13 // Conn. allocation failure
uint8_t cmdResponse; // Command Response
#define CHSR_USDIR_BIT 0x8000 // Upstream direction bit
uint16_t maxBandwidth; // Required bandwidth in Mbps
uint16_t testPort; // Test port on server
#define CHSR_JUMBO_STATUS 0x01
#define CHSR_TRADITIONAL_MTU 0x02
uint8_t modifierBitmap; // Modifier bitmap
// ========== Integrity Verification ==========
#define AUTHMODE_1 1 // Mode 1: Authenticated Control
#define AUTHMODE_2 2 // Mode 2: Authenticated Control+Status
uint8_t authMode; // Authentication mode
uint32_t authUnixTime; // Authentication timestamp
#define AUTH_DIGEST_LENGTH 32 // SHA-256 digest length
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
};
#define SHA256_KEY_LEN 32 // Authentication key length
<CODE ENDS>
Figure 3: Test Setup PDU
図 3: テスト セットアップ PDU
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 from the client, using a new UDP socket allocated from the UDP ephemeral port range. This new socket will also be used for the subsequent Load and Status PDUs that are part of testing (with the port number communicated back to the client in testPort field of the Test Setup Response). Then, the server SHALL start a watchdog timer (to terminate the new connection if the client goes silent) and SHALL send the Test Setup Response back to the client. The watchdog timer is set to the same value as on the client side (see Section 6)
サーバーが、セットアップ要求がその構成と一致し、その他の点で許容できると判断した場合、サーバーは、UDP 一時ポート範囲から割り当てられた新しい UDP ソケットを使用して、クライアントからテスト アクティベーション要求を受信するための新しい接続を開始するものとします(SHALL)。この新しいソケットは、テストの一部である後続のロードおよびステータス PDU にも使用されます (ポート番号はテスト セットアップ応答の testPort フィールドでクライアントに返されます)。次に、サーバーは (クライアントが沈黙した場合に新しい接続を終了するために) ウォッチドッグ タイマーを開始し、テスト セットアップ応答をクライアントに送り返すものとします(SHALL)。ウォッチドッグ タイマーはクライアント側と同じ値に設定されます (セクション 6 を参照)
When the server replies to the Test Setup Request message, the Test Setup Response PDU is structured identically to the Test Setup Request PDU and SHALL retain the original values received in it, with the following exceptions:
サーバーがテスト セットアップ要求メッセージに応答するとき、テスト セットアップ応答 PDU はテスト セットアップ要求 PDU と同じ構造になっており、次の例外を除いて、そこで受信した元の値を保持するものとします。
* The cmdRequest field is set to CHSR_CREQ_SETUPRSP, indicating a response.
* cmdRequest フィールドは CHSR_CREQ_SETUPRSP に設定され、応答を示します。
* The cmdResponse field is set to CHSR_CRSP_ACKOK, indicating an acknowledgment.
* cmdResponse フィールドは CHSR_CRSP_ACKOK に設定され、確認応答を示します。
* The testPort field is set to the ephemeral port number to be used for the client's Test Activation Request and all subsequent communication.
* testPort フィールドは、クライアントのテスト アクティベーション要求とその後のすべての通信に使用される一時ポート番号に設定されます。
* The authUnixTime field is updated to the current system (wall-clock) time and, after the authDigest and checkSum fields are zeroed, the authDigest is recalculated and inserted. If the optional checkSum field is being utilized, it is then also calculated and inserted.
* authUnixTime フィールドは現在のシステム (壁時計) 時間に更新され、authDigest フィールドと checkSum フィールドがゼロに設定された後、authDigest が再計算されて挿入されます。オプションの checkSum フィールドが使用されている場合は、それも計算されて挿入されます。
Finally, the new UDP connection associated with the new socket and port number are made ready, and the server awaits further communication there.
最後に、新しいソケットとポート番号に関連付けられた新しい UDP 接続が準備され、サーバーはそこでさらなる通信を待ちます。
To ensure that a server's local firewall will successfully allow packets received for the new ephemeral port number, the server SHALL immediately send a Null Request with the corresponding 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 Null Request arrives at the client, it is a confirmation that further exchanges are possible on the new port-pair (but this is not strictly necessary). If received, the client SHALL follow the Message Verification Procedure listed in Section 6.2, Paragraph 2. Note that there is no response to a Null Request.
サーバーのローカル ファイアウォールが新しい一時ポート番号で受信したパケットを確実に許可するために、サーバーは送信元および宛先の IP アドレスとポート番号を含む対応する値を含む Null 要求を直ちに送信するものとします (SHALL)。送信元ポートは新しい一時ポートであるものとします。この操作により、サーバーのローカル ファイアウォールが一時ポートのオープン範囲を禁止している場合でも、サーバーへの通信が可能になります。クライアント側のファイアウォールが予期しないトラフィックをブロックした場合、パケットはクライアントに正常に到着するとは限りません。Null リクエストがクライアントに到着すると、新しいポート ペアでさらなる交換が可能であることが確認されます (ただし、これは厳密に必要なわけではありません)。受信した場合、クライアントはセクション 6.2、第 2 項にリストされているメッセージ検証手順に従うものとします (SHALL)。Null リクエストには応答がないことに注意してください。
The UDP PDU format layout SHALL be as follows (big-endian AB):
UDP PDU フォーマットのレイアウトは次のとおりです (ビッグエンディアン 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pduId | protocolVer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cmdRequest | cmdResponse | reserved1 | authMode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authUnixTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. authDigest (32 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| keyId | reservedAuth1 | checkSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Null Request PDU Layout
図 4: Null リクエスト PDU レイアウト
The authentication and checkSum fields follow the same methodology as with the Setup Request and Response.
認証フィールドとチェックサムフィールドは、セットアップ要求と応答の場合と同じ方法に従います。
Additional details regarding the Null Request fields are as follows:
Null リクエスト フィールドに関する追加の詳細は次のとおりです。
pduId:
pduId:
IANA has assigned the hex value 0xDEAD (Section 12.3.1).
IANA は 16 進値 0xDEAD を割り当てました (セクション 12.3.1)。
cmdRequest:
cmdRequest:
Set to CHNR_CREQ_NULLREQ to indicate a Null Request message.
CHNR_CREQ_NULLREQ に設定すると、Null 要求メッセージを示します。
cmdResponse:
cmdResponse:
Set to CHNR_CRSP_NONE.
CHNR_CRSP_NONE に設定します。
authMode:
認証モード:
Same as in Section 6.1.
セクション 6.1 と同じ。
authUnixTime:
認証Unix時間:
Same as in Section 6.1.
セクション 6.1 と同じ。
authDigest:
認証ダイジェスト:
Same as in Section 6.1.
セクション 6.1 と同じ。
keyId:
キーID:
Same as in Section 6.1.
セクション 6.1 と同じ。
reservedAuth1:
予約済み認証1:
Same as in Section 6.1.
セクション 6.1 と同じ。
checkSum:
チェックサム:
Same as in Section 6.1.
セクション 6.1 と同じ。
If a Test Activation Request is not subsequently received from the client on the new ephemeral port number before the watchdog timer expires, the server SHALL close the socket and deallocate the associated resources.
その後、ウォッチドッグ タイマーが期限切れになる前に新しい一時ポート番号でクライアントからテスト アクティベーション要求を受信しなかった場合、サーバーはソケットを閉じ、関連するリソースの割り当てを解除するものとします (SHALL)。
The Null Request message PDU SHALL be organized as follows:
Null リクエスト メッセージ PDU は次のように編成されなければなりません (SHALL)。
<CODE BEGINS>
//
// Control header for UDP payload of Null Request PDU
//
struct controlHdrNR {
#define CHNR_ID 0xDEAD
uint16_t pduId; // PDU ID
uint16_t protocolVer; // Protocol version
#define CHNR_CREQ_NONE 0
#define CHNR_CREQ_NULLREQ 1 // Null Request
uint8_t cmdRequest; // Command Request
#define CHNR_CRSP_NONE 0 // (used with request)
uint8_t cmdResponse; // Command Response
uint8_t reserved1; // (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 5: Null Request PDU
図 5: ヌル要求 PDU
When the client receives the Test Setup Response message, it SHALL first follow the Message Verification Procedure listed in Section 6.2, Paragraph 2.
クライアントは、テストセットアップ応答メッセージを受信すると、まずセクション 6.2、段落 2 にリストされているメッセージ検証手順に従うものとします (SHALL)。
The client SHALL then proceed to evaluate the other fields in the protocol, beginning with the protocol version, PDU ID (to validate the type of message), and cmdRequest for the role of the message, which MUST be Test Setup Response, CHSR_CREQ_SETUPRSP, as indicated by Figure 3.
次に、クライアントは、プロトコル バージョン、PDU ID (メッセージの種類を検証するため)、およびメッセージの役割の cmdRequest から始まるプロトコル内の他のフィールドの評価を続行するものとします (SHALL)。メッセージの役割は、図 3 に示すように、テスト セットアップ応答 CHSR_CREQ_SETUPRSP でなければなりません。
If the cmdResponse value indicates an error (values greater than CHSR_CRSP_ACKOK), the client SHALL display/report a relevant message to the user or management process and exit. If the client receives a Command Response code that is not equal to one of the codes defined, the client MUST terminate the connection and terminate operation of the current Setup Request. If the Command Response code value indicates success (CHSR_CRSP_ACKOK), 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.
cmdResponse 値がエラー (CHSR_CRSP_ACKOK より大きい値) を示している場合、クライアントは関連するメッセージをユーザーまたは管理プロセスに表示/報告し、終了するものとします(SHALL)。クライアントが定義されたコードのいずれとも異なるコマンド応答コードを受信した場合、クライアントは接続を終了し、現在のセットアップ要求の操作を終了しなければなりません(MUST)。コマンド応答コード値が成功(CHSR_CRSP_ACKOK)を示した場合、クライアントは、以下で説明するように、テスト方向、テスト期間など、必要なすべてのテストパラメータを含むテストアクティベーションリクエストを作成するものとします(SHALL)。
This section is divided according to the sending and processing of the client and server and again at the client.
このセクションは、クライアントとサーバーの送信と処理、およびクライアントでの送信と処理に応じて分割されます。
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).
セットアップ交換が成功すると、クライアントはテスト アクティベーション要求を作成し、サーバーがテスト セットアップ応答で通信した UDP ポート番号 (標準の UDPSTP ポートではなく、新しい一時ポート) に送信するものとします (SHALL)。
The UDP PDU format layout is as follows (big-endian AB):
UDP PDU フォーマットのレイアウトは次のとおりです (ビッグエンディアン 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
図 6: テスト アクティベーション PDU のレイアウト
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:
pduId:
IANA has assigned the hex value 0xACE2 (Section 12.3.1).
IANA は 16 進値 0xACE2 を割り当てました (セクション 12.3.1)。
cmdRequest:
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.
アップストリーム テストのアクティブ化を示すには CHTA_CREQ_TESTACTUS に設定するか、ダウンストリーム テストのアクティブ化を示すには CHTA_CREQ_TESTACTDS に設定します。CHTA_CREQ_NONE は未使用のままであることに注意してください。セクション12.3.6を参照してください。
cmdResponse:
cmdResponse:
Three CHTA_CRSP_<Indication> values are defined; see Figure 7.
3 つの CHTA_CRSP_<Indication> 値が定義されています。図 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].
2 オクテットのフィールド。ラウンドトリップ時間 (RTT) 変動の範囲の下限しきい値 (範囲は最小 RTT を超える値で構成されます)。表 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].
2 オクテットのフィールド。RTT 変動範囲の上限しきい値 (範囲は最小 RTT を超える値で構成されます)。[TR-471] の表 3 も参照してください。
trialInt:
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).
ステータス フィードバック/試行間隔をミリ秒単位で示す 2 オクテットのフィールド。テスト間隔 Delta_t は、いくつかのサブ間隔 dt に細分され、各サブ間隔はさらにいくつかの試行間隔に分割されます ([TR-471] を参照)。1 から始まり、単一のテスト間隔 (testIntTime) 中に継続的に増分されます。
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]).
2 オクテットのフィールド。検索アルゴリズムが使用されている場合のテスト (ダウンリンクまたはアップリンク) の期間。検索プロセスの最大期間 (秒単位) として機能します ([TR-471] の表 3 の TestInterval も参照)。
dscpEcn:
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.
Diffserv コードポイントと ECN フィールド。[TR-471] で指定されている DSCP フィールドも参照してください。この仕様は、ECN 対応のトランスポートを提供しません。したがって、送信者は ECN フィールドを not_ECT に設定するものとします (SHALL)。
srIndexConf:
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.
2 オクテットのフィールド。テスト アクティベーション リクエストで使用される、要求された設定送信レート テーブルのインデックス。希望の固定送信レートまたは開始送信レート (CHTA_SRIDX_ISSTART がそれぞれクリアまたは設定されているかどうかに応じて) になります。値 0 は有効な固定または開始送信速度インデックスであるため、サーバーのデフォルト動作 (選択された負荷速度調整アルゴリズムを最小/ゼロ インデックスで開始) を要求する場合、フィールドはその最大値 (CHTA_SRIDX_DEF) に設定されるものとします(SHALL)。これは、srIndexConf を 0 に設定し、CHTA_SRIDX_ISSTART ビットを設定することと同等であるものとします。
useOwDelVar:
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].
1 オクテットのフィールド。ブール値、デフォルトは True (False の場合、負荷率調整アルゴリズムで RTT= 往復遅延変動を使用します。True の場合、負荷率調整アルゴリズムで一方向遅延変動を使用する EnableIPDV を使用します)。[TR-471] の表 1 の EnableIPDV を参照してください。
highSpeedDelta:
ハイスピードデルタ:
A one-octet field; see Appendix A of [RFC9097].
1 オクテットのフィールド。[RFC9097]の付録Aを参照してください。
slowAdjThresh and seqErrThresh:
lowAdjThresh と seqErrThresh:
Two two-octet fields; see Appendix A of [RFC9097].
2 つの 2 オクテットのフィールド。[RFC9097]の付録Aを参照してください。
ignoreOooDup:
無視OooDup:
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]).
1 オクテットのフィールド。順序が乱れた重複を無視します。ブール値。True の場合、受信パケット シーケンス番号エラーとして損失のみがカウントされます。False の場合、損失、順序外れ、重複の合計はすべてシーケンス番号エラーとしてカウントされます。デフォルトは True です ([TR-471] の表 3 も参照)。
modifierBitmap:
修飾子ビットマップ:
A one-octet field. This document only assigns two bits in this bitmap; see Section 12.3.7:
1 オクテットのフィールド。このドキュメントでは、このビットマップに 2 つのビットのみを割り当てます。セクション12.3.7を参照してください。
CHTA_SRIDX_ISSTART (0x01):
CHTA_SRIDX_ISSTART (0x01):
Treat srIndexConf as the starting sending rate to be used by the load rate adjustment algorithm.
srIndexConf を、負荷レート調整アルゴリズムで使用される開始送信レートとして扱います。
CHTA_RAND_PAYLOAD (0x02):
CHTA_RAND_PAYLOAD (0x02):
Randomize the payload content beyond the Load PDU header.
Load PDU ヘッダーを超えてペイロード コンテンツをランダム化します。
Other bit positions are left unassigned per this document.
このドキュメントに従って、他のビット位置は割り当てられないままになります。
rateAdjAlgo:
rateAdjAlgo:
A one-octet field. The applied load rate adjustment algorithm; see Section 12.3.8.
1 オクテットのフィールド。適用される負荷率調整アルゴリズム。セクション12.3.8を参照してください。
srStruct:
sr構造体:
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:
送信レート構造。クライアントが使用する (初期) Load PDU 送信パラメータを伝達するために、アップストリーム テストのテスト アクティベーション レスポンスでサーバーによって使用されます。テストアクティベーションリクエストまたはダウンストリームテストの場合、この構造体はゼロに設定されるものとします(SHALL)。2 セットの周期的送信パラメータが利用可能で、(高度なレート粒度をサポートするため) デュアル独立送信機が可能になります。フィールドは次のように定義されます。
txInterval1 and txInterval2:
txInterval1 および txInterval2:
Two four-octet fields indicating the load rate transmit interval in us (microseconds). A 100 us granularity is recommended for optimal rate selection.
負荷率の送信間隔をマイクロ秒単位で示す 2 つの 4 オクテット フィールド。最適なレートを選択するには、100 us の粒度が推奨されます。
udpPayload1 and udpPayload2:
udpPayload1 と udpPayload2:
Two four-octet fields indicating the UDP payload at load rate in bytes.
負荷率での UDP ペイロードをバイト単位で示す 2 つの 4 オクテット フィールド。
burstSize1 and burstSize2:
バーストサイズ 1 とバーストサイズ 2:
Two four-octet fields indicating the burst size at load rate by a dimensionless number (of datagrams).
負荷レートでのバースト サイズを (データグラムの) 無次元数で示す 2 つの 4 オクテット フィールド。
udpAddon2:
udpアドオン2:
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.
udpPayload2 またはburstSize2 がゼロで、それ自体の送信が行われない場合でも、txInterval2 送信シーケンスの最後に送信される単一の Load PDU のサイズを示す 4 オクテットのフィールド。
subIntPeriod:
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.
2 オクテットのフィールド。ミリ秒単位のテストサブインターバル期間 ([TR-471] の表 3 も参照)。subIntPeriod を 100 ～ 10000 ミリ秒の範囲で試行した結果、デフォルト値は 1000 ミリ秒になりました。
authMode:
認証モード:
Same as in Section 6.1.
セクション 6.1 と同じ。
authUnixTime:
認証Unix時間:
Same as in Section 6.1.
セクション 6.1 と同じ。
authDigest:
認証ダイジェスト:
Same as in Section 6.1.
セクション 6.1 と同じ。
keyId:
キーID:
Same as in Section 6.1.
セクション 6.1 と同じ。
reservedAuth1:
予約済み認証1:
Same as in Section 6.1.
セクション 6.1 と同じ。
checkSum:
チェックサム:
Same as in Section 6.1.
セクション 6.1 と同じ。
The Test Activation Request/Response message PDU (as well as the included Sending Rate structure) SHALL be organized as follows:
テスト アクティベーション要求/応答メッセージ PDU (および含まれる送信レート構造) は、次のように編成されなければなりません (SHALL)。
<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: テスト アクティベーション PDU
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.
サーバーは、新しい接続でテスト アクティベーション リクエストを受信すると、テスト パラメータのいずれかを受け入れるか、無視するか、変更するかを選択します。サーバーが Test Activation Request メッセージに応答するとき、Test Activation Response PDU は Request PDU と同じ構造になっており、明示的にサーバーが受け入れ可能な値に強制されない限り、受信した元の値を保持するものとします (SHALL)。
When the server receives the Test Activation Request message, it SHALL first follow the Message Verification Procedure listed in Section 6.2, Paragraph 2.
サーバーがテストアクティベーションリクエストメッセージを受信すると、まずセクション 6.2、段落 2 にリストされているメッセージ検証手順に従うものとします (SHALL)。
When evaluating the Test Activation Request, the server MAY allow the client to specify its own fixed or starting send rate via srIndexConf.
テストアクティベーションリクエストを評価するとき、サーバーはクライアントが srIndexConf を介して独自の固定または開始送信レートを指定できるようにしてもよい (MAY)。
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.
あるいは、サーバーは、クライアントが正常に要求できる固定または開始送信レートの最大制限を強制してもよい(MAY)。クライアントのテストアクティベーションリクエストがサーバーの設定された最大値を超える場合、サーバーはリクエストを拒否するか、値を設定された最大ビットレートに強制し、その最大値をテストアクティベーションレスポンスでクライアントに伝えなければなりません(MUST)。もちろん、クライアントは必要に応じてテストを終了することを選択できます。
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
* 負荷レート調整アルゴリズム: lowThresh、upperThresh、useOwDelayVar、highSpeedDelta、slowAdjThresh、seqErrThresh、highSpeedDelta、ignoreOooDup、および rateAdjAlgo
* Test duration/intervals: trialInt, testIntTime, and subIntPeriod
* テスト期間/間隔:trialInt、testIntTime、および subIntPeriod
* Packet marking: dscpEcn
* パケットマーキング: 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.
強制は、サーバー構成の値を使用してテストを実行するためのステップです。クライアントが特定の値を好む場合でも、サーバーはクライアントに、優先セットとは異なる値を使用してテストを実行する機会を与えます。このような場合、コマンド応答値は 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).
サーバーにはリクエストを完全に拒否し、適切な cmdResponse フィールド値を送り返すオプションもあります (現在は CHTA_CRSP_BADPARAM のみ。セクション 12.3.9 を参照)。
Whether this error response is sent or not depends on the security mode of operation and the outcome of authDigest validation.
このエラー応答が送信されるかどうかは、動作のセキュリティ モードと authDigest 検証の結果によって異なります。
If the Test Activation Request must be rejected (due to the Command Response value being CHTA_CRSP_BADPARAM), and
テスト アクティベーション要求を拒否する必要がある場合 (コマンド応答値が CHTA_CRSP_BADPARAM であるため)、および
* 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.
* authDigest が有効な場合、テストアクティベーション応答は、拒否の理由を示す対応するコマンド応答値とともにクライアントに返送されるものとします (SHALL)。
* 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.
* authDigest が無効な場合、テスト アクティベーション リクエストはサイレントに失敗する必要があります (SHOULD)。例外は操作サポートです。サーバー管理者は、操作とトラブルシューティングをサポートするためにアクティベーション応答を送信することが許可されています。
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,
* テスト アクティベーション リクエスト PDU サイズが、図 7 に示す「struct controlHdrTA」サイズと等しくありません。
* the PDU ID is not 0xACE2 (Test Activation PDU), or
* PDU ID が 0xACE2 (テスト アクティベーション PDU) ではない、または
* 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.
この場合、サーバーはテスト アクティベーション リクエストがサイレントに終了することを許可します。攻撃の検出はこの仕様の範囲外です。
When the server sends the Test Activation Response, it SHALL set the cmdResponse field to CHTA_CRSP_ACKOK (see Section 12.3.9).
サーバーが Test Activation Response を送信するときは、cmdResponse フィールドを CHTA_CRSP_ACKOK に設定するものとします (セクション 12.3.9 を参照)。
If the client has requested an upstream test, the server SHALL:
クライアントがアップストリームテストを要求した場合、サーバーは次のことを行うものとします(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
* 送信レート構造体の送信レート テーブルの最初の行の送信パラメータを含めます (srIndexConf を CHTA_SRIDX_DEF の値に設定することによって要求された場合)、または
* 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.
* 送信レート テーブルの指定された構成済み送信レート テーブル インデックス (srIndexConf) からの送信パラメータが含まれます。CHTA_SRIDX_ISSTART が modifierBitmap に設定されている場合、これは負荷レート調整アルゴリズムの開始レートとして使用されます。それ以外の場合は、固定レートのテストとみなされます。
When generating the Test Activation Response (acceptance) for a downstream test, the server SHALL set all octets of the Sending Rate structure to zero.
ダウンストリームテストのテストアクティベーション応答（受諾）を生成するとき、サーバーは送信レート構造のすべてのオクテットをゼロに設定するものとします（SHALL）。
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:
アップストリーム テストの場合、サーバーは単一のタイマーを使用して、指定された間隔でステータス PDU を送信する準備をする必要があります (SHALL)。ダウンストリーム テストの場合、サーバーは以下に基づいてデュアル タイマーを利用して Load PDU を送信する準備をするものとします (SHALL)。
* 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
* 送信レート テーブルの最初の行から直接送信パラメータ (CHTA_SRIDX_DEF に設定されている srIndexConf によって要求された場合)、または
* 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.
* 送信レート テーブルの指定された構成済み送信レート テーブル インデックス (srIndexConf) からの送信パラメータ。CHTA_SRIDX_ISSTART が modifierBitmap に設定されている場合、これは負荷レート調整アルゴリズムの開始レートとして使用されます。それ以外の場合は、固定レートのテストとみなされます。
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.
その後、サーバーはテストアクティベーション応答をクライアントに送り返し、新しいタイムアウト値でウォッチドッグタイマーを更新し、最終的にテストを停止するためにテスト期間タイマーを設定するものとします(SHALL)。
When the client receives the Test Activation Response message, it SHALL first follow the Message Verification Procedure listed in Section 6.2, Paragraph 2.
クライアントは、Test Activation Response メッセージを受信すると、まずセクション 6.2、段落 2 にリストされているメッセージ検証手順に従うものとします (SHALL)。
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.
クライアントがエラーを示す Test Activation cmdResponse フィールド値を受信した場合、クライアントは関連するメッセージをユーザーまたは測定システムに表示/報告して終了するものとします(SHALL)。
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.
クライアントがセクション 12.3.9 で定義されたコードのいずれとも異なる Test Activation cmdResponse フィールド値を受信した場合、クライアントは接続を終了し、現在のセットアップ手順の操作を終了しなければなりません (MUST)。
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.
クライアントが成功を示すテストアクティベーションコマンド応答値(例: CHTA_CRSP_ACKOK; セクション12.3.9を参照)を受信した場合、クライアントはサーバーによって変更されたテストパラメータを使用するように構成を更新するものとします(SHALL)。サーバーによって強制されたセットアップ パラメータがクライアントに受け入れられない場合、クライアントはテストを終了します。
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.
受け入れられたテストのアクティベーションを完了するために、クライアントは、ロード PDU を送信するように設定されたデュアル タイマーを使用したアップストリーム テスト (サーバーによって送信された開始送信パラメータに基づいて)、または指定された間隔でステータス PDU を送信する単一のタイマーを使用したダウンストリーム テストのいずれかに向けて接続を準備するものとします(SHALL)。
Then, the client SHALL stop the test initiation timer and start a watchdog timer to detect if the server goes quiet.
その後、クライアントはテスト開始タイマーを停止し、サーバーが停止したかどうかを検出するためにウォッチドッグ タイマーを開始するものとします(SHALL)。
The connection is now ready for testing.
これで接続をテストする準備が整いました。
This section describes the Data phase of the protocol. The roles of sender and receiver vary depending on whether the direction of testing is from server to client, or the reverse.
このセクションでは、プロトコルのデータ フェーズについて説明します。送信者と受信者の役割は、テストの方向がサーバーからクライアントか、その逆かによって異なります。
Testing proceeds with one endpoint sending Load PDUs, based on transmission parameters from the Sending Rate Table, and the other endpoint sending Status Feedback messages to communicate the traffic conditions at the receiver. When the server is sending Status Feedback messages, they will also contain the latest transmission parameters from the Sending Rate Table that the client SHALL use.
テストは、一方のエンドポイントが送信レート テーブルの送信パラメータに基づいてロード PDU を送信し、もう一方のエンドポイントがステータス フィードバック メッセージを送信して受信側のトラフィック状況を伝達することで進行します。サーバーがステータス フィードバック メッセージを送信するとき、メッセージには、クライアントが使用する送信レート テーブルからの最新の送信パラメータも含まれます。
When a Load PDU is received, the receiver SHALL do the following:
Load PDU を受信した場合、受信者は次のことを行うものとします (SHALL)。
1. Verify that the size of the message is greater than or equal to the 'struct loadHdr' size shown in Figure 9.
1. メッセージのサイズが、図 9 に示す「structloadHdr」サイズ以上であることを確認します。
2. Validate the checksum for the Load PDU header portion of the total message (as described in Section 5.6) if the optional checkSum field is being utilized.
2. オプションの checkSum フィールドが使用されている場合は、メッセージ全体の Load PDU ヘッダー部分のチェックサムを検証します (セクション 5.6 を参照)。
3. Confirm that the PDU ID is 0xBEEF (Load PDU).
3. PDU ID が 0xBEEF (Load PDU) であることを確認します。
If any of the above checks fail, the message SHALL be considered invalid.
上記のチェックのいずれかが失敗した場合、メッセージは無効であると見なされます。
The watchdog timer at the receiver SHALL be reset each time a valid Load PDU is received (which includes verification of the checkSum, if in use). See non-graceful test stop in Section 9 for handling the watchdog timeout expiration at each endpoint. Note that the watchdog timer's purpose is to detect a connection failure or a massive congestion condition only.
受信側のウォッチドッグ タイマーは、有効な Load PDU が受信されるたびにリセットされるものとします (SHALL) (チェックサムが使用されている場合は、その検証を含みます)。各エンドポイントでのウォッチドッグ タイムアウト期限切れの処理については、セクション 9 の非正常テスト停止を参照してください。ウォッチドッグ タイマーの目的は、接続障害または大規模な輻輳状態のみを検出することであることに注意してください。
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 indirectly based on the feedback in its received Status Feedback messages).
サーバーが送信側の役割でロード PDU を送信する場合、サーバーは現在選択されているインデックス (受信したステータス フィードバック メッセージ内のフィードバックに間接的に基づいた) を介して、送信レート テーブルから送信パラメータを直接使用するものとします(SHALL)。
However, when the client is sending Load PDUs in the role of sender, it SHALL use the discrete transmission parameters that were communicated by the server in its periodic Status Feedback messages (and not referencing a Sending Rate Table directly). 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.
ただし、クライアントが送信側の役割で Load PDU を送信する場合、クライアントは定期的なステータス フィードバック メッセージでサーバーによって通信された個別の送信パラメータを使用するものとします (SHALL) (送信レート テーブルを直接参照することはありません)。このアプローチにより、サーバーは個々の送信レートと、レートをいつどのように調整するかを決定するために使用されるアルゴリズムを制御できます。
The server uses a load rate adjustment algorithm that evaluates measurements taken locally at the Load PDU receiver. When the client is the receiver, the information is communicated to the server via periodic Status Feedback messages. When the server is the receiver, the information is used directly (although it is also communicated to the client via its periodic Status 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 are absent from other testing tools. Although the algorithm depends on the protocol, it is not part of the protocol per se.
サーバーは、Load PDU レシーバーでローカルに取得された測定値を評価する負荷率調整アルゴリズムを使用します。クライアントが受信者の場合、情報は定期的なステータス フィードバック メッセージを介してサーバーに送信されます。サーバーが受信側である場合、情報は直接使用されます (ただし、定期的なステータス フィードバック メッセージを介してクライアントにも送信されます)。このアプローチは、このプロトコルに固有のものです。最大 IP 容量を検索し、他のテスト ツールにはない特定の送信者の動作を指定する機能を提供します。アルゴリズムはプロトコルに依存しますが、それ自体はプロトコルの一部ではありません。
The default algorithm (B; see [Y.1540]) has three paths to its decision on the next sending rate:
デフォルトのアルゴリズム (B; [Y.1540] を参照) には、次の送信レートを決定するための 3 つのパスがあります。
1. When there are no impairments present (no sequence errors and low delay variation), resulting in a sending rate increase.
1. 障害が存在しない場合 (シーケンス エラーがなく、遅延変動が少ない場合)、送信レートが増加します。
2. When there are low impairments present (no sequence errors but higher levels of delay variation), the same sending rate is maintained.
2. 障害が少ない場合 (シーケンス エラーはないが、遅延変動のレベルが高い場合)、同じ送信レートが維持されます。
3. When the impairment levels are above the thresholds set for this purpose and "congestion" is inferred, resulting in a sending rate decrease.
3. 障害レベルがこの目的で設定されたしきい値を超えている場合、「輻輳」が推定され、送信速度が低下します。
Algorithm B also has two modes for increasing/decreasing the sending rate:
アルゴリズム B には、送信レートを増減するための 2 つのモードもあります。
* A high-speed mode (fast) to achieve high sending rates quickly but that also backs 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.
* 高速モード (高速) は、高い送信レートを迅速に達成しますが、測定値から「輻輳」が推定されると、すぐに停止します。シーケンス番号異常のしきい値を超えるカウントが連続するフィードバック間隔、および/または連続間隔のすべてに遅延変動上限しきい値例外が含まれる連続フィードバック間隔は、テスト内で「輻輳」を宣言するのに十分です。連続フィードバック間隔のしきい値は、デフォルトの 3 間隔で設定可能であるものとします (SHALL)。
* 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.
* シングルステップ (低速) モードでは、すべてのレート調整が送信レート テーブルの 1 ステップの最小増減を使用します。シングルステップ モードは、測定された障害から「渋滞」が最初に推測された後も継続します。
An OPTIONAL load rate 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 provides the option to retry the fast mode during a test (which improves the measurement accuracy in dynamic or error-prone access, such as radio access).
オプションの負荷率調整アルゴリズム (C と指定) が [TR-471] で定義されています。アルゴリズム C の動作とモードは B と似ていますが、C は高速モードで乗算増加を使用してギガビット範囲に素早く到達し、テスト中に高速モードを再試行するオプションを提供します (これにより、無線アクセスなどの動的アクセスやエラーが発生しやすいアクセスでの測定精度が向上します)。
On the other hand, the test configuration MAY use a fixed sending rate requested by the client, using the field srIndexConf.
一方、テスト設定では、フィールド srIndexConf を使用して、クライアントによって要求された固定送信レートを使用してもよい(MAY)。
The client MAY communicate the desired fixed rate in its Test Activation Request.
クライアントは、テストアクティベーションリクエストで希望の固定レートを通信してもよい(MAY)。
The UDP PDU format layout SHALL be as follows (big-endian AB):
UDP PDU フォーマットのレイアウトは次のとおりです (ビッグエンディアン 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pduId | testAction | rxStopped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lpduSeqNo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| udpPayload | spduSeqErr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spduTime_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spduTime_nsec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lpduTime_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lpduTime_nsec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rttRespDelay | checkSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Payload Content... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Load PDU Layout
図 8: ロード PDU レイアウト
Specific details regarding Load PDU fields are as follows:
Load PDU フィールドに関する具体的な詳細は次のとおりです。
pduId:
pduId:
IANA has assigned the hex value 0xBEEF (Section 12.3.1).
IANA は 16 進値 0xBEEF を割り当てました (セクション 12.3.1)。
testAction:
テストアクション:
A one-octet field designating the current test action as either TEST_ACT_TEST (testing in progress), TEST_ACT_STOP1 (first phase of graceful termination, used locally by server), or TEST_ACT_STOP2 (second phase of graceful termination, sent by server and reciprocated by client). See Section 9 for additional information on test termination.
現在のテスト アクションを TEST_ACT_TEST (テスト進行中)、TEST_ACT_STOP1 (正常な終了の第 1 フェーズ、サーバーによってローカルで使用)、または TEST_ACT_STOP2 (正常な終了の第 2 フェーズ、サーバーによって送信され、クライアントによって返される) のいずれかとして指定する 1 オクテットのフィールド。テストの終了に関する追加情報については、セクション 9 を参照してください。
rxStopped:
rx停止:
A one-octet field. Boolean, 0 or 1, used to indicate to the remote endpoint that local receive traffic (either Load or Status PDUs) has stopped. All outgoing Load or Status PDUs SHALL continue to assert this indication until traffic is received again, or the test is terminated. The time threshold to trigger this condition is expected to be a reasonable fraction of the watchdog timeout (a default of one second is recommended).
1 オクテットのフィールド。ブール値 (0 または 1)。ローカル受信トラフィック (ロード PDU またはステータス PDU のいずれか) が停止したことをリモート エンドポイントに示すために使用されます。すべての発信ロード PDU またはステータス PDU は、トラフィックが再び受信されるか、テストが終了するまで、この指示をアサートし続けるものとします (SHALL)。この状態を引き起こす時間しきい値は、ウォッチドッグ タイムアウトの適切な割合であることが予想されます (デフォルトの 1 秒を推奨します)。
lpduSeqNo:
lpduSeqNo:
A four-octet field indicating the Load PDU sequence number (starting at 1). Used to determine loss, out-of-order, and duplicate totals.
Load PDU シーケンス番号 (1 から始まる) を示す 4 オクテットのフィールド。損失、順序外れ、および重複の合計を決定するために使用されます。
udpPayload:
udpペイロード:
A two-octet field indicating the total payload size of the UDP datagram including the Load PDU message header and payload content (i.e., what the UDP socket read function would return). This field allows the Load PDU receiver to maintain accurate receive statistics if utilizing receive truncation (only requesting the Load PDU message header octets from the protocol stack).
Load PDU メッセージ ヘッダーとペイロード コンテンツ (つまり、UDP ソケット読み取り関数が返すもの) を含む UDP データグラムの合計ペイロード サイズを示す 2 オクテットのフィールド。このフィールドにより、Load PDU 受信機は、受信切り捨てを利用する場合 (プロトコル スタックから Load PDU メッセージ ヘッダー オクテットのみを要求する場合)、正確な受信統計を維持できます。
spduSeqErr:
spduSeqErr:
A two-octet field indicating the Status PDU loss count, as seen by the Load PDU sender. This is determined by the Status PDU sequence number (spduSeqNo) in the most recently received Status PDU. Used to communicate to the Load PDU receiver that return traffic (in the unloaded direction) is being lost.
Load PDU 送信側から確認される、Status PDU 損失数を示す 2 オクテットのフィールド。これは、最後に受信した Status PDU の Status PDU シーケンス番号 (spduSeqNo) によって決定されます。リターン トラフィック (アンロードされた方向) が失われていることを Load PDU レシーバーと通信するために使用されます。
spduTime_sec/spduTime_nsec:
spduTime_sec/spduTime_nsec:
Two four-octet fields containing a copy of the most recent spduTime_sec/spduTime_nsec from the last Status PDU received. Used for RTT measurements made by the Load PDU receiver.
受信した最後のステータス PDU からの最新の spduTime_sec/spduTime_nsec のコピーを含む 2 つの 4 オクテット フィールド。Load PDU レシーバーによって行われる RTT 測定に使用されます。
lpduTime_sec/lpduTime_nsec:
lpduTime_sec/lpduTime_nsec:
Two four-octet fields containing the local send time of the Load PDU. Used for one-way delay variation measurements made by the Load PDU receiver.
Load PDU のローカル送信時刻を含む 2 つの 4 オクテット フィールド。Load PDU レシーバーによる一方向遅延変動測定に使用されます。
rttRespDelay:
rtt応答遅延:
A two-octet field indicating the RTT response delay, used to "adjust" raw RTT. On the Load PDU sender, it is the number of ms from reception of the most recent Status PDU (when the latest spduTime_sec/spduTime_nsec was obtained) to the transmission of the Load PDU (where the previously obtained spduTime_sec/spduTime_nsec is returned). When the Load PDU receiver is calculating RTT, by subtracting the copied Status PDU send time (in the Load PDU) from the local Load PDU receive time, this value is subtracted from the raw RTT to correct for any response delay due to Load PDU scheduling.
RTT 応答遅延を示す 2 オクテットのフィールド。生の RTT を「調整」するために使用されます。Load PDU 送信側では、最新の Status PDU の受信 (最新の spduTime_sec/spduTime_nsec が取得されたとき) から Load PDU の送信 (以前に取得された spduTime_sec/spduTime_nsec が返される) までのミリ秒数です。Load PDU 受信機が RTT を計算しているとき、ローカルの Load PDU 受信時間からコピーされた Status PDU 送信時間 (Load PDU 内) を減算することで、この値が生の RTT から減算され、Load PDU のスケジューリングによる応答遅延が補正されます。
checkSum:
チェックサム:
An optional checksum of only the Load PDU header (see Section 5.6 for guidance). The checksum does not cover the payload content. The calculation is done as the very last step of building the PDU header, with the checkSum field set to zero.
Load PDU ヘッダーのみのオプションのチェックサム (ガイダンスについてはセクション 5.6 を参照)。チェックサムはペイロードの内容をカバーしません。この計算は、checkSum フィールドをゼロに設定して、PDU ヘッダーを構築する最後のステップとして実行されます。
Payload Content:
ペイロードの内容:
All zeroes, all ones, or a pseudorandom binary sequence.
すべて 0、すべて 1、または擬似ランダム バイナリ シーケンス。
The Load PDU SHALL be organized as follows (followed by any payload content):
Load PDU は次のように構成されます (その後にペイロード コンテンツが続きます)。
<CODE BEGINS>
//
// Load header for UDP payload of Load PDUs
//
struct loadHdr {
#define LOAD_ID 0xBEEF
uint16_t pduId; // PDU ID
#define TEST_ACT_TEST 0 // Test active
#define TEST_ACT_STOP1 1 // Stop indication used locally by server
#define TEST_ACT_STOP2 2 // Stop indication exchanged with client
uint8_t testAction; // Test action
uint8_t rxStopped; // Receive traffic stopped (BOOL)
uint32_t lpduSeqNo; // Load PDU sequence number
uint16_t udpPayload; // UDP payload (bytes)
uint16_t spduSeqErr; // Status PDU sequence error count
uint32_t spduTime_sec; // Send time in last rx'd status PDU
uint32_t spduTime_nsec; // Send time in last rx'd status PDU
uint32_t lpduTime_sec; // Send time of this Load PDU
uint32_t lpduTime_nsec; // Send time of this Load PDU
uint16_t rttRespDelay; // Response delay for RTT (ms)
uint16_t checkSum; // Header checksum
};
<CODE ENDS>
Figure 9: Load PDU
図 9: PDU のロード
The Load PDU receiver SHALL send a Status PDU to the sender during a test at the configured feedback interval, after at least one Load PDU has been received (when there is something to provide status on). In test scenarios with long delays between client and server, it is possible for the Status PDU send timer to fire before the first Load PDU arrives. In these cases, the Status PDU SHALL NOT be sent.
Load PDU受信者は、テスト中に少なくとも1つのLoad PDUを受信した後(ステータスを提供するものが存在する場合)、設定されたフィードバック間隔でステータスPDUを送信者に送信するものとします(SHALL)。クライアントとサーバー間の遅延が長いテスト シナリオでは、最初の Load PDU が到着する前に、Status PDU 送信タイマーが起動する可能性があります。このような場合、ステータス PDU は送信されません (SHALL)。
When the Load PDU sender receives a Status PDU message, it SHALL first follow the Message Verification Procedure listed in Section 6.2, Paragraph 2.
Load PDU 送信者は、Status PDU メッセージを受信すると、まずセクション 6.2、段落 2 にリストされているメッセージ検証手順に従うものとします (SHALL)。
The watchdog timer at the Load PDU sender SHALL be reset each time a valid Status PDU is received (which includes verification of the checkSum and/or authDigest, if in use). See non-graceful test stop in Section 9 for handling the watchdog timeout expiration at each endpoint.
Load PDU 送信側のウォッチドッグ タイマーは、有効な Status PDU を受信するたびにリセットされるものとします (SHALL) (これには、checkSum および/または authDigest が使用されている場合の検証が含まれます)。各エンドポイントでのウォッチドッグ タイムアウト期限切れの処理については、セクション 9 の非正常テスト停止を参照してください。
The UDP PDU format layout SHALL be as follows (big-endian AB):
UDP PDU フォーマットのレイアウトは次のとおりです (ビッグエンディアン 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rxDatagrams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rxBytes |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| deltaTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqErrLoss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqErrOoo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqErrDup |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarMin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarMax |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarCnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rttVarMinimum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rttVarMaximum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| accumTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | testAction | rxStopped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spduSeqNo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. srStruct (28 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subIntSeqNo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. sisSav (56 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqErrLoss |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqErrOoo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| seqErrDup |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| clockDeltaMin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarMin |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarMax |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayVarCnt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rttMinimum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rttVarSample |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delayMinUpd | reserved1 | reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tiDeltaTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tiRxDatagrams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tiRxBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spduTime_sec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spduTime_nsec |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved3 | reserved4 | authMode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authUnixTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. authDigest (32 octets) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| keyId | reservedAuth1 | checkSum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Status PDU Layout
図 10: ステータス PDU のレイアウト
Note that the Sending Rate structure is defined in Section 7.
送信レート構造はセクション 7 で定義されていることに注意してください。
The primary role of the Status Feedback message is to communicate the traffic conditions at the Load PDU receiver to the Load PDU sender. While the Sub-Interval statistics saved (sisSav) structure covers the most recently saved (completed) Sub-Interval, similar fields directly in the Status PDU itself cover the most recent trial interval (the time period between Status Feedback messages, completed by this Status PDU). Both sets of statistics SHALL always be populated by the Load PDU receiver, regardless of role (client or server).
ステータス フィードバック メッセージの主な役割は、Load PDU 受信側のトラフィック状況を Load PDU 送信側に伝えることです。保存されたサブ間隔統計 (sisSav) 構造は、最後に保存された (完了した) サブ間隔をカバーしますが、ステータス PDU 自体の同様のフィールドは、最新の試行間隔 (このステータス PDU によって完了する、ステータス フィードバック メッセージ間の期間) を直接カバーします。両方の統計セットは、役割 (クライアントまたはサーバー) に関係なく、Load PDU レシーバーによって常に設定されるものとします (SHALL)。
Details on the Status PDU measurement fields are provided in [RFC9097]. The authentication and checkSum fields follow the same methodology as with the Setup Request and Response. Additional information regarding fields not defined previously are as follows:
Status PDU 測定フィールドの詳細は [RFC9097] で提供されています。認証フィールドとチェックサムフィールドは、セットアップ要求と応答の場合と同じ方法に従います。以前に定義されていないフィールドに関する追加情報は次のとおりです。
pduId:
pduId:
IANA has assigned the hex value 0xFEED (Section 12.3.1).
IANA は 16 進値 0xFEED を割り当てました (セクション 12.3.1)。
spduSeqNo:
spduSeqNo:
A four-octet field containing the Status PDU sequence number (starting at 1). Used by the Load PDU sender to detect Status PDU loss (in the unloaded direction). The loss count is communicated back to the Load PDU receiver via spduSeqErr in subsequent Load PDUs.
Status PDU シーケンス番号 (1 から始まる) を含む 4 オクテットのフィールド。ロード PDU 送信者がステータス PDU の損失 (アンロード方向) を検出するために使用します。損失カウントは、後続の Load PDU の spduSeqErr を介して Load PDU 受信機に返されます。
subIntSeqNo:
subIntSeqNo:
A four-octet field containing the Sub-Interval sequence number (starting at 1) that corresponds to the statistics provided in sisSav, for the last saved (completed) Sub-Interval.
最後に保存された (完了した) サブ間隔について、sisSav で提供される統計に対応するサブ間隔シーケンス番号 (1 から始まる) を含む 4 オクテットのフィールド。
sisSav:
sisSav:
Sub-Interval statistics saved (completed) for the most recent Sub-Interval (as designated by the subIntSeqNo). These consist of the following fields:
最新のサブ間隔 (subIntSeqNo で指定) について保存 (完了) されたサブ間隔統計。これらは次のフィールドで構成されます。
rxDatagrams:
rxデータグラム:
A four-octet field Sub-Interval indicating the number of received datagrams during the Sub-Interval.
サブインターバル中に受信したデータグラムの数を示す 4 オクテットのフィールド サブインターバル。
rxBytes:
rxバイト:
An eight-octet field indicating the Sub-Interval byte count (eight octets chosen to prevent overflow at high speeds).
サブインターバルのバイト数を示す 8 オクテットのフィールド (高速でのオーバーフローを防ぐために 8 オクテットが選択されます)。
deltaTime:
デルタ時間:
A four-octet field indicating the exact duration of the Sub-Interval in us. Used to calculate the received traffic rate together with rxBytes.
私たちの中のサブインターバルの正確な期間を示す 4 オクテットのフィールド。rxBytes とともに受信トラフィック レートを計算するために使用されます。
seqErrLoss/seqErrOoo/seqErrDup:
seqErrLoss/seqErrOoo/seqErrDup:
Three four-octet fields populated by the loss, out-of-order, and duplicate totals. Available for both the Sub-Interval and trial interval; it is a breakout of the SeqErrors count in Table 3 of [TR-471]. seqErrOoo and seqErrDup are realized by comparing sequence numbers. A lookback list of the last n sequence numbers received is used as the basis. Each Load PDU sequence number is checked against this lookback. The number n may depend on the implementation and on typical characteristics of environments, where UDPSTP is deployed (like mobile networks or Wi-Fi). Currently, a default sequence number interval of n=32 has been chosen. Specifically for seqErrOoo, each successively received higher seqno sets the next-expected seqno to seqno+1, and anything below that is considered out of order (i.e., delayed). For example, given the sequence 93, 94, 95, 100, 96, 97, 101, 98, 99, 102, 103, ... reception of 96, 97, 98, and 99 would not increment the next-expected seqno and would all be considered out of order.
損失、順序外れ、および重複の合計が入力される 3 つの 4 オクテット フィールド。サブインターバルとトライアルインターバルの両方で使用できます。これは、[TR-471] の表 3 の SeqErrors カウントの内訳です。seqErrOoo と seqErrDup はシーケンス番号を比較することで実現されます。受信した最後の n 個のシーケンス番号のルックバック リストが基礎として使用されます。各 Load PDU シーケンス番号は、このルックバックに対してチェックされます。数値 n は、実装および UDPSTP が展開される環境 (モバイル ネットワークや Wi-Fi など) の典型的な特性に依存する場合があります。現在、デフォルトのシーケンス番号間隔 n=32 が選択されています。特に seqErrOoo の場合、連続して受信した上位の各 seqno は次に期待される seqno を seqno+1 に設定し、それ以下のものは順序が間違っている (つまり、遅延している) と見なされます。たとえば、シーケンス 93、94、95、100、96、97、101、98、99、102、103、... の場合、96、97、98、および 99 の受信は、次に期待されるシーケンス番号をインクリメントせず、すべて順序が間違っていると見なされます。
delayVarMin/delayVarMax/delayVarSum/delayVarCnt:
遅延VarMin/遅延VarMax/遅延VarSum/遅延VarCnt:
Four four-octet fields populated by the one-way delay variation measurements of all received Load PDUs (where avg = sum/cnt). For each Load PDU received, the send time (lpduTime_sec/lpduTime_nsec) is subtracted from the local receive time, which is then normalized by subtracting the current clockDeltaMin. Available for both the Sub-Interval and trial interval.
受信したすべての Load PDU の一方向遅延変動測定値が入力される 4 つの 4 オクテット フィールド (avg = sum/cnt)。受信した Load PDU ごとに、送信時間 (lpduTime_sec/lpduTime_nsec) がローカル受信時間から減算され、現在の ClockDeltaMin を減算することで正規化されます。サブインターバルとトライアルインターバルの両方で使用できます。
rttVarMinimum/rttVarMaximum (in sisSav):
rttVarMinimum/rttVarMinimum (sisSav 内):
Two four-octet fields populated by the minimum and maximum RTT delay variation (rttVarSample) in the Sub-Interval designated by the subIntSeqNo.
subIntSeqNo で指定されたサブインターバル内の最小および最大 RTT 遅延変動 (rttVarSample) が入力される 2 つの 4 オクテット フィールド。
accumTime:
累積時間:
The accumulated time of the test in ms, based on the duration of each Sub-Interval. Equivalent to the sum of each deltaTime (although in ms) sent in each Status PDU during the test.
各サブインターバルの期間に基づく、テストの累積時間 (ミリ秒)。テスト中に各ステータス PDU で送信された各 deltaTime (ミリ秒単位ですが) の合計に相当します。
clockDeltaMin:
クロックデルタ最小:
A four-octet field indicating the minimum clock delta (difference) since the beginning of the test. Obtained by subtracting the send time of each Load PDU (lpduTime_sec/ lpduTime_nsec) from the local time that it was received. This value is initialized with the first Load PDU received and is updated with each subsequent one to maintain a current (and continuously updated) minimum. If the endpoint clocks are sufficiently synchronized, this will be the minimum one-way delay in ms. Otherwise, this value may be negative but still valid for one-way delay variation measurements for the default test duration (default is 10 seconds). If the test duration is extended to a range of minutes, where significant clock drift can occur, synchronized (or at least well-disciplined) clocks may be required.
テスト開始以降の最小クロック デルタ (差分) を示す 4 オクテットのフィールド。各 Load PDU の送信時刻 (lpduTime_sec/lpduTime_nsec) を、受信したローカル時刻から減算して取得します。この値は、最初に受信した Load PDU で初期化され、現在の (継続的に更新される) 最小値を維持するために後続の Load PDU ごとに更新されます。エンドポイントのクロックが十分に同期している場合、これはミリ秒単位の最小片道遅延になります。それ以外の場合、この値は負になる可能性がありますが、デフォルトのテスト期間 (デフォルトは 10 秒) の間の一方向遅延変動測定には依然として有効です。テスト期間が分単位の範囲に延長される場合、重大なクロック ドリフトが発生する可能性があるため、同期された (または少なくともよく規律された) クロックが必要になる場合があります。
rttMinimum (in Status PDU):
rtt最小値 (ステータス PDU 内):
A four-octet field indicating the minimum "adjusted" RTT measured since the beginning of the test. See rttRespDelay (Section 8.1) regarding "adjusted" measurements. RTT is obtained by subtracting the copied spduTime_sec/ spduTime_nsec in the received Load PDU from the local time at which it was received. This minimum SHALL be kept current (and continuously updated) via each Load PDU received with an updated spduTime_sec/spduTime_nsec. This value MUST be positive. Before an initial value can be established, and because zero is itself valid, it SHALL be set to STATUS_NODEL when communicated in the Status PDU.
テストの開始以降に測定された最小の「調整された」RTT を示す 4 オクテットのフィールド。「調整された」測定値については、rttRespDelay (セクション 8.1) を参照してください。RTT は、受信した Load PDU 内のコピーされた spduTime_sec/spduTime_nsec を、受信時のローカル時間から減算することによって取得されます。この最小値は、更新された spduTime_sec/spduTime_nsec で受信された各 Load PDU を通じて最新に維持される (そして継続的に更新される) ものとします (SHALL)。この値は正の値でなければなりません。初期値が確立される前に、ゼロ自体が有効であるため、Status PDU で通信するときに、それを STATUS_NODEL に設定する必要があります (SHALL)。
rttVarSample:
rttVarサンプル:
A four-octet field indicating the most recent "adjusted" RTT delay variation measurement. See rttRespDelay (Section 8.1) regarding "adjusted" measurements. RTT delay variation is obtained by subtracting the current (and continuously updated) "adjusted" RTT minimum, communicated as rttMinimum (in Status PDU), from each "adjusted" RTT measurement (which is itself obtained by subtracting the copied spduTime_sec/spduTime_nsec in the received Load PDU from the local time at which it was received). Note that while one-way delay variation is measured for every Load PDU received, RTT delay variation is only sampled via the Status PDU sent and the very next Load PDU received with the corresponding updated spduTime_sec/spduTime_nsec. When a new value is unavailable (possibly due to packet loss), and because zero is itself valid, it SHALL be set to STATUS_NODEL when communicated in the Status PDU.
最新の「調整された」RTT 遅延変動測定値を示す 4 オクテットのフィールド。「調整された」測定値については、rttRespDelay (セクション 8.1) を参照してください。RTT 遅延変動は、各「調整済み」RTT 測定値から、rttMinimum (Status PDU 内で) として伝達される、現在の (そして継続的に更新されている) 「調整済み」RTT 最小値を減算することによって取得されます (これ自体は、受信した Load PDU 内のコピーされた spduTime_sec/spduTime_nsec を、受信したローカル時間から減算することによって取得されます)。一方向の遅延変動は受信したすべての Load PDU に対して測定されますが、RTT 遅延変動は、送信された Status PDU と、対応する更新された spduTime_sec/spduTime_nsec で受信された次の Load PDU を介してのみサンプリングされることに注意してください。新しい値が利用できない場合 (おそらくパケット損失により)、ゼロ自体が有効であるため、Status PDU で通信するときは、STATUS_NODEL に設定されるものとします (SHALL)。
delayMinUpd:
遅延最小更新:
A one-octet field. Boolean, 0 or 1, indicating that the clockDeltaMin and/or rttMinimum (in Status PDU), as measured by the Load PDU receiver, has been updated.
1 オクテットのフィールド。ブール値、0 または 1。Load PDU レシーバーによって測定された ClockDeltaMin および/または rttMinimum (Status PDU 内) が更新されたことを示します。
tiDeltaTime/tiRxDatagrams/tiRxBytes:
tiDeltaTime/tiRxDatagrams/tiRxBytes:
Three four-octet fields populated by the trial interval time in us, along with the received datagram and byte counts. Used to calculate the received traffic rate for the trial interval.
3 つの 4 オクテット フィールドには、受信したデータグラムとバイト数とともに試行間隔時間が入力されます。試行間隔の受信トラフィック レートを計算するために使用されます。
spduTime_sec/spduTime_nsec:
spduTime_sec/spduTime_nsec:
Two four-octet fields containing the local transmit time of the Status PDU. Expected to be copied into spduTime_sec/spduTime_nsec in subsequent Load PDUs after being received by the Load PDU sender. Used for RTT measurements.
ステータス PDU のローカル送信時間を含む 2 つの 4 オクテット フィールド。Load PDU 送信者によって受信された後、後続の Load PDU の spduTime_sec/spduTime_nsec にコピーされることが予期されます。RTT測定に使用されます。
authMode:
認証モード:
Same as in Section 6.1.
セクション 6.1 と同じ。
authUnixTime:
認証Unix時間:
Same as in Section 6.1.
セクション 6.1 と同じ。
authDigest:
認証ダイジェスト:
Same as in Section 6.1.
セクション 6.1 と同じ。
keyId:
キーID:
Same as in Section 6.1.
セクション 6.1 と同じ。
reservedAuth1:
予約済み認証1:
Same as in Section 6.1.
セクション 6.1 と同じ。
checkSum:
チェックサム:
Same as in Section 6.1.
セクション 6.1 と同じ。
The Status Feedback message PDU (as well as the included Sub-Interval statistics structure) SHALL be organized as follows:
ステータス フィードバック メッセージ PDU (および含まれるサブインターバル統計構造) は、次のように構成されなければなりません (SHALL)。
<CODE BEGINS>
//
// Sub-Interval statistics structure for received traffic information
//
#pragma pack(push, 1)
struct subIntStats {
uint32_t rxDatagrams; // Received datagrams
uint64_t rxBytes; // Received bytes (64 bits)
uint32_t deltaTime; // Time delta (us)
uint32_t seqErrLoss; // Loss sum
uint32_t seqErrOoo; // Out-of-order sum
uint32_t seqErrDup; // Duplicate sum
uint32_t delayVarMin; // Delay variation minimum (ms)
uint32_t delayVarMax; // Delay variation maximum (ms)
uint32_t delayVarSum; // Delay variation sum (ms)
uint32_t delayVarCnt; // Delay variation count
uint32_t rttVarMinimum; // Minimum RTT variation (ms)
uint32_t rttVarMaximum; // Maximum RTT variation (ms)
uint32_t accumTime; // Accumulated time (ms)
};
#pragma pack(pop)
//
// Status Feedback header for UDP payload of status PDUs
//
struct statusHdr {
#define STATUS_ID 0xFEED
uint16_t pduId; // PDU ID
uint8_t testAction; // Test action
uint8_t rxStopped; // Receive traffic stopped (BOOL)
uint32_t spduSeqNo; // Status PDU sequence number
struct sendingRate srStruct; // Sending Rate structure
uint32_t subIntSeqNo; // Sub-Interval sequence number
struct subIntStats sisSav; // Sub-Interval stats saved
uint32_t seqErrLoss; // Loss sum
uint32_t seqErrOoo; // Out-of-order sum
uint32_t seqErrDup; // Duplicate sum
uint32_t clockDeltaMin; // Clock delta minimum (ms)
uint32_t delayVarMin; // Delay variation minimum (ms)
uint32_t delayVarMax; // Delay variation maximum (ms)
uint32_t delayVarSum; // Delay variation sum (ms)
uint32_t delayVarCnt; // Delay variation count
#define STATUS_NODEL UINT32_MAX // No delay data/value
uint32_t rttMinimum; // Min round-trip time sampled (ms)
uint32_t rttVarSample; // Last round-trip time sample (ms)
uint8_t delayMinUpd; // Delay minimum(s) updated (BOOL)
uint8_t reserved1; // (reserved for alignment)
uint16_t reserved2; // (reserved for alignment)
uint32_t tiDeltaTime; // Trial interval delta time (us)
uint32_t tiRxDatagrams; // Trial interval receive datagrams
uint32_t tiRxBytes; // Trial interval receive bytes
uint32_t spduTime_sec; // Send time of this status PDU
uint32_t spduTime_nsec; // Send time of this status PDU
uint16_t reserved3; // (reserved for alignment)
uint8_t reserved4; // (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 11: Status PDU
図 11: ステータス PDU
When the test duration timer (testIntTime) on the server expires, it SHALL set the local connection test action to TEST_ACT_STOP1 (phase 1 of graceful termination). This is simply a non-reversible state awaiting the next message(s) to be sent from the server. During this time, any received Load or Status PDUs are processed normally.
サーバー上のテスト期間タイマー (testIntTime) が期限切れになると、サーバーはローカル接続テスト アクションを TEST_ACT_STOP1 (正常な終了のフェーズ 1) に設定するものとします (SHALL)。これは単に、サーバーから送信される次のメッセージを待っている、元に戻せない状態です。この間、受信したロード PDU またはステータス PDU は通常どおり処理されます。
Upon transmission of the next Load or Status PDUs, the server SHALL set the local connection test action to TEST_ACT_STOP2 (phase 2 of graceful termination) and mark any outgoing PDUs with a testAction value of TEST_ACT_STOP2. While in this state, the server MAY reduce any Load PDU bursts to a size of one.
次のロード PDU またはステータス PDU の送信時に、サーバーはローカル接続テスト アクションを TEST_ACT_STOP2 (正常な終了のフェーズ 2) に設定し、すべての送信 PDU に testAction 値 TEST_ACT_STOP2 をマークするものとします(SHALL)。この状態にある間、サーバーは Load PDU バーストをサイズ 1 に縮小してもよい(MAY)。
When the client receives a Load or Status PDU with the TEST_ACT_STOP2 indication, it SHALL finalize testing, display the test results, and mark its local connection with a test action of TEST_ACT_STOP2 (so that any PDUs subsequently received can be ignored).
クライアントが TEST_ACT_STOP2 指示を持つ Load または Status PDU を受信すると、テストを終了し、テスト結果を表示し、ローカル接続に TEST_ACT_STOP2 のテスト アクションをマークするものとします (そのため、その後受信した PDU は無視できます)。
With the test action of the client's connection set to TEST_ACT_STOP2, the very next expiry of a send timer, for either a Load or a Status PDU, SHALL result in it and any subsequent PDUs being sent with a testAction value of TEST_ACT_STOP2 (as confirmation to the server). While in this state, the client MAY reduce any Load PDU bursts to a size of one. The client SHALL then schedule an immediate end time for the connection.
クライアントの接続のテスト アクションが TEST_ACT_STOP2 に設定されている場合、Load または Status PDU の送信タイマーが次に期限切れになると、それ以降の PDU は testAction 値 TEST_ACT_STOP2 (サーバーへの確認として) で送信されるものとします (SHALL)。この状態にある間、クライアントは Load PDU バーストをサイズ 1 に縮小してもよい(MAY)。その後、クライアントは接続の即時終了時刻をスケジュールするものとします(SHALL)。
When the server receives the TEST_ACT_STOP2 confirmation in the Load or Status PDU, the server SHALL schedule an immediate end time for the connection that closes the socket and deallocates the associated resources. The TEST_ACT_STOP2 exchange constitutes a graceful termination of the test.
サーバーがロード PDU またはステータス PDU で TEST_ACT_STOP2 確認を受信した場合、サーバーはソケットを閉じ、関連するリソースの割り当てを解除する接続の即時終了時刻をスケジュールするものとします(SHALL)。TEST_ACT_STOP2 交換は、テストの正常な終了を構成します。
In a non-graceful test stop due to path failure, the watchdog timeouts at each endpoint will expire (sometimes at one endpoint first); notifications in logs, STDOUT, and/or formatted output SHALL be made; and the endpoint SHALL schedule an immediate end time for the connection.
パス障害による非正常なテスト停止では、各エンドポイントでウォッチドッグ タイムアウトが期限切れになります (最初に 1 つのエンドポイントで終了する場合もあります)。ログ、STDOUT、および/またはフォーマットされた出力での通知が行われる必要があります。そしてエンドポイントは接続の即時終了時刻をスケジュールするものとします(SHALL)。
If an attacker clears the TEST_ACT_STOP2 indication, then the configured test duration timer (testIntTime) at the server and client SHALL take precedence and the endpoint SHALL schedule an immediate end time for the connection.
攻撃者が TEST_ACT_STOP2 指示をクリアした場合、サーバーとクライアントで設定されたテスト期間タイマー (testIntTime) が優先され、エンドポイントは接続の即時終了時刻をスケジュールするものとします (SHALL)。
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.
この方法のアーキテクチャでは、Src (テスト パケット送信者) と Dst (受信者) の役割で動作する 2 つの協調ホストが必要で、その間に測定パスとリターン パスが存在します。
The nominal duration of a measurement interval at the Destination, parameter testIntTime, 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.
実稼働ネットワークでは、宛先での測定間隔の公称期間、パラメータ testIntTime を制限する必要があります。これは、これがアクティブなテスト方法であり、テスト中に Src から Dst へのホスト パスで輻輳が発生する可能性があるためです。
It is RECOMMENDED to locate test endpoints as close to the intended measured link(s) as practical. The testing operator MUST set a value for the MaxHops parameter, based on the expected path length. This parameter can keep measurement traffic from straying too far beyond the intended path.
テスト エンドポイントは、実際的には対象となる測定リンクにできるだけ近い場所に配置することをお勧めします。テストオペレータは、予想されるパス長に基づいて、MaxHops パラメータの値を設定しなければなりません (MUST)。このパラメータにより、測定トラフィックが意図したパスを超えて逸脱するのを防ぐことができます。
It is obviously counterproductive to run more than one independent and concurrent test (regardless of the number of flows in the test stream) when attempting to measure the maximum capacity on a single path. The number of concurrent, independent tests of a path SHALL be limited to one.
単一パスの最大容量を測定しようとする場合、(テスト ストリーム内のフローの数に関係なく) 複数の独立した同時テストを実行することは、明らかに逆効果です。パスの同時独立テストの数は 1 つに制限されるものとします (SHALL)。
The load rate adjustment algorithm's scope is limited to helping determine the Maximum IP-Layer Capacity in the context of an infrequent, diagnostic, short-term measurement. It is RECOMMENDED to discontinue non-measurement traffic that shares a subscriber's dedicated resources while testing: measurements may not be accurate, and throughput of competing elastic traffic may be greatly reduced.
負荷率調整アルゴリズムの範囲は、頻度の低い、診断用の短期間の測定のコンテキストでの最大 IP 層容量の決定を支援することに限定されています。テスト中は加入者の専用リソースを共有する非測定トラフィックを中止することが推奨されます。測定は正確ではない可能性があり、競合するエラスティック トラフィックのスループットが大幅に低下する可能性があります。
See Section 8 of [RFC9097] for a discussion of the Method of Measurement beyond purely operational aspects.
純粋に運用上の側面を超えた測定方法の議論については、[RFC9097] のセクション 8 を参照してください。
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.
特定の状況では追加の測定が役立つ場合があります。たとえば、クライアント アプリケーションが、サービス加入者の場所との間で送受信されるすべてのトラフィックを認識するインターフェイスにアクセスできる場合、住宅用ゲートウェイでクライアントによって測定されるインターフェイス バイト カウンタが可能になります。ダウンロードまたはアップロードの指示用にクライアントにバイト カウンタを追加すると、合計トラフィックを測定し、テスト以外のトラフィックが存在するとき (および容量を使用しているとき) を検出できる可能性があります。クライアントには、インターフェイス トラフィックと IP 層キャパシティの両方を同時にカウントできる CPU サイクルがない可能性があるため、この形式の診断測定は不可能な場合があります。
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].
アクティブなメトリクスと測定には、セキュリティに関する考慮事項の長い歴史があります。ここでは、ライブ パスのアクティブな測定に適用されるセキュリティに関する考慮事項が関係します。[RFC4656] および [RFC5357] を参照してください。
When considering privacy of users activating measurements as a service or users whose traffic is measured, the sensitive information available to potential observers is greatly reduced when using active techniques that are within this scope of work. Passive observations of user traffic for measurement purposes raise many privacy issues. See the privacy considerations described in the LMAP Framework [RFC7594], which covers active and passive techniques.
サービスとしての測定をアクティブ化するユーザー、またはトラフィックが測定されるユーザーのプライバシーを考慮する場合、この作業範囲内のアクティブな技術を使用すると、潜在的な観察者が入手できる機密情報が大幅に減少します。測定目的でユーザー トラフィックを受動的に観察すると、プライバシーに関する多くの問題が生じます。アクティブおよびパッシブ技術について説明している LMAP フレームワーク [RFC7594] で説明されているプライバシーに関する考慮事項を参照してください。
Below are some new considerations for capacity measurement as described in this document.
以下に、このドキュメントで説明されている容量測定に関する新しい考慮事項をいくつか示します。
1. Cooperating client and server hosts and agreements to test the path between the hosts are REQUIRED. Hosts perform in either the server or the client roles. One way to assure a cooperative agreement employs the optional Authorization mode is through the use of the authDigest field and the known identity associated with the shared key used to create the authDigest field via the KDF. Other means are also possible, such as access control lists at the server.
1. クライアントとサーバーのホストを連携させ、ホスト間のパスをテストするための合意が必要です。ホストは、サーバーまたはクライアントの役割のいずれかで実行されます。協力協定でオプションの認可モードを確実に使用する 1 つの方法は、authDigest フィールドと、KDF を介して authDigest フィールドの作成に使用される共有キーに関連付けられた既知の ID を使用することです。サーバーのアクセス制御リストなど、他の手段も可能です。
2. It is REQUIRED to have a user client-initiated setup handshake between cooperating hosts that allows firewalls to control inbound unsolicited UDP traffic that goes to either a control port or ephemeral ports that are only created as needed. Firewalls protecting each host can continue to do their jobs normally.
2. 制御ポートまたは必要に応じてのみ作成される一時ポートのいずれかに送信される、一方的な受信 UDP トラフィックをファイアウォールが制御できるようにするために、連携するホスト間でユーザー クライアントが開始するセットアップ ハンドシェイクを行うことが必須です。各ホストを保護するファイアウォールは、通常どおりの作業を続行できます。
3. Client-server authentication and integrity protection for feedback messages conveying measurements is RECOMMENDED. To accommodate different host limitations and testing circumstances, different modes of operation are available, as described in Section 5.
3. クライアントサーバー認証と、測定値を伝えるフィードバックメッセージの完全性保護が推奨されます。さまざまなホストの制限やテスト環境に対応するために、セクション 5 で説明するように、さまざまな動作モードが利用可能です。
4. Hosts MUST limit the number of simultaneous tests to avoid resource exhaustion and inaccurate results.
4. ホストは、リソースの枯渇と不正確な結果を避けるために、同時テストの数を制限しなければなりません (MUST)。
5. Senders MUST be rate-limited. This can be accomplished using a pre-built table defining all the offered sending rates that will be supported. The default and optional load rate adjustment algorithm results in "ramp up" from the lowest rate in the table. Optionally, the server could utilize the maxBandwidth field (and the CHSR_USDIR_BIT bit) in the Setup Request from the client to limit the maximum that it will attempt to achieve.
5. 送信者はレート制限されなければなりません。これは、サポートされる提供されるすべての送信レートを定義する事前作成されたテーブルを使用して実現できます。デフォルトおよびオプションの負荷率調整アルゴリズムでは、表内の最も低い負荷率から「ランプアップ」が行われます。オプションで、サーバーはクライアントからのセットアップ要求の maxBandwidth フィールド (および CHSR_USDIR_BIT ビット) を利用して、達成しようとする最大値を制限できます。
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).
6. データ量が限られているサービス加入者が広範な容量テストを実施すると、サービスに対するサービス プロバイダーの制御の影響を受ける可能性があります。サービスプロバイダーの測定ホストを使用したテストは、テストトラフィックの頻度および/または全体量を制限する必要があります(たとえば、テスト間隔の継続時間の値の範囲を制限する必要があります)。
One specific attack that has been recognized is an on-path attack on the testAction field where the attacker would set or clear the STOP indication. Setting the indication in successive packets terminates the test prematurely, with no threat to the Internet but annoyance for the testers. If an attacker clears the STOP indication, 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.
認識されている特定の攻撃の 1 つは、攻撃者が STOP 指示を設定またはクリアする testAction フィールドに対するオンパス攻撃です。連続するパケットに表示を設定すると、テストが途中で終了し、インターネットに対する脅威はありませんが、テスターにとっては迷惑になります。攻撃者が STOP 指示をクリアした場合、軽減策はクライアントとサーバーでのテスト期間の情報に依存します。指定されたテスト期間が完了すると、これらのホストはすべてのトラフィックを停止します。
Authentication methods and requirements steadily evolve. Alternate authentication modes provide for algorithm agility by defining a new mode, whose support is indicated by assigning a suitable "Test Setup PDU Authentication Mode" registry value (see Section 12.3.4 ).
認証方法と要件は着実に進化しています。代替認証モードは、新しいモードを定義することによってアルゴリズムの機敏性を提供します。そのサポートは、適切な「テスト セットアップ PDU 認証モード」レジストリ値を割り当てることによって示されます (セクション 12.3.4 を参照)。
Per this document, IANA has assigned a UDP port number for the Test Setup exchange in the Control phase of protocol operation and has created a new registry group for the UDPSTP.
この文書に従って、IANA はプロトコル操作の制御フェーズでのテスト セットアップ交換に UDP ポート番号を割り当て、UDPSTP 用の新しいレジストリ グループを作成しました。
IANA has registered the following service name in the "Service Name and Transport Protocol Port Number Registry":
IANA は、次のサービス名を「サービス名およびトランスポート プロトコル ポート番号レジストリ」に登録しています。
Service Name:
サービス名：
udpstp
udpstp
Port Number:
ポート番号:
24601
24601
Transport Protocol:
トランスポートプロトコル:
udp
udp
Description:
説明：
UDP-based IP-Layer Capacity and Performance Measurement protocol
UDP ベースの IP 層の容量およびパフォーマンス測定プロトコル
Assignee:
譲受人:
IESG <iesg@ietf.org>
IESG <iesg@ietf.org>
Contact:
接触：
IETF Chair <chair@ietf.org>
IETF 議長 <chair@ietf.org>
Reference:
参照：
RFC 9946
RFC 9946
The protocol uses IP-Layer Unicast. A single port number was assigned to help configure firewalls and other port-based systems for access control prior to negotiating dynamic ports between client and server.
このプロトコルは IP 層ユニキャストを使用します。クライアントとサーバーの間で動的ポートをネゴシエートする前に、アクセス制御用にファイアウォールやその他のポートベースのシステムを構成しやすくするために、単一のポート番号が割り当てられました。
IANA has added the following KDF entry to the "KeyTable KDFs" registry (see <https://www.iana.org/assignments/keytable>):
IANA は、次の KDF エントリを「KeyTable KDFs」レジストリに追加しました (<https://www.iana.org/assignments/keytable> を参照)。
+==============+=============================+===========+
| KDF | Description | Reference |
+==============+=============================+===========+
| HMAC-SHA-256 | HMAC using the SHA-256 hash | [RFC6234] |
+--------------+-----------------------------+-----------+
Table 1: KeyTable KDFs Registry
表 1: KeyTable KDF レジストリ
IANA has created the registries in the subsections that follow under a new registry group called "UDP Speed Test Protocol (UDPSTP)".
IANA は、「UDP Speed Test Protocol (UDPSTP)」と呼ばれる新しいレジストリ グループの下に、以下のサブセクションのレジストリを作成しました。
IANA has added the following note under the "UDP Speed Test Protocol (UDPSTP)" registry group:
IANA は、「UDP Speed Test Protocol (UDPSTP)」レジストリ グループに次のメモを追加しました。
Note: Values reserved for Experimental Use are not expected to be used on the Internet but are expected to be used for experiments that are confined to closed environments.
注: 実験用に予約されている値は、インターネット上での使用は想定されていませんが、閉じた環境に限定された実験での使用が想定されています。
IANA has created the "PDU Identifier" registry under the "UDP Speed Test Protocol (UDPSTP)" registry group. Every UDPSTP PDU contains a two-octet pduId field identifying the role and format of the PDU that follows. The code points in this registry are allocated according to the registration procedures [RFC8126] described in Table 2.
IANA は、「UDP Speed Test Protocol (UDPSTP)」レジストリ グループの下に「PDU Identifier」レジストリを作成しました。すべての UDPSTP PDU には、後続の PDU の役割と形式を識別する 2 オクテットの pduId フィールドが含まれています。このレジストリ内のコード ポイントは、表 2 に記載されている登録手順 [RFC8126] に従って割り当てられます。
+===============+=========================+
| Range | Registration Procedures |
+===============+=========================+
| 0x0000 | Reserved |
+---------------+-------------------------+
| 0x0001-0x7F00 | Specification Required |
+---------------+-------------------------+
| 0x7F01-0x7FE0 | Experimental Use |
+---------------+-------------------------+
| 0x7FE1-0x7FFF | Private Use |
+---------------+-------------------------+
| 0x8000-0xFFFE | IETF Review |
+---------------+-------------------------+
| 0xFFFF | Reserved |
+---------------+-------------------------+
Table 2: Registration Procedures for the PDU Identifier Registry
表 2: PDU 識別子レジストリの登録手順
IANA has assigned values in the "PDU Identifier" registry as follows:
IANA は、「PDU 識別子」レジストリの値を次のように割り当てています。
+===============+===============================+===========+
| Value | Description | Reference |
+===============+===============================+===========+
| 0x0000 | Reserved | RFC 9946 |
+---------------+-------------------------------+-----------+
| 0x7F01-0x7FE0 | Reserved for Experimental Use | RFC 9946 |
+---------------+-------------------------------+-----------+
| 0x7FE1-0x7FFF | Reserved for Private Use | RFC 9946 |
+---------------+-------------------------------+-----------+
| 0xACE1 | Test Setup PDU | RFC 9946 |
+---------------+-------------------------------+-----------+
| 0xACE2 | Test Activation PDU | RFC 9946 |
+---------------+-------------------------------+-----------+
| 0xBEEF | Load PDU | RFC 9946 |
+---------------+-------------------------------+-----------+
| 0xDEAD | Null PDU | RFC 9946 |
+---------------+-------------------------------+-----------+
| 0xFEED | Status Feedback PDU | RFC 9946 |
+---------------+-------------------------------+-----------+
| 0xFFFF | Reserved | RFC 9946 |
+---------------+-------------------------------+-----------+
Table 3: Initial Values of the PDU Identifier Registry
表 3: PDU 識別子レジストリの初期値
IANA has created the "Protocol Version" registry under the "UDP Speed Test Protocol (UDPSTP)" registry group. UDPSTP Test Setup Request, Test Setup Response, and Test Activation Request PDUs contain a two-octet protocolVer field, identifying the version of the protocol in use. The code points in this registry are allocated according to the registration procedures [RFC8126] described in Table 4.
IANA は、「UDP Speed Test Protocol (UDPSTP)」レジストリ グループの下に「Protocol Version」レジストリを作成しました。UDPSTP テスト セットアップ リクエスト、テスト セットアップ レスポンス、およびテスト アクティベーション リクエスト PDU には、使用中のプロトコルのバージョンを識別する 2 オクテットのprotocolVer フィールドが含まれています。このレジストリ内のコード ポイントは、表 4 に記載されている登録手順 [RFC8126] に従って割り当てられます。
+=============+=========================+
| Range | Registration Procedures |
+=============+=========================+
| 0-19 | Reserved |
+-------------+-------------------------+
| 20-40960 | IETF Review |
+-------------+-------------------------+
| 40961-53248 | Specification Required |
+-------------+-------------------------+
| 53249-65534 | Experimental Use |
+-------------+-------------------------+
| 65535 | Reserved |
+-------------+-------------------------+
Table 4: Registration Procedures for the Protocol Version Registry
表 4: プロトコル バージョン レジストリの登録手順
IANA has assigned decimal value 20 in the "Protocol Version" registry as follows:
IANA は、次のように「プロトコル バージョン」レジストリに 10 進数値 20 を割り当てました。
+=======+===========+
| Value | Reference |
+=======+===========+
| 20 | RFC 9946 |
+-------+-----------+
Table 5: Initial Value of the Protocol Version Registry
表 5: プロトコル バージョン レジストリの初期値
IANA has created the "Test Setup PDU Modifier Bitmap" registry under the "UDP Speed Test Protocol (UDPSTP)" registry group. The Test Setup PDU layout contains a modifierBitmap field. The bitmaps in this registry are allocated according to the registration procedures [RFC8126] described in Table 6.
IANA は、「UDP Speed Test Protocol (UDPSTP)」レジストリ グループの下に「Test Setup PDU Modifier Bitmap」レジストリを作成しました。テスト セットアップ PDU レイアウトには modifierBitmap フィールドが含まれています。このレジストリ内のビットマップは、表 6 で説明されている登録手順 [RFC8126] に従って割り当てられます。
+===================+=========================+
| Range | Registration Procedures |
+===================+=========================+
| 00000000-01111111 | IETF Review |
+-------------------+-------------------------+
| 10000000 | Reserved |
+-------------------+-------------------------+
Table 6: Registration Procedures for the Test Setup PDU Modifier Bitmap Registry
表 6: テスト セットアップ PDU 修飾子ビットマップ レジストリの登録手順
IANA has assigned bitmap values in the "Test Setup PDU Modifier Bitmap" registry as follows:
IANA は、「Test Setup PDU Modifier Bitmap」レジストリのビットマップ値を次のように割り当てています。
+=======+===============================+===========+
| Value | Description | Reference |
+=======+===============================+===========+
| 0x00 | No modifications | RFC 9946 |
+-------+-------------------------------+-----------+
| 0x01 | Allow Jumbo datagram sizes | RFC 9946 |
| | above sending rates of 1 Gbps | |
+-------+-------------------------------+-----------+
| 0x02 | Use Traditional MTU (1500 | RFC 9946 |
| | bytes with an IP header) | |
+-------+-------------------------------+-----------+
Table 7: Initial Values of the Test Setup PDU Modifier Bitmap Registry
表 7: テスト セットアップ PDU 修飾子ビットマップ レジストリの初期値
IANA has created the "Test Setup PDU Authentication Mode" registry under the "UDP Speed Test Protocol (UDPSTP)" registry group. The Test Setup PDU layout contains an authMode field. The code points in this registry are allocated according to the registration procedures [RFC8126] described in Table 8.
IANA は、「UDP Speed Test Protocol (UDPSTP)」レジストリ グループの下に「Test Setup PDU Authentication Mode」レジストリを作成しました。テスト セットアップ PDU レイアウトには、authMode フィールドが含まれています。このレジストリ内のコード ポイントは、表 8 で説明されている登録手順 [RFC8126] に従って割り当てられます。
+========+=========================+
| Range | Registration Procedures |
+========+=========================+
| 0-59 | IETF Review |
+--------+-------------------------+
| 60-63 | Experimental Use |
+--------+-------------------------+
| 64-255 | Reserved |
+--------+-------------------------+
Table 8: Registration Procedures for the Test Setup PDU Authentication Mode Registry
表 8: テスト セットアップ PDU 認証モード レジストリの登録手順
IANA has assigned decimal values in the "Test Setup PDU Authentication Mode" registry as follows:
IANA は、「Test Setup PDU Authentication Mode」レジストリに次のように 10 進数値を割り当てました。
+=======+===============================================+===========+
| Value | Description | Reference |
+=======+===============================================+===========+
| 0 | Not used | RFC 9946 |
+-------+-----------------------------------------------+-----------+
| 1 | Required authentication for | RFC 9946 |
| | the Control phase | |
+-------+-----------------------------------------------+-----------+
| 2 | Required authentication for | RFC 9946 |
| | the Control and Data phases | |
+-------+-----------------------------------------------+-----------+
Table 9: Initial Values of the Test Setup PDU Authentication Mode Registry
表 9: テスト セットアップ PDU 認証モード レジストリの初期値
IANA has created the "Test Setup PDU Command Response Field" registry under the "UDP Speed Test Protocol (UDPSTP)" registry group. The Test Setup PDU layout contains a cmdResponse field. The code points in this registry are allocated according to the registration procedures [RFC8126] described in Table 10.
IANA は、「UDP Speed Test Protocol (UDPSTP)」レジストリ グループの下に「Test Setup PDU Command Response Field」レジストリを作成しました。テスト セットアップ PDU レイアウトには cmdResponse フィールドが含まれています。このレジストリ内のコード ポイントは、表 10 に記載されている登録手順 [RFC8126] に従って割り当てられます。
+=========+=========================+
| Range | Registration Procedures |
+=========+=========================+
| 0-127 | IETF Review |
+---------+-------------------------+
| 128-239 | Specification Required |
+---------+-------------------------+
| 240-249 | Experimental Use |
+---------+-------------------------+
| 250-254 | Private Use |
+---------+-------------------------+
| 255 | Reserved |
+---------+-------------------------+
Table 10: Registration Procedures for the Test Setup PDU Command Response Field Registry
表 10: テスト セットアップ PDU コマンド応答フィールド レジストリの登録手順
IANA has assigned decimal values in the "Test Setup PDU Command Response Field" registry as follows:
IANA は、「Test Setup PDU Command Response Field」レジストリに次のように 10 進数値を割り当てました。
+=========+============================================+===========+
| Value | Description | Reference |
+=========+============================================+===========+
| 0 | None (used by client in Request) | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 1 | Acknowledgment | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 2 | Bad protocol version | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 3 | Invalid Jumbo datagram option | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 4 | Unexpected authentication in Setup Request | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 5 | Authentication missing in Setup Request | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 6 | Invalid authentication method | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 7 | Authentication failure | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 8 | Authentication time is invalid in Setup | RFC 9946 |
| | Request | |
+---------+--------------------------------------------+-----------+
| 9 | No maximum test bit rate specified | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 10 | Server maximum bit rate exceeded | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 11 | MTU option does not match server | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 12 | Multi-connection parameters rejected by | RFC 9946 |
| | server | |
+---------+--------------------------------------------+-----------+
| 13 | Connection allocation failure on server | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 240-249 | Reserved for Experimental Use | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 250-254 | Reserved for Private Use | RFC 9946 |
+---------+--------------------------------------------+-----------+
| 255 | Reserved | RFC 9946 |
+---------+--------------------------------------------+-----------+
Table 11: Initial Values of the Test Setup PDU Command Response Field Registry
表 11: テスト セットアップ PDU コマンド応答フィールド レジストリの初期値
Note that value 4 is required for backward compatibility with previous experimental versions of software already in use. Further, value 6 signals that a client erroneously used an authMode that hasn't been standardized yet (i.e., authMode is greater than 1 or 2).
値 4 は、すでに使用されているソフトウェアの以前の実験バージョンとの下位互換性のために必要であることに注意してください。さらに、値 6 は、クライアントがまだ標準化されていない authMode を誤って使用したことを示します (つまり、authMode が 1 または 2 より大きい)。
IANA has created the "Test Activation PDU Command Request" registry under the "UDP Speed Test Protocol (UDPSTP)" registry group. The Test Setup PDU layout contains a cmdRequest field. The code points in this registry are allocated according to the registration procedures [RFC8126] described in Table 12.
IANA は、「UDP Speed Test Protocol (UDPSTP)」レジストリ グループの下に「Test Activation PDU Command Request」レジストリを作成しました。テスト セットアップ PDU レイアウトには cmdRequest フィールドが含まれています。このレジストリ内のコード ポイントは、表 12 に記載されている登録手順 [RFC8126] に従って割り当てられます。
+=========+=========================+
| Range | Registration Procedures |
+=========+=========================+
| 0-127 | IETF Review |
+---------+-------------------------+
| 128-239 | Specification Required |
+---------+-------------------------+
| 240-249 | Experimental Use |
+---------+-------------------------+
| 250-254 | Private Use |
+---------+-------------------------+
| 255 | Reserved |
+---------+-------------------------+
Table 12: Registration Procedures for the Test Activation PDU Command Request Registry
表 12: Test Activation PDU コマンド要求レジストリの登録手順
IANA has assigned decimal values in the "Test Activation PDU Command Request" registry as follows:
IANA は、「Test Activation PDU Command Request」レジストリに次のように 10 進数値を割り当てました。
+=========+==============================+===========+
| Value | Description | Reference |
+=========+==============================+===========+
| 0 | No Request | RFC 9946 |
+---------+------------------------------+-----------+
| 1 | Request test in upstream | RFC 9946 |
| | direction (client to server) | |
+---------+------------------------------+-----------+
| 2 | Request test in downstream | RFC 9946 |
| | direction (server to client) | |
+---------+------------------------------+-----------+
| 240-249 | Reserved for Experimental | RFC 9946 |
| | Use | |
+---------+------------------------------+-----------+
| 250-254 | Reserved for Private Use | RFC 9946 |
+---------+------------------------------+-----------+
| 255 | Reserved | RFC 9946 |
+---------+------------------------------+-----------+
Table 13: Initial Values of the Test Activation PDU Command Request Registry
表 13: Test Activation PDU コマンド要求レジストリの初期値
IANA has created the "Test Activation PDU Modifier Bitmap" registry under the "UDP Speed Test Protocol (UDPSTP)" registry group. The Test Activation PDU layout (also) contains a modifierBitmap field. The bitmaps in this registry are allocated according to the registration procedures [RFC8126] described in Table 14.
IANA は、「UDP Speed Test Protocol (UDPSTP)」レジストリ グループの下に「Test Activation PDU Modifier Bitmap」レジストリを作成しました。Test Activation PDU レイアウトには、(また) modifierBitmap フィールドが含まれています。このレジストリ内のビットマップは、表 14 で説明されている登録手順 [RFC8126] に従って割り当てられます。
+===================+=========================+
| Range | Registration Procedures |
+===================+=========================+
| 00000000-01111111 | IETF Review |
+-------------------+-------------------------+
| 10000000 | Reserved |
+-------------------+-------------------------+
Table 14: Registration Procedures for the Test Activation PDU Modifier Bitmap Registry
表 14: Test Activation PDU Modifier Bitmap Registry の登録手順
IANA has assigned bitmap values in the "Test Activation PDU Modifier Bitmap" registry as follows:
IANA は、「Test Activation PDU Modifier Bitmap」レジストリ内のビットマップ値を次のように割り当てています。
+=======+===============================================+===========+
| Value | Description | Reference |
+=======+===============================================+===========+
| 0x00 | No modifications | RFC 9946 |
+-------+-----------------------------------------------+-----------+
| 0x01 | Set when srIndexConf is | RFC 9946 |
| | start rate for search | |
+-------+-----------------------------------------------+-----------+
| 0x02 | Set for randomized UDP | RFC 9946 |
| | payload | |
+-------+-----------------------------------------------+-----------+
Table 15: Initial Values of the Test Activation PDU Modifier Bitmap Registry
表 15: Test Activation PDU 修飾子ビットマップ レジストリの初期値
IANA has created the "Test Activation PDU Rate Adjustment Algo" registry under the "UDP Speed Test Protocol (UDPSTP)" registry group. The Test Activation PDU layout contains a rateAdjAlgo field. The code points in this registry are allocated according to the registration procedures [RFC8126] described in Table 16.
IANA は、「UDP Speed Test Protocol (UDPSTP)」レジストリ グループの下に「Test Activation PDU Rate Adjustment Algo」レジストリを作成しました。Test Activation PDU レイアウトには、rateAdjAlgo フィールドが含まれています。このレジストリ内のコード ポイントは、表 16 で説明されている登録手順 [RFC8126] に従って割り当てられます。
+=======+=========================+
| Range | Registration Procedures |
+=======+=========================+
| A-Y | IETF Review |
+-------+-------------------------+
| Z | Reserved |
+-------+-------------------------+
Table 16: Registration Procedures for the Test Activation PDU Rate Adjustment Algo Registry
表 16: テスト アクティベーション PDU レート調整アルゴ レジストリの登録手順
IANA has added the following note under the "Test Activation PDU Rate Adjustment Algo" registry:
IANA は、「Test Activation PDU Rate Adjustment Algo」レジストリに次の注記を追加しました。
Note: The algorithm identifier is a capitalized alphabetic UTF-8 value (A-Z), specified by the corresponding incremental numeric.
注: アルゴリズム識別子は、大文字のアルファベットの UTF-8 値 (A ～ Z) であり、対応する増分数値で指定されます。
IANA has assigned capitalized alphabetic UTF-8 values, as well as the corresponding incremental numeric values, in the "Test Activation PDU Rate Adjustment Algo" registry as follows:
IANA は、「Test Activation PDU Rate Adjustment Algo」レジストリで、大文字アルファベットの UTF-8 値と、対応する増分数値を次のように割り当てています。
+================+=======================+==============+
| Value(Numeric) | Description | Reference |
+================+=======================+==============+
| A(n/a) | Not used | RFC 9946 |
+----------------+-----------------------+--------------+
| B(0) | Rate algorithm Type B | [Y.1540Amd2] |
+----------------+-----------------------+--------------+
| C(1) | Rate algorithm Type C | [TR-471] |
+----------------+-----------------------+--------------+
Table 17: Initial Values of the Test Activation PDU Rate Adjustment Algo Registry
表 17: テスト アクティベーション PDU レート調整アルゴ レジストリの初期値
IANA has created the "Test Activation PDU Command Response Field" registry under the "UDP Speed Test Protocol (UDPSTP)" registry group. The Test Activation PDU layout (also) contains a cmdResponse field. The code points in this registry are allocated according to the registration procedures [RFC8126] described in Table 18.
IANA は、「UDP Speed Test Protocol (UDPSTP)」レジストリ グループの下に「Test Activation PDU Command Response Field」レジストリを作成しました。Test Activation PDU レイアウトには、cmdResponse フィールドも含まれています。このレジストリ内のコード ポイントは、表 18 で説明されている登録手順 [RFC8126] に従って割り当てられます。
+=========+=========================+
| Range | Registration Procedures |
+=========+=========================+
| 0-127 | IETF Review |
+---------+-------------------------+
| 128-239 | Specification Required |
+---------+-------------------------+
| 240-249 | Experimental Use |
+---------+-------------------------+
| 250-254 | Private Use |
+---------+-------------------------+
| 255 | Reserved |
+---------+-------------------------+
Table 18: Registration Procedures for the Test Activation PDU Command Response Field Registry
表 18: Test Activation PDU コマンド応答フィールド レジストリの登録手順
IANA has assigned decimal values in the "Test Activation PDU Command Response Field" registry as follows:
IANA は、「Test Activation PDU Command Response Field」レジストリに次のように 10 進数値を割り当てました。
+=========+==================================+===========+
| Value | Description | Reference |
+=========+==================================+===========+
| 0 | None (used by client in Request) | RFC 9946 |
+---------+----------------------------------+-----------+
| 1 | Server acknowledgment | RFC 9946 |
+---------+----------------------------------+-----------+
| 2 | Server indicates an error | RFC 9946 |
+---------+----------------------------------+-----------+
| 240-249 | Reserved for Experimental Use | RFC 9946 |
+---------+----------------------------------+-----------+
| 250-254 | Reserved for Private Use | RFC 9946 |
+---------+----------------------------------+-----------+
| 255 | Reserved | RFC 9946 |
+---------+----------------------------------+-----------+
Table 19: Initial Values of the Test Activation PDU Command Response Field Registry
表 19: Test Activation PDU コマンド応答フィールド レジストリの初期値
It is suggested that multiple designated experts be appointed for registry change requests.
レジストリ変更リクエストには複数の指定された専門家を任命することが推奨されます。
Criteria that should be applied by the designated experts include determining whether the proposed registration duplicates existing entries and whether the registration description is clear and fits the purpose of this registry.
指定された専門家が適用すべき基準には、提案された登録が既存のエントリと重複するかどうか、および登録の説明が明確でこのレジストリの目的に適合するかどうかの判断が含まれます。
Registration requests are evaluated within a two-week review period on the advice of one or more designated experts. Within the review period, the designated experts will either approve or deny the registration request, communicating this decision to IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
登録リクエストは、1 人以上の指定された専門家のアドバイスに基づいて 2 週間の審査期間内に評価されます。審査期間内に、指定された専門家が登録要求を承認または拒否し、この決定を IANA に伝えます。拒否には、説明と、該当する場合はリクエストを成功させる方法に関する提案を含める必要があります。
[C-Prog] ISO/IEC, "Programming languages -- C", ISO/IEC 9899:1999,
1999, <https://www.iso.org/standard/29237.html>.
[NIST800-108]
Chen, L., "Recommendation for Key Derivation Using
Pseudorandom Functions",
DOI 10.6028/NIST.SP.800-108r1-upd1, NIST
SP 800-108r1-upd1, August 2022,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-108r1-upd1.pdf>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[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>.
[RFC5044] Culley, P., Elzur, U., Recio, R., Bailey, S., and J.
Carrier, "Marker PDU Aligned Framing for TCP
Specification", RFC 5044, DOI 10.17487/RFC5044, October
2007, <https://www.rfc-editor.org/info/rfc5044>.
[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>.
[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>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[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>.
[TR-471] Broadband Forum, "Maximum IP-Layer Capacity Metric,
Related Metrics, and Measurements", TR-471, Issue 4,
September 2024,
<https://www.broadband-forum.org/pdfs/tr-471-4-0-0.pdf>.
[Y.1540] ITU-T, "Internet protocol data communication service - IP
packet transfer and availability performance parameters",
ITU-T Recommendation Y.1540, December 2019,
<https://www.itu.int/rec/T-REC-Y.1540-201912-I/en>.
[Y.1540Amd2]
ITU-T, "Internet protocol data communication service - IP
packet transfer and availability performance parameters,
Amendment 2 - Revised Annex B: Additional search
algorithms for IP-based capacity parameters and methods of
measurement", ITU-T Recommendation Y.1540 Amd. 2, March
2023,
<https://www.itu.int/rec/T-REC-Y.1540-202303-I!Amd2/en>.
[EVP_KDF-KB]
"EVP_KDF-KB - The Key-Based EVP_KDF implementation",
OpenSSL Documentation,
<https://docs.openssl.org/master/man7/EVP_KDF-KB/>.
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC9145] Boucadair, M., Reddy.K, T., and D. Wing, "Integrity
Protection for the Network Service Header (NSH) and
Encryption of Sensitive Context Headers", RFC 9145,
DOI 10.17487/RFC9145, December 2021,
<https://www.rfc-editor.org/info/rfc9145>.
<CODE BEGINS>
//
// Output individual authentication keys of length SHA256_KEY_LEN
// from derived key material.
//
// Return Values: 0 = Failure, 1 = Success
//
int kdf_hmac_sha256(char *Kin, uint32_t authUnixTime,
unsigned char *cAuthKey, // Client key
unsigned char *sAuthKey) { // Server key
int var, keylen = SHA256_KEY_LEN * 2;
char context[16];
unsigned char *keyptr, keybuf[keylen];
EVP_KDF *kdf = NULL;
EVP_KDF_CTX *kctx = NULL;
OSSL_PARAM params[16], *p = params;
//
// Fetch KDF algorithm and create context
//
if ((kdf = EVP_KDF_fetch(NULL, "KBKDF", NULL)) == NULL) {
return 0;
}
if ((kctx = EVP_KDF_CTX_new(kdf)) == NULL) {
EVP_KDF_free(kdf);
return 0;
}
//
// Set parameters for KBKDF
// ---------------------------------------------------------
*p++ = OSSL_PARAM_construct_utf8_string(
OSSL_KDF_PARAM_MODE, "COUNTER", 0);
*p++ = OSSL_PARAM_construct_utf8_string(
OSSL_KDF_PARAM_MAC, "HMAC", 0);
*p++ = OSSL_PARAM_construct_utf8_string(
OSSL_KDF_PARAM_DIGEST, "SHA256", 0);
*p++ = OSSL_PARAM_construct_octet_string(
OSSL_KDF_PARAM_KEY, Kin, strlen(Kin));
*p++ = OSSL_PARAM_construct_octet_string(
OSSL_KDF_PARAM_SALT, "UDPSTP", 6);
var = snprintf(context, sizeof(context), "%u", authUnixTime);
*p++ = OSSL_PARAM_construct_octet_string(
OSSL_KDF_PARAM_INFO, context, var);
//
// Confirm the following are enabled
//
var = 1;
*p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_USE_L, &var);
*p++ = OSSL_PARAM_construct_int(
OSSL_KDF_PARAM_KBKDF_USE_SEPARATOR, &var);
//
// Set counter length in bits (available as of OpenSSL 3.1)
//
var = 32; // Length of 32 is backward compatible with OpenSSL 3.0
*p++ = OSSL_PARAM_construct_int(OSSL_KDF_PARAM_KBKDF_R, &var);
*p++ = OSSL_PARAM_construct_end();
// ---------------------------------------------------------
//
// Derive key material
//
if (EVP_KDF_derive(kctx, keybuf, keylen, params) < 1) {
EVP_KDF_CTX_free(kctx);
EVP_KDF_free(kdf);
return 0;
}
//
// Output individual keys
//
keyptr = keybuf;
memcpy(cAuthKey, keyptr, SHA256_KEY_LEN);
keyptr += SHA256_KEY_LEN;
memcpy(sAuthKey, keyptr, SHA256_KEY_LEN);
//
// Cleanup
//
EVP_KDF_CTX_free(kctx);
EVP_KDF_free(kdf);
return 1;
}
<CODE ENDS>
Figure 12: KDF Example Code Snippet
図 12: KDF サンプル コード スニペット
This document was edited by Al Morton, who passed away before being able to finalize this work. Ruediger Geib only joined later to help finalize this specification.
この文書は、この作品を完成させる前に亡くなったアル・モートンによって編集されました。Ruediger Geib は、この仕様の完成を支援するために後から参加しました。
Thanks to Lincoln Lavoie, Can Desem, Greg Mirsky, Bjoern Ivar Teigen, Ken Kerpez, and Chen Li for reviewing this specification and providing helpful suggestions and areas for further development. Mohamed Boucadair's AD review improved comprehensibility of the document, and he provided helpful guidance well through the final review stages. Tommy Pauly shepherded this document. Further comments by Gorry Fairhurst, Éric Vyncke, Roman Danyliw, Gunter Van de Velde, Deb Cooley, Tianran Zhou, Andy Newton, Giuseppe Fioccola, Lars Eggert, Erik Kline, and Benson Muite helped to shape the document. David Dong and Amanda Baber provided early reviews of the IANA Considerations section.
この仕様をレビューし、さらなる開発のための有益な提案と領域を提供してくれた Lincoln Lavoie、Can Desem、Greg Mirsky、Bjoern Ivar Reigen、Ken Kerpez、および Chen Li に感謝します。Mohamed Boucadair の AD レビューにより、文書の理解度が向上し、最終レビュー段階まで役立つガイダンスを提供してくれました。トミー・ポーリーはこの文書を管理しました。Gorry Fairhurst、Éric Vyncke、Roman Danyliw、Gunter Van de Velde、Deb Cooley、Tianran Zhou、Andy Newton、Giuseppe Fioccola、Lars Eggert、Erik Kline、Benson Muite によるさらなるコメントが文書の形成に役立ちました。David Dong と Amanda Baber は、IANA の考慮事項セクションの初期レビューを提供しました。
Starting with the early SEC-DIR review, Brian Weis provided constructive guidance regarding numerous security-related protocol issues. The Crypto Forum Research Group reviewed these parts, again providing guidance. Magnus Westerlund's review resulted in further changes and refinements. Ultimately, Paul Wouters' feedback was critical in finalizing the chosen security approach.
Brian Weis は、初期の SEC-DIR レビューを皮切りに、セキュリティ関連のプロトコルに関する多数の問題に関して建設的なガイダンスを提供しました。クリプトフォーラム研究グループはこれらの部分を検討し、再びガイダンスを提供しました。Magnus Westerlund のレビューにより、さらなる変更と改良が行われました。最終的に、Paul Wouters のフィードバックは、選択したセキュリティ アプローチを最終決定する上で重要でした。
Al Morton
AT&T Labs
Len Ciavattone
AT&T Labs
Middletown, NJ
United States of America
Email: lenciavattone@gmail.com
Ruediger Geib (editor)
Deutsche Telekom
Deutsche Telekom Allee 9
64295 Darmstadt
Germany
Phone: +49 6151 5812747
Email: Ruediger.Geib@telekom.de