[要約] RFC 4656は、One-way Active Measurement Protocol（OWAMP）に関する規格です。OWAMPは、ネットワークの性能測定を行うためのプロトコルであり、往復時間やパケットロスなどを測定することが目的です。
Network Working Group S. Shalunov
Request for Comments: 4656 B. Teitelbaum
Category: Standards Track A. Karp
J. Boote
M. Zekauskas
Internet2
September 2006
A One-way Active Measurement Protocol (OWAMP)
一方向アクティブ測定プロトコル（OWAMP）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources (such as GPS and CDMA). OWAMP enables the interoperability of these measurements.
一元配置アクティブ測定プロトコル（OWAMP）は、一元配置遅延や一元配置損失などの単方向特性を測定します。これらの一元配置IPパフォーマンスメトリックの高精度測定が可能になり、良い時間ソース（GPSやCDMAなど）が幅広く利用可能になりました。OWAMPにより、これらの測定の相互運用性が可能になります。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Relationship of Test and Control Protocols .................3
1.2. Logical Model ..............................................4
2. Protocol Overview ...............................................5
3. OWAMP-Control ...................................................6
3.1. Connection Setup ...........................................6
3.2. Integrity Protection (HMAC) ...............................11
3.3. Values of the Accept Field ................................11
3.4. OWAMP-Control Commands ....................................12
3.5. Creating Test Sessions ....................................13
3.6. Send Schedules ............................................18
3.7. Starting Test Sessions ....................................19
3.8. Stop-Sessions .............................................20
3.9. Fetch-Session .............................................24
4. OWAMP-Test .....................................................27
4.1. Sender Behavior ...........................................28
4.1.1. Packet Timings .....................................28
4.1.2. OWAMP-Test Packet Format and Content ...............29
4.2. Receiver Behavior .........................................33
5. Computing Exponentially Distributed Pseudo-Random Numbers ......35
5.1. High-Level Description of the Algorithm ...................35
5.2. Data Types, Representation, and Arithmetic ................36
5.3. Uniform Random Quantities .................................37
6. Security Considerations ........................................38
6.1. Introduction ..............................................38
6.2. Preventing Third-Party Denial of Service ..................38
6.3. Covert Information Channels ...............................39
6.4. Requirement to Include AES in Implementations .............39
6.5. Resource Use Limitations ..................................39
6.6. Use of Cryptographic Primitives in OWAMP ..................40
6.7. Cryptographic Primitive Replacement .......................42
6.8. Long-term Manually Managed Keys ...........................43
6.9. (Not) Using Time as Salt ..................................44
6.10. The Use of AES-CBC and HMAC ..............................44
7. Acknowledgements ...............................................45
8. IANA Considerations ............................................45
9. Internationalization Considerations ............................46
10. References ....................................................46
10.1. Normative References .....................................46
10.2. Informative References ...................................47
Appendix A: Sample C Code for Exponential Deviates ................49
Appendix B: Test Vectors for Exponential Deviates .................54
The IETF IP Performance Metrics (IPPM) working group has defined metrics for one-way packet delay [RFC2679] and loss [RFC2680] across Internet paths. Although there are now several measurement platforms that implement collection of these metrics [SURVEYOR] [SURVEYOR-INET] [RIPE] [BRIX], there is not currently a standard that would permit initiation of test streams or exchange of packets to collect singleton metrics in an interoperable manner.
IETF IPパフォーマンスメトリック（IPPM）ワーキンググループは、インターネットパス全体で一元配置パケット遅延[RFC2679]および損失[RFC2680]のメトリックを定義しています。現在、これらのメトリックのコレクションを実装するいくつかの測定プラットフォーム[Surveyor] [Surveyor-Inet] [Ripe] [Brix]がありますが、テストストリームの開始またはパケットの交換を可能にする標準はありません。相互運用可能な方法。
With the increasingly wide availability of affordable global positioning systems (GPS) and CDMA-based time sources, hosts increasingly have available to them very accurate time sources, either directly or through their proximity to Network Time Protocol (NTP) primary (stratum 1) time servers. By standardizing a technique for collecting IPPM one-way active measurements, we hope to create an environment where IPPM metrics may be collected across a far broader mesh of Internet paths than is currently possible. One particularly compelling vision is of widespread deployment of open OWAMP servers that would make measurement of one-way delay as commonplace as measurement of round-trip time using an ICMP-based tool like ping.
手頃な価格のグローバルポジショニングシステム（GPS）およびCDMAベースの時間源がますます幅広く利用できるため、ネットワークタイムプロトコル（NTP）プライマリ（層1）に直接または近接して、非常に正確な時間源（層1）のいずれかで、非常に正確な時間源がますます利用できるようになります。サーバー。IPPM一元配置測定値を収集する手法を標準化することにより、現在可能であるよりもはるかに広いインターネットパスでIPPMメトリックが収集される環境を作成したいと考えています。特に説得力のあるビジョンの1つは、PingなどのICMPベースのツールを使用して往復時間の測定と同じくらい一般的な一元配置遅延の測定を行うオープンオワンプサーバーの広範な展開です。
Additional design goals of OWAMP include: being hard to detect and manipulate, security, logical separation of control and test functionality, and support for small test packets. (Being hard to detect makes interference with measurements more difficult for intermediaries in the middle of the network.)
OWAMPの追加設計目標には、検出と操作が困難であること、セキュリティ、制御機能とテスト機能の論理的分離、および小さなテストパケットのサポートが含まれます。（検出が難しく、ネットワークの中央にある仲介者にとって測定値への干渉がより困難になります。）
OWAMP test traffic is hard to detect because it is simply a stream of UDP packets from and to negotiated port numbers, with potentially nothing static in the packets (size is negotiated, as well). OWAMP also supports an encrypted mode that further obscures the traffic and makes it impossible to alter timestamps undetectably.
OWAMPテストトラフィックは、単にネゴシエートされたポート番号からのUDPパケットのストリームであるため、パケットに静的なものがない可能性があるため、検出が困難です（サイズも交渉されます）。Owampは、トラフィックをさらに曖昧にし、タイムスタンプを検出不要に変更することを不可能にする暗号化モードもサポートしています。
Security features include optional authentication and/or encryption of control and test messages. These features may be useful to prevent unauthorized access to results or man-in-the-middle attacks that attempt to provide special treatment to OWAMP test streams or that attempt to modify sender-generated timestamps to falsify test results.
セキュリティ機能には、コントロールメッセージとテストメッセージのオプションの認証および/または暗号化が含まれます。これらの機能は、テストストリームを控えるために特別な治療を提供しようとする、またはテスト結果を偽造するために送信者が生成したタイムスタンプを変更しようとする結果または中間攻撃への不正アクセスを防ぐのに役立つ場合があります。
In this document, the key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" are to be interpreted as described in [RFC2119].
このドキュメントでは、キーワードは「必要」、「必要」、「必要」、「推奨」、および「可能性」は[RFC2119]で説明されているように解釈されます。
OWAMP actually consists of two inter-related protocols: OWAMP-Control and OWAMP-Test. OWAMP-Control is used to initiate, start, and stop test sessions and to fetch their results, whereas OWAMP-Test is used to exchange test packets between two measurement nodes.
OWAMPは、実際には2つの相互に関連するプロトコルで構成されています：Owamp-ControlとOwamp-Test。Owamp-Controlは、テストセッションを開始、開始、および結果を取得するために使用され、Owampテストは2つの測定ノード間でテストパケットを交換するために使用されます。
Although OWAMP-Test may be used in conjunction with a control protocol other than OWAMP-Control, the authors have deliberately chosen to include both protocols in the same RFC to encourage the implementation and deployment of OWAMP-Control as a common denominator control protocol for one-way active measurements. Having a complete and open one-way active measurement solution that is simple to implement and deploy is crucial to ensuring a future in which inter-domain one-way active measurement could become as commonplace as ping. We neither anticipate nor recommend that OWAMP-Control form the foundation of a general-purpose extensible measurement and monitoring control protocol.
OWAMP-Control以外のコントロールプロトコルと組み合わせてOWAMPテストは使用できますが、著者は、同じRFCに両方のプロトコルを含めることを意図的に選択して、OWAMP-Controlの一般的な分母コントロールプロトコルとしての実装と展開を促進することを選択しました。 - ウェイアクティブ測定。実装および展開が簡単で展開が簡単で、完全でオープンな一方向アクティブ測定ソリューションを持つことは、ドメイン間の一方向アクティブ測定がPingと同じくらい一般的になる可能性がある未来を確保するために重要です。Owamp-Controlが汎用拡張可能な測定と監視制御プロトコルの基礎を形成することを予想も推奨もしていません。
OWAMP-Control is designed to support the negotiation of one-way active measurement sessions and results retrieval in a straightforward manner. At session initiation, there is a negotiation of sender and receiver addresses and port numbers, session start time, session length, test packet size, the mean Poisson sampling interval for the test stream, and some attributes of the very general [RFC 2330] notion of packet type, including packet size and per-hop behavior (PHB) [RFC2474], which could be used to support the measurement of one-way network characteristics across differentiated services networks. Additionally, OWAMP-Control supports per-session encryption and authentication for both test and control traffic, measurement servers that can act as proxies for test stream endpoints, and the exchange of a seed value for the pseudo-random Poisson process that describes the test stream generated by the sender.
Owamp-Controlは、一方向のアクティブ測定セッションの交渉をサポートするように設計されています。セッション開始時には、送信者と受信者のアドレスとポート番号の交渉、セッション開始時間、セッション長、テストパケットサイズ、テストストリームの平均ポアソンサンプリング間隔、および非常に一般的な[RFC 2330]概念のいくつかの属性があります。パケットサイズとホップごとの動作（PHB）[RFC2474]を含むパケットタイプ。これを使用して、差別化されたサービスネットワーク全体で一元配置ネットワーク特性の測定をサポートできます。さらに、OWAMP-Controlは、テストと制御トラフィックの両方のセッションごとの暗号化と認証をサポートします。テストストリームエンドポイントのプロキシとして機能する測定サーバー、およびテストストリームを説明する擬似ランダムポアソンプロセスのシード値の交換をサポートします送信者によって生成されます。
We believe that OWAMP-Control can effectively support one-way active measurement in a variety of environments, from publicly accessible measurement beacons running on arbitrary hosts to network monitoring deployments within private corporate networks. If integration with Simple Network Management Protocol (SNMP) or proprietary network management protocols is required, gateways may be created.
OWAMP-Controlは、任意のホストで実行されている公開可能な測定ビーコンから、民間企業ネットワーク内のネットワーク監視展開まで、さまざまな環境での一元配置積極測定を効果的にサポートできると考えています。Simple Network Management Protocol（SNMP）または独自のネットワーク管理プロトコルとの統合が必要な場合は、ゲートウェイが作成される場合があります。
Several roles are logically separated to allow for broad flexibility in use. Specifically, we define the following:
いくつかの役割は、幅広い柔軟性を使用できるように論理的に分離されています。具体的には、以下を定義します。
Session-Sender The sending endpoint of an OWAMP-Test session;
セッションセンダーオウムテストセッションの送信エンドポイント。
Session-Receiver The receiving endpoint of an OWAMP-Test session;
セッションレシーバーOWAMPテストセッションの受信エンドポイント。
Server An end system that manages one or more OWAMP-Test sessions, is capable of configuring per-session state in session endpoints, and is capable of returning the results of a test session;
サーバー1つ以上のオウムテストセッションを管理するエンドシステムは、セッションごとのエンドポイントでセッションごとの状態を構成でき、テストセッションの結果を返すことができます。
Control-Client An end system that initiates requests for OWAMP-Test sessions, triggers the start of a set of sessions, and may trigger their termination; and
コントロールクライアントオウムテストセッションのリクエストを開始し、一連のセッションの開始をトリガーし、終了をトリガーする可能性があります。と
Fetch-Client An end system that initiates requests to fetch the results of completed OWAMP-Test sessions.
完了したOWAMPテストセッションの結果を取得するリクエストを開始するエンドシステムを取得します。
One possible scenario of relationships between these roles is shown below.
+----------------+ +------------------+
| Session-Sender |--OWAMP-Test-->| Session-Receiver |
+----------------+ +------------------+
^ ^
| |
| |
| |
| +----------------+<----------------+
| | Server |<-------+
| +----------------+ |
| ^ |
| | |
| OWAMP-Control OWAMP-Control
| | |
v v v
+----------------+ +-----------------+
| Control-Client | | Fetch-Client |
+----------------+ +-----------------+
(Unlabeled links in the figure are unspecified by this document and may be proprietary protocols.)
（図の非標識リンクは、このドキュメントでは特定されておらず、独自のプロトコルである可能性があります。）
Different logical roles can be played by the same host. For example, in the figure above, there could actually be only two hosts: one playing the roles of Control-Client, Fetch-Client, and Session-Sender, and the other playing the roles of Server and Session-Receiver. This is shown below.
同じホストが異なる論理的役割を演奏できます。たとえば、上の図では、実際には2つのホストしか存在しない可能性があります。1つはコントロールクライアント、フェッチクライアント、セッションセンダーの役割を演奏し、もう1つはサーバーとセッションレシーバーの役割を演じています。これを以下に示します。
+-----------------+ +------------------+
| Control-Client |<--OWAMP-Control-->| Server |
| Fetch-Client | | |
| Session-Sender |---OWAMP-Test----->| Session-Receiver |
+-----------------+ +------------------+
Finally, because many Internet paths include segments that transport IP over ATM, delay and loss measurements can include the effects of ATM segmentation and reassembly (SAR). Consequently, OWAMP has been designed to allow for small test packets that would fit inside the payload of a single ATM cell (this is only achieved in unauthenticated mode).
最後に、多くのインターネットパスにはIPをATM上で輸送するセグメントが含まれているため、遅延測定と損失測定にはATMセグメンテーションと再組み立ての影響（SAR）が含まれます。その結果、OWAMPは、単一のATMセルのペイロード内に収まる小さなテストパケットを可能にするように設計されています（これは、認定されていないモードでのみ達成されます）。
As described above, OWAMP consists of two inter-related protocols: OWAMP-Control and OWAMP-Test. The former is layered over TCP and is used to initiate and control measurement sessions and to fetch their results. The latter protocol is layered over UDP and is used to send singleton measurement packets along the Internet path under test.
上記のように、OWAMPは、Owamp-ControlとOwamp-Testの2つの相互に関連するプロトコルで構成されています。前者はTCP上に階層化されており、測定セッションを開始および制御し、結果を取得するために使用されます。後者のプロトコルはUDP上に階層化されており、テスト中のインターネットパスに沿ってSingleton測定パケットを送信するために使用されます。
The initiator of the measurement session establishes a TCP connection to a well-known port, 861, on the target point and this connection remains open for the duration of the OWAMP-Test sessions. An OWAMP server SHOULD listen to this well-known port.
測定セッションのイニシエーターは、ターゲットポイントでよく知られているポート861へのTCP接続を確立し、この接続はOWAMPテストセッションの期間中開いたままです。OWAMPサーバーは、このよく知られているポートを聞く必要があります。
OWAMP-Control messages are transmitted only before OWAMP-Test sessions are actually started and after they are completed (with the possible exception of an early Stop-Sessions message).
Owamp-Controlメッセージは、Owamp-Testセッションが実際に開始され、それらが完了した後にのみ送信されます（早期停止セッションメッセージを除いて）。
The OWAMP-Control and OWAMP-Test protocols support three modes of operation: unauthenticated, authenticated, and encrypted. The authenticated or encrypted modes require that endpoints possess a shared secret.
All multi-octet quantities defined in this document are represented as unsigned integers in network byte order unless specified otherwise.
このドキュメントで定義されているすべてのマルチオクテット数量は、特に指定されていない限り、ネットワークバイトの順序で符号なしの整数として表されます。
The type of each OWAMP-Control message can be found after reading the first 16 octets. The length of each OWAMP-Control message can be computed upon reading its fixed-size part. No message is shorter than 16 octets.
最初の16個のオクテットを読んだ後、各owamp-controlメッセージのタイプは見つけることができます。各OWAMPコントロールメッセージの長さは、固定サイズの部分を読み取ると計算できます。16オクテットより短いメッセージはありません。
An implementation SHOULD expunge unused state to prevent denial-of-service attacks, or unbounded memory usage, on the server. For example, if the full control message is not received within some number of minutes after it is expected, the TCP connection associated with the OWAMP-Control session SHOULD be dropped. In absence of other considerations, 30 minutes seems like a reasonable upper bound.
サーバー上のサービス拒否攻撃、または無制限のメモリ使用量を防ぐために、未使用の状態を消去する必要があります。たとえば、完全な制御メッセージが予想から数分以内に受信されない場合、Owamp-Controlセッションに関連付けられたTCP接続を削除する必要があります。他の考慮事項がない場合、30分間は合理的な上限のようです。
Before either a Control-Client or a Fetch-Client can issue commands to a Server, it has to establish a connection to the server.
コントロールクライアントまたはフェッチクライアントがサーバーにコマンドを発行する前に、サーバーへの接続を確立する必要があります。
First, a client opens a TCP connection to the server on a well-known port 861. The server responds with a server greeting:
まず、クライアントは、よく知られているポート861でサーバーへのTCP接続を開きます。サーバーは、サーバーの挨拶で応答します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Unused (12 octets) |
| |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Challenge (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Salt (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following Mode values are meaningful: 1 for unauthenticated, 2 for authenticated, and 4 for encrypted. The value of the Modes field sent by the server is the bit-wise OR of the mode values that it is willing to support during this session. Thus, the last three bits of the Modes 32-bit value are used. The first 29 bits MUST be zero. A client MUST ignore the values in the first 29 bits of the Modes value. (This way, the bits are available for future protocol extensions. This is the only intended extension mechanism.)
Challenge is a random sequence of octets generated by the server; it is used subsequently by the client to prove possession of a shared secret in a manner prescribed below.
チャレンジは、サーバーによって生成されたオクテットのランダムシーケンスです。その後、クライアントによって使用され、以下に規定されている方法で共有された秘密の所持を証明します。
Salt and Count are parameters used in deriving a key from a shared secret as described below.
塩とカウントは、以下に説明するように、共有された秘密からキーを導き出す際に使用されるパラメーターです。
Salt MUST be generated pseudo-randomly (independently of anything else in this document).
塩は擬似ランダムリー（このドキュメントの他のものとは無関係に）生成する必要があります。
Count MUST be a power of 2. Count MUST be at least 1024. Count SHOULD be increased as more computing power becomes common.
カウントは2のパワーでなければなりません。カウントは少なくとも1024でなければなりません。カウントを増やす必要があります。
If the Modes value is zero, the server does not wish to communicate with the client and MAY close the connection immediately. The client SHOULD close the connection if it receives a greeting with Modes equal to zero. The client MAY close the connection if the client's desired mode is unavailable.
モード値がゼロの場合、サーバーはクライアントと通信することを望まず、すぐに接続を閉じることができます。クライアントは、ゼロに等しいモードでグリーティングを受け取る場合、接続を閉じる必要があります。クライアントの希望するモードが利用できない場合、クライアントは接続を閉じることができます。
Otherwise, the client MUST respond with the following Set-Up-Response message:
それ以外の場合、クライアントは次のセットアップ応答メッセージで応答する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. KeyID (80 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Token (64 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Client-IV (16 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here Mode is the mode that the client chooses to use during this OWAMP-Control session. It will also be used for all OWAMP-Test sessions started under control of this OWAMP-Control session. In Mode, one or zero bits MUST be set within last three bits. If it is one bit that is set within the last three bits, this bit MUST indicate a mode that the server agreed to use (i.e., the same bit MUST have been set by the server in the server greeting). The first 29 bits of Mode MUST be zero. A server MUST ignore the values of the first 29 bits. If zero Mode bits are set by the client, the client indicates that it will not continue with the session; in this case, the client and the server SHOULD close the TCP connection associated with the OWAMP-Control session.
In unauthenticated mode, KeyID, Token, and Client-IV are unused. Otherwise, KeyID is a UTF-8 string, up to 80 octets in length (if the string is shorter, it is padded with zero octets), that tells the server which shared secret the client wishes to use to authenticate or encrypt, while Token is the concatenation of a 16-octet challenge, a 16-octet AES Session-key used for encryption, and a 32-octet HMAC-SHA1 Session-key used for authentication. The token itself is encrypted using the AES (Advanced Encryption Standard) [AES] in Cipher Block Chaining (CBC). Encryption MUST be performed using an Initialization Vector (IV) of zero and a key derived from the shared secret associated with KeyID. (Both the server and the client use the same mappings from KeyIDs to shared secrets. The server, being prepared to conduct sessions with more than one client, uses KeyIDs to choose the appropriate secret key; a client would typically have different secret keys for different servers. The situation is analogous to that with passwords.)
認証されていないモードでは、KeyID、Token、およびClient-IVが使用されていません。それ以外の場合、KeyIDはUTF-8文字列で、長さが最大80オクテット（文字列の短い場合、ゼロオクテットが付いています）は、クライアントが秘密を共有しているサーバーに、認証または暗号化に使用したいと考えています。16オクテットのチャレンジ、暗号化に使用される16オクセットのAESセッションキー、および認証に使用される32オクテットHMAC-SHA1セッションキーの連結です。トークン自体は、暗号ブロックチェーン（CBC）のAES（高度な暗号化標準）[AES] [AES]を使用して暗号化されています。暗号化は、ゼロの初期化ベクトル（IV）と、KeyIDに関連付けられた共有秘密から派生したキーを使用して実行する必要があります。（サーバーとクライアントの両方がKeyIDSの同じマッピングを共有秘密に使用します。サーバーは、複数のクライアントとセッションを実行する準備ができており、KeyIDSを使用して適切な秘密キーを選択します。クライアントは通常、異なる秘密キーを持っていますサーバー。状況はパスワードでそれに類似しています。）
The shared secret is a passphrase; it MUST not contain newlines. The secret key is derived from the passphrase using a password-based key derivation function PBKDF2 (PKCS #5) [RFC2898]. The PBKDF2 function requires several parameters: the PRF is HMAC-SHA1 [RFC2104]; the salt and count are as transmitted by the server.
共有秘密はパスフレーズです。新しいラインを含めてはなりません。シークレットキーは、パスワードベースのキー派生関数PBKDF2（PKCS＃5）[RFC2898]を使用して、パスフレーズから導出されます。PBKDF2関数にはいくつかのパラメーターが必要です。PRFはHMAC-SHA1 [RFC2104]です。塩とカウントは、サーバーによって送信されるとおりです。
AES Session-key, HMAC Session-key and Client-IV are generated randomly by the client. AES Session-key and HMAC Session-key MUST be generated with sufficient entropy not to reduce the security of the underlying cipher [RFC4086]. Client-IV merely needs to be unique (i.e., it MUST never be repeated for different sessions using the same secret key; a simple way to achieve that without the use of cumbersome state is to generate the Client-IV values using a cryptographically secure pseudo-random number source: if this is done, the first repetition is unlikely to occur before 2^64 sessions with the same secret key are conducted).
AESセッションキー、HMACセッションキー、クライアントIVは、クライアントによってランダムに生成されます。AESセッションキーとHMACセッションキーは、基礎となる暗号のセキュリティを減らないように十分なエントロピーで生成する必要があります[RFC4086]。クライアント-IVは単にユニークである必要があるだけです（つまり、同じ秘密のキーを使用して異なるセッションで繰り返されることはありません。扱いにくい状態を使用せずにそれを達成するための簡単な方法は、暗号化された擬似擬似を使用してクライアント-IV値を生成することです。 - ランダム番号出典：これが行われた場合、同じ秘密キーを使用した2^64セッションが行われる前に、最初の繰り返しが発生する可能性は低いです）。
The server MUST respond with the following Server-Start message:
サーバーは、次のサーバースタートメッセージで応答する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (15 octets) |
| |
| +-+-+-+-+-+-+-+-+
| | Accept |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Server-IV (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Time (Timestamp) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MBZ parts MUST be zero. The client MUST ignore their value. MBZ (MUST be zero) fields here and after have the same semantics: the party that sends the message MUST set the field so that all bits are equal to zero; the party that interprets the message MUST ignore the value. (This way, the field could be used for future extensions.)
MBZパーツはゼロでなければなりません。クライアントは自分の価値を無視する必要があります。ここではMBZ（ゼロでなければならない）フィールドと同じセマンティクスがあります。メッセージを送信するパーティーは、すべてのビットがゼロに等しくなるようにフィールドを設定する必要があります。メッセージを解釈する当事者は、値を無視する必要があります。（このように、フィールドは将来の拡張に使用できます。）
Server-IV is generated randomly by the server. In unauthenticated mode, Server-IV is unused.
サーバーIVは、サーバーによってランダムに生成されます。認識されていないモードでは、Server-IVは使用されていません。
The Accept field indicates the server's willingness to continue communication. A zero value in the Accept field means that the server accepts the authentication and is willing to conduct further transactions. Non-zero values indicate that the server does not accept the authentication or, for some other reason, is not willing to conduct further transactions in this OWAMP-Control session. The full list of available Accept values is described in Section 3.3, "Values of the Accept Field".
Acceptフィールドは、コミュニケーションを継続するサーバーの意欲を示します。Acceptフィールドのゼロ値は、サーバーが認証を受け入れ、さらにトランザクションを実行することをいとわないことを意味します。ゼロ以外の値は、サーバーが認証を受け入れないこと、または他の理由で、このOWAMP-Controlセッションでさらなるトランザクションを実施する意思がないことを示しています。利用可能な受け入れ値の完全なリストは、セクション3.3「Acceptフィールドの値」で説明されています。
If a negative (non-zero) response is sent, the server MAY (and the client SHOULD) close the connection after this message.
ネガティブ（ゼロ以外の）応答が送信された場合、サーバーはこのメッセージの後に接続を閉じる（およびクライアントが接続する必要があります）。
Start-Time is a timestamp representing the time when the current instantiation of the server started operating. (For example, in a multi-user general purpose operating system, it could be the time when the server process was started.) If Accept is non-zero, Start- Time SHOULD be set so that all of its bits are zeros. In authenticated and encrypted modes, Start-Time is encrypted as described in Section 3.4, "OWAMP-Control Commands", unless Accept is non-zero. (Authenticated and encrypted mode cannot be entered unless the control connection can be initialized.)
開始時間は、サーバーの現在のインスタンス化が動作し始めた時期を表すタイムスタンプです。（たとえば、マルチユーザーの汎用オペレーティングシステムでは、サーバープロセスが開始された時期である可能性があります。）受け入れがゼロである場合、すべてのビットがゼロになるように開始時間を設定する必要があります。認証されたモードと暗号化されたモードでは、セクション3.4で説明されている「Owamp-Controlコマンド」で説明されているように、開始時間は暗号化されます。（コントロール接続を初期化できない限り、認証されたモードと暗号化モードを入力できません。）
Timestamp format is described in Section 4.1.2. The same instantiation of the server SHOULD report the same exact Start-Time value to each client in each session.
タイムスタンプ形式は、セクション4.1.2で説明されています。サーバーの同じインスタンス化は、各セッションの各クライアントに同じ正確な開始時間値を報告する必要があります。
The previous transactions constitute connection setup.
以前のトランザクションは接続のセットアップを構成します。
Authentication of each message (also referred to as a command in this document) in OWAMP-Control is accomplished by adding an HMAC to it. The HMAC that OWAMP uses is HMAC-SHA1 truncated to 128 bits. Thus, all HMAC fields are 16 octets. An HMAC needs a key. The HMAC Session-key is communicated along with the AES Session-key during OWAMP-Control connection setup. The HMAC Session-key SHOULD be derived independently of the AES Session-key (an implementation, of course, MAY use the same mechanism to generate the random bits for both keys). Each HMAC sent covers everything sent in a given direction between the previous HMAC (but not including it) and up to the beginning of the new HMAC. This way, once encryption is set up, each bit of the OWAMP-Control connection is authenticated by an HMAC exactly once.
Owamp-Controlの各メッセージ（このドキュメントのコマンドとも呼ばれる）の認証は、HMACを追加することで実現されます。Owampが使用するHMACは、128ビットに切り捨てられたHMAC-SHA1です。したがって、すべてのHMACフィールドは16オクテットです。HMACにはキーが必要です。HMAC Session-Keyは、Owamp-Control Connectionセットアップ中にAESセッションキーとともに通信されます。HMACセッションキーは、AESセッションキーとは独立して導出する必要があります（もちろん、実装は同じメカニズムを使用して両方のキーのランダムビットを生成する場合があります）。送信された各HMACは、以前のHMAC（ただし含まれていない）と新しいHMACの先頭までの特定の指示で送信されたすべてをカバーします。このようにして、暗号化がセットアップされると、Owamp-Control接続の各ビットはHMACによって1回認証されます。
When encrypting, authentication happens before encryption, so HMAC blocks are encrypted along with the rest of the stream. When decrypting, the order, of course, is reversed: first one decrypts, then one checks the HMAC, then one proceeds to use the data.
暗号化すると、暗号化前に認証が行われるため、HMACブロックはストリームの残りの部分とともに暗号化されます。復号化するとき、もちろん順序が逆になります。最初の1つの復号化、次にHMACをチェックしてから、データを使用します。
The HMAC MUST be checked as early as possible to avoid using and propagating corrupt data.
腐敗したデータの使用と伝播を避けるために、HMACをできるだけ早くチェックする必要があります。
In open mode, the HMAC fields are unused and have the same semantics as MBZ fields.
オープンモードでは、HMACフィールドは未使用であり、MBZフィールドと同じセマンティクスを持っています。
Accept values are used throughout the OWAMP-Control protocol to communicate the server response to client requests. The full set of valid Accept field values are as follows:
受け入れ値は、クライアントリクエストにサーバーの応答を通信するために、Owamp-Controlプロトコル全体で使用されます。有効なAcceptフィールド値の完全なセットは次のとおりです。
0 OK.
0 OK。
1 Failure, reason unspecified (catch-all).
1障害、理由が不特定（キャッチオール）。
2 Internal error.
2内部エラー。
3 Some aspect of request is not supported.
3要求のいくつかの側面はサポートされていません。
4 Cannot perform request due to permanent resource limitations.
4は、永続的なリソースの制限のためにリクエストを実行できません。
5 Cannot perform request due to temporary resource limitations.
5は、一時的なリソースの制限のためにリクエストを実行できません。
All other values are reserved. The sender of the message MAY use the value of 1 for all non-zero Accept values. A message sender SHOULD use the correct Accept value if it is going to use other values. The message receiver MUST interpret all values of Accept other than these reserved values as 1. This way, other values are available for future extensions.
他のすべての値は予約されています。メッセージの送信者は、すべての非ゼロの受け入れ値に対して1の値を使用できます。メッセージ送信者は、他の値を使用する場合は、正しい受け入れ値を使用する必要があります。メッセージ受信者は、これらの予約値以外のすべての受け入れの値を1として解釈する必要があります。
In authenticated or encrypted mode (which are identical as far as OWAMP-Control is concerned, and only differ in OWAMP-Test), all further communications are encrypted with the AES Session-key (using CBC mode) and authenticated with HMAC Session-key. The client encrypts everything it sends through the just-established OWAMP-Control connection using stream encryption with Client-IV as the IV. Correspondingly, the server encrypts its side of the connection using Server-IV as the IV.
認証されたまたは暗号化されたモード（OWAMP-Controlが関係している限り同一であり、OWAMPテストでのみ異なる）では、すべてのさらなる通信はAES Session-Key（CBCモードを使用）で暗号化され、HMAC Session-Keyで認証されます。クライアントは、クライアント-IVをIVとしてのストリーム暗号化を使用して、確立されたばかりのOwamp-Control接続を介して送信するすべてを暗号化します。それに対応して、サーバーはIVとしてServer-IVを使用して接続の側面を暗号化します。
The IVs themselves are transmitted in cleartext. Encryption starts with the block immediately following the block containing the IV. The two streams (one going from the client to the server and one going back) are encrypted independently, each with its own IV, but using the same key (the AES Session-key).
IV自体はクリアテキストで送信されます。暗号化は、IVを含むブロックの直後のブロックから始まります。2つのストリーム（1つはクライアントからサーバーに移動し、もう1つは戻る）は独立して暗号化され、それぞれ独自のIVがありますが、同じキー（AESセッションキー）を使用しています。
The following commands are available for the client: Request-Session, Start-Sessions, Stop-Sessions, and Fetch-Session. The command Stop-Sessions is available to both the client and the server. (The server can also send other messages in response to commands it receives.)
クライアントが次のコマンドを利用できます：リクエストセッション、スタートセッション、ストップセッション、フェッチセッション。コマンドストップセッションは、クライアントとサーバーの両方が利用できます。（サーバーは、受信するコマンドに応じて他のメッセージを送信することもできます。）
After the client sends the Start-Sessions command and until it both sends and receives (in an unspecified order) the Stop-Sessions command, it is said to be conducting active measurements. Similarly, the server is said to be conducting active measurements after it receives the Start-Sessions command and until it both sends and receives (in an unspecified order) the Stop-Sessions command.
クライアントがStartSessionsコマンドを送信し、Stop-Sessionsコマンドを送信および受信するまで（不特定の順序で）、アクティブな測定を実施していると言われています。同様に、サーバーは、StartSessionsコマンドを受信し、Stop-Sessionsコマンドを送信および受信するまで、アクティブ測定を実行していると言われています。
While conducting active measurements, the only command available is Stop-Sessions.
These commands are described in detail below.
これらのコマンドについては、以下で詳しく説明しています。
Individual one-way active measurement sessions are established using a simple request/response protocol. An OWAMP client MAY issue zero or more Request-Session messages to an OWAMP server, which MUST respond to each with an Accept-Session message. An Accept-Session message MAY refuse a request.
単純な要求/応答プロトコルを使用して、個々の一方向アクティブ測定セッションが確立されます。OWAMPクライアントは、ゼロ以上のリクエストセッションメッセージをOWAMPサーバーに発行する場合があります。受け入れセッションメッセージは、リクエストを拒否する場合があります。
The format of Request-Session message is as follows:
リクエストセッションメッセージの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | MBZ | IPVN | Conf-Sender | Conf-Receiver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Schedule Slots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port | Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Address (cont.) or MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receiver Address (cont.) or MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout, (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-P Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is immediately followed by one or more schedule slot descriptions (the number of schedule slots is specified in the "Number of Schedule Slots" field above):
これにより、1つ以上のスケジュールスロットの説明が続きます（上記の「スケジュールスロット数」フィールドでスケジュールスロットの数が指定されます）：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Type | |
+-+-+-+-+-+-+-+-+ MBZ (7 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Parameter (Timestamp) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are immediately followed by HMAC:
これらはすぐにHMACが続きます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All these messages constitute one logical message: the Request-Session command.
これらのすべてのメッセージは、1つの論理メッセージを構成します：リクエストセッションコマンド。
Above, the first octet (1) indicates that this is the Request-Session command.
上記の最初のオクテット（1）は、これがリクエストセッションコマンドであることを示します。
IPVN is the IP version numbers for Sender and Receiver. When the IP version number is 4, 12 octets follow the 4-octet IPv4 address stored in Sender Address and Receiver Address. These octets MUST be set to zero by the client and MUST be ignored by the server. Currently meaningful IPVN values are 4 and 6.
IPVNは、送信者と受信機のIPバージョン番号です。IPバージョン番号が4の場合、12オクテットは、送信者アドレスとレシーバーアドレスに保存されている4-OCTET IPv4アドレスに従います。これらのオクテットは、クライアントによってゼロに設定する必要があり、サーバーでは無視する必要があります。現在、意味のあるIPVN値は4および6です。
Conf-Sender and Conf-Receiver MUST be set to 0 or 1 by the client. The server MUST interpret any non-zero value as 1. If the value is 1, the server is being asked to configure the corresponding agent (sender or receiver). In this case, the corresponding Port value SHOULD be disregarded by the server. At least one of Conf-Sender and Conf-Receiver MUST be 1. (Both can be set, in which case the server is being asked to perform a session between two hosts it can configure.) Number of Schedule Slots, as mentioned before, specifies the number of slot records that go between the two blocks of HMAC. It is used by the sender to determine when to send test packets (see next section).
Conf-SenderとConf-Receiverは、クライアントによって0または1に設定する必要があります。サーバーは、ゼロ以外の値を1として解釈する必要があります。値が1の場合、サーバーは対応するエージェント（送信者または受信機）を構成するように求められています。この場合、対応するポート値はサーバーによって無視される必要があります。Conf-SenderとConf-Receiverの少なくとも1つは1でなければなりません（両方とも設定できます。この場合、サーバーは、構成できる2つのホスト間でセッションを実行するように求められています。）前述のスケジュールスロットの数、前述のように、HMACの2つのブロックの間にあるスロットレコードの数を指定します。送信者は、テストパケットをいつ送信するかを判断するために使用されます（次のセクションを参照）。
Number of Packets is the number of active measurement packets to be sent during this OWAMP-Test session (note that either the server or the client can abort the session early).
パケットの数は、このオウムテストセッション中に送信されるアクティブな測定パケットの数です（サーバーまたはクライアントのいずれかがセッションを早期に中止できることに注意してください）。
If Conf-Sender is not set, Sender Port is the UDP port from which OWAMP-Test packets will be sent. If Conf-Receiver is not set, Receiver Port is the UDP port OWAMP-Test to which packets are requested to be sent.
コンフセンダーが設定されていない場合、送信者ポートは、オウムテストパケットが送信されるUDPポートです。Conf-Receiverが設定されていない場合、レシーバーポートは、パケットを送信するように要求されるUDPポートオウムテストです。
The Sender Address and Receiver Address fields contain, respectively, the sender and receiver addresses of the end points of the Internet path over which an OWAMP test session is requested.
送信者アドレスとレシーバーアドレスフィールドには、それぞれ、OWAMPテストセッションが要求されているインターネットパスのエンドポイントの送信者とレシーバーアドレスが含まれています。
SID is the session identifier. It can be used in later sessions as an argument for the Fetch-Session command. It is meaningful only if Conf-Receiver is 0. This way, the SID is always generated by the receiving side. See the end of the section for information on how the SID is generated.
SIDはセッション識別子です。後のセッションでは、フェッチセッションコマンドの引数として使用できます。これは、Conf-Receiverが0の場合にのみ意味があります。このようにして、SIDは常に受信側によって生成されます。SIDの生成方法については、セクションの最後を参照してください。
Padding length is the number of octets to be appended to the normal OWAMP-Test packet (see more on padding in discussion of OWAMP-Test).
パディングの長さは、通常のOwamp-Testパケットに追加されるオクテットの数です（Owamp-Testの議論のパディングの詳細を参照）。
Start Time is the time when the session is to be started (but not before Start-Sessions command is issued). This timestamp is in the same format as OWAMP-Test timestamps.
開始時間は、セッションを開始する時間です（ただし、StartSessionsコマンドが発行される前ではありません）。このタイムスタンプは、Owamp-Testタイムスタンプと同じ形式です。
Timeout (or a loss threshold) is an interval of time (expressed as a timestamp). A packet belonging to the test session that is being set up by the current Request-Session command will be considered lost if it is not received during Timeout seconds after it is sent.
タイムアウト（または損失のしきい値）は、時間の間隔（タイムスタンプとして表される）です。現在のリクエストセッションコマンドによってセットアップされているテストセッションに属するパケットは、送信後数秒間に受信されない場合、失われたと見なされます。
Type-P Descriptor covers only a subset of (very large) Type-P space. If the first two bits of the Type-P Descriptor are 00, then the subsequent six bits specify the requested Differentiated Services Codepoint (DSCP) value of sent OWAMP-Test packets, as defined in [RFC2474]. If the first two bits of Type-P descriptor are 01, then the subsequent 16 bits specify the requested PHB Identification Code (PHB ID), as defined in [RFC2836].
Type-P記述子は、（非常に大きな）Type-Pスペースのサブセットのみをカバーします。Type-P記述子の最初の2ビットが00の場合、[RFC2474]で定義されているように、その後の6ビットは、送信されたOwamp-Testパケットの要求された差別化されたサービスコードポイント（DSCP）値を指定します。タイプP記述子の最初の2ビットが01の場合、[RFC2836]で定義されているように、その後の16ビットは要求されたPHB識別コード（PHB ID）を指定します。
Therefore, the value of all zeros specifies the default best-effort service.
したがって、すべてのゼロの値は、デフォルトのベストエフォートサービスを指定します。
If Conf-Sender is set, the Type-P Descriptor is to be used to configure the sender to send packets according to its value. If Conf-Sender is not set, the Type-P Descriptor is a declaration of how the sender will be configured.
conf-senderが設定されている場合、Type-p記述子を使用して、その値に応じてパケットを送信するように送信者を構成します。conf-senderが設定されていない場合、Type-p記述子は、送信者の構成方法の宣言です。
If Conf-Sender is set and the server does not recognize the Type-P Descriptor, or it cannot or does not wish to set the corresponding attributes on OWAMP-Test packets, it SHOULD reject the session request. If Conf-Sender is not set, the server SHOULD accept or reject the session, paying no attention to the value of the Type-P Descriptor.
conf-senderが設定されており、サーバーがType-p記述子を認識していない場合、またはOwamp-Testパケットに対応する属性を設定できない場合、または希望しない場合、セッションリクエストを拒否する必要があります。Conf-Senderが設定されていない場合、サーバーはセッションを受け入れたり拒否したりして、Type-P記述子の価値に注意を払わない必要があります。
To each Request-Session message, an OWAMP server MUST respond with an Accept-Session message:
各リクエストセッションメッセージに対して、OWAMPサーバーは受け入れセッションメッセージで応答する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | MBZ | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this message, zero in the Accept field means that the server is willing to conduct the session. A non-zero value indicates rejection of the request. The full list of available Accept values is described in Section 3.3, "Values of the Accept Field".
このメッセージでは、Acceptフィールドのゼロは、サーバーがセッションを喜んで実行することを意味します。ゼロ以外の値は、リクエストの拒否を示します。利用可能な受け入れ値の完全なリストは、セクション3.3「Acceptフィールドの値」で説明されています。
If the server rejects a Request-Session message, it SHOULD not close the TCP connection. The client MAY close it if it receives a negative response to the Request-Session message.
サーバーがリクエストセッションメッセージを拒否した場合、TCP接続を閉じることはできません。クライアントは、リクエストセッションメッセージに対する否定的な応答を受信した場合に閉じることができます。
The meaning of Port in the response depends on the values of Conf-Sender and Conf-Receiver in the query that solicited the response. If both were set, the Port field is unused. If only Conf-Sender was set, Port is the port from which to expect OWAMP-Test packets. If only Conf-Receiver was set, Port is the port to which OWAMP-Test packets are sent.
応答におけるポートの意味は、応答を求めているクエリのconf-senderとconf-receiverの値に依存します。両方が設定されている場合、ポートフィールドは未使用です。コンフセンダーのみが設定されている場合、ポートはオウムテストパケットを期待するポートです。Conf-Receiverのみが設定されている場合、ポートはOwamp-Testパケットが送信されるポートです。
If only Conf-Sender was set, the SID field in the response is unused. Otherwise, SID is a unique server-generated session identifier. It can be used later as handle to fetch the results of a session.
コンフセンダーのみが設定されている場合、応答のSIDフィールドは未使用です。それ以外の場合、SIDは一意のサーバーで生成されたセッション識別子です。後でハンドルとして使用して、セッションの結果を取得できます。
SIDs SHOULD be constructed by concatenation of the 4-octet IPv4 IP number belonging to the generating machine, an 8-octet timestamp, and a 4-octet random value. To reduce the probability of collisions, if the generating machine has any IPv4 addresses (with the exception of loopback), one of them SHOULD be used for SID generation, even if all communication is IPv6-based. If it has no IPv4 addresses at all, the last four octets of an IPv6 address MAY be used instead. Note that SID is always chosen by the receiver. If truly random values are not available, it is important that the SID be made unpredictable, as knowledge of the SID might be used for access control.
SIDは、生成マシン、8オクテットのタイムスタンプ、および4オクテットのランダム値に属する4-OCTET IPv4 IP番号の連結により構築する必要があります。衝突の可能性を減らすために、生成マシンにIPv4アドレスを持っている場合（ループバックを除く）、そのうちの1つはすべての通信がIPv6ベースであっても、SID生成に使用する必要があります。IPv4アドレスがまったくない場合、IPv6アドレスの最後の4オクテットを代わりに使用できます。SIDは常に受信機によって選択されることに注意してください。真にランダムな値が利用できない場合は、SIDの知識をアクセス制御に使用する可能性があるため、SIDを予測不可能にすることが重要です。
The sender and the receiver both need to know the same send schedule. This way, when packets are lost, the receiver knows when they were supposed to be sent. It is desirable to compress common schedules and still to be able to use an arbitrary one for the test sessions. In many cases, the schedule will consist of repeated sequences of packets: this way, the sequence performs some test, and the test is repeated a number of times to gather statistics.
送信者と受信者はどちらも同じ送信スケジュールを知る必要があります。このようにして、パケットが紛失した場合、受信者はいつ送信されるかを知っています。一般的なスケジュールを圧縮し、テストセッションに任意のスケジュールを使用できることが望ましいです。多くの場合、スケジュールはパケットの繰り返しシーケンスで構成されます。このように、シーケンスは何らかのテストを実行し、テストは何度も繰り返されて統計を収集します。
To implement this, we have a schedule with a given number of slots. Each slot has a type and a parameter. Two types are supported: exponentially distributed pseudo-random quantity (denoted by a code of 0) and a fixed quantity (denoted by a code of 1). The parameter is expressed as a timestamp and specifies a time interval. For a type 0 slot (exponentially distributed pseudo-random quantity), this interval is the mean value (or 1/lambda if the distribution density function is expressed as lambda*exp(-lambda*x) for positive values of x). For a type 1 (fixed quantity) slot, the parameter is the delay itself. The sender starts with the beginning of the schedule and executes the instructions in the slots: for a slot of type 0, wait an exponentially distributed time with a mean of the specified parameter and then send a test packet (and proceed to the next slot); for a slot of type 1, wait the specified time and send a test packet (and proceed to the next slot). The schedule is circular: when there are no more slots, the sender returns to the first slot.
これを実装するには、特定の数のスロットを持つスケジュールがあります。各スロットには、タイプとパラメーターがあります。2つのタイプがサポートされています：指数分布の擬似ランダム量（0のコードで示される）と固定量（1のコードで示される）。パラメーターはタイムスタンプとして表され、時間間隔を指定します。タイプ0スロット（指数分布の擬似ランダム量）の場合、この間隔は平均値（またはxの正値の分布密度関数がlambda*exp（-lambda*x）として表される場合の1/lambda）です。タイプ1（固定数量）スロットの場合、パラメーターは遅延自体です。送信者はスケジュールの開始から始まり、スロットの命令を実行します。タイプ0のスロットについては、指定されたパラメーターの平均で指数関数的に分散した時間を待ち、テストパケットを送信します（次のスロットに進みます）;タイプ1のスロットについては、指定された時間を待ってテストパケットを送信します（次のスロットに進みます）。スケジュールは円形です。スロットがなくなると、送信者は最初のスロットに戻ります。
The sender and the receiver need to be able to reproducibly execute the entire schedule (so, if a packet is lost, the receiver can still attach a send timestamp to it). Slots of type 1 are trivial to reproducibly execute. To reproducibly execute slots of type 0, we need to be able to generate pseudo-random exponentially distributed quantities in a reproducible manner. The way this is accomplished is discussed later in Section 5, "Computing Exponentially Distributed Pseudo-Random Numbers".
送信者とレシーバーは、スケジュール全体を再現できるように実行できる必要があります（したがって、パケットが紛失した場合、受信者はまだ送信タイムスタンプを接続できます）。タイプ1のスロットは、再現性があることに些細なことです。タイプ0のスロットを再現できるように実行するには、再現可能な方法で擬似ランダム指数分布の量を生成できる必要があります。これの達成方法については、セクション5「指数関数的に分布した擬似ランダム数」というセクション5で説明します。
Using this mechanism, one can easily specify common testing scenarios. The following are some examples:
このメカニズムを使用して、一般的なテストシナリオを簡単に指定できます。以下はいくつかの例です。
+ Poisson stream: a single slot of type 0.
+ ポアソンストリーム：タイプ0の単一スロット。
+ Periodic stream: a single slot of type 1.
+ 周期的なストリーム：タイプ1の単一スロット。
+ Poisson stream of back-to-back packet pairs: two slots, type 0 with a non-zero parameter and type 1 with a zero parameter.
+ バックツーバックパケットペアのポアソンストリーム：2つのスロット、非ゼロパラメーターを備えたタイプ0、ゼロパラメーターのタイプ1。
Further, a completely arbitrary schedule can be specified (albeit inefficiently) by making the number of test packets equal to the number of schedule slots. In this case, the complete schedule is transmitted in advance of an OWAMP-Test session.
さらに、テストパケットの数をスケジュールスロットの数に等しくすることにより、完全にarbitrary意的なスケジュールを（非効率的ではありますが）指定できます。この場合、完全なスケジュールは、OWAMPテストセッションの前に送信されます。
Having requested one or more test sessions and received affirmative Accept-Session responses, an OWAMP client MAY start the execution of the requested test sessions by sending a Start-Sessions message to the server.
1つ以上のテストセッションを要求し、肯定的な受け入れセッション応答を受け取ったため、OWAMPクライアントは、スタートセッションメッセージをサーバーに送信することにより、要求されたテストセッションの実行を開始する場合があります。
The format of this message is as follows:
このメッセージの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | |
+-+-+-+-+-+-+-+-+ |
| MBZ (15 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The server MUST respond with an Start-Ack message (which SHOULD be sent as quickly as possible). Start-Ack messages have the following format:
サーバーは、Start-ackメッセージ（できるだけ早く送信する必要がある）で応答する必要があります。Start-ackメッセージには、次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | |
+-+-+-+-+-+-+-+-+ |
| MBZ (15 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If Accept is non-zero, the Start-Sessions request was rejected; zero means that the command was accepted. The full list of available Accept values is described in Section 3.3, "Values of the Accept Field". The server MAY, and the client SHOULD, close the connection in the case of a rejection.
受け入れがゼロでない場合、スタートセッション要求は拒否されました。ゼロとは、コマンドが受け入れられたことを意味します。利用可能な受け入れ値の完全なリストは、セクション3.3「Acceptフィールドの値」で説明されています。サーバーは、拒否の場合に接続を閉じることができます。
The server SHOULD start all OWAMP-Test streams immediately after it sends the response or immediately after their specified start times, whichever is later. If the client represents a Sender, the client SHOULD start its OWAMP-Test streams immediately after it sees the Start-Ack response from the Server (if the Start-Sessions command was accepted) or immediately after their specified start times, whichever is later. See more on OWAMP-Test sender behavior in a separate section below.
サーバーは、応答を送信した直後または指定された開始時間のいずれか後の方向にすべてのOWAMPテストストリームを起動する必要があります。クライアントが送信者を表している場合、クライアントはサーバーからのスタートクロップの応答を確認した直後にOWAMPテストストリームを開始する必要があります（StartSessionsコマンドが受け入れられた場合）、または指定された開始時間の直後のいずれか遅い方。以下の別のセクションで、Owamp-Test Senderの動作の詳細を参照してください。
The Stop-Sessions message may be issued by either the Control-Client or the Server. The format of this command is as follows:
STOPセッションメッセージは、コントロールクライアントまたはサーバーのいずれかによって発行される場合があります。このコマンドの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | Accept | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sessions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is immediately followed by zero or more session description records (the number of session description records is specified in the "Number of Sessions" field above). The session description record is used to indicate which packets were actually sent by the sender process (rather than skipped). The header of the session description record is as follows:
これにより、すぐにセッションの説明レコードがゼロ以上です（セッションの説明記録の数は、上記の「セッションの数」フィールドで指定されています）。セッションの説明レコードは、（スキップではなく）送信者プロセスによって実際に送信されたパケットを示すために使用されます。セッション説明レコードのヘッダーは次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Skip Ranges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is immediately followed by zero or more Skip Range descriptions as specified by the "Number of Skip Ranges" field above. Skip Ranges are simply two sequence numbers that, together, indicate a range of packets that were not sent:
これに続いて、上記の「スキップ範囲の数」フィールドで指定されているように、ゼロ以上のスキップ範囲の説明が続きます。スキップ範囲は、送信されなかったパケットの範囲を一緒に示す2つのシーケンス番号にすぎません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| First Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Skip Ranges MUST be in order. The last (possibly full, possibly incomplete) block (16 octets) of data MUST be padded with zeros, if necessary. This ensures that the next session description record starts on a block boundary.
スキップ範囲は順調です。必要に応じて、最後の（おそらく完全な、おそらく不完全な）ブロック（16オクテット）のデータをゼロでパディングする必要があります。これにより、次のセッションの説明レコードがブロック境界で始まることが保証されます。
Finally, a single block (16 octets) of HMAC is concatenated on the end to complete the Stop-Sessions message.
最後に、HMACの単一のブロック（16オクテット）が最後に連結され、STOPセッションメッセージが完成します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All these records comprise one logical message: the Stop-Sessions command.
これらのすべてのレコードは、1つの論理メッセージで構成されています：STOPSESSIONSコマンド。
Above, the first octet (3) indicates that this is the Stop-Sessions command.
上記では、最初のオクテット（3）は、これがSTOPセッションコマンドであることを示しています。
Non-zero Accept values indicate a failure of some sort. Zero values indicate normal (but possibly premature) completion. The full list of available Accept values is described in Section 3.3, "Values of the Accept Field".
ゼロ以外の受け入れ値は、ある種の障害を示します。ゼロ値は、正常な（ただし早期）完了を示します。利用可能な受け入れ値の完全なリストは、セクション3.3「Acceptフィールドの値」で説明されています。
If Accept had a non-zero value (from either party), results of all OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD be considered invalid, even if a Fetch-Session with SID from this session works for a different OWAMP-Control session. If Accept was not transmitted at all (for whatever reason, including the TCP connection used for OWAMP-Control breaking), the results of all OWAMP-Test sessions spawned by this OWAMP-control session MAY be considered invalid.
Acceptがゼロ以外の値を持っていた場合（いずれかの当事者から）、このセッションのSIDとのフェッチセッションが異なるOWAMP-で機能する場合でも、このOWAMP-Controlセッションによって生まれたすべてのオウムテストセッションの結果は無効と見なされるべきです。コントロールセッション。受け入れがまったく送信されなかった場合（オウム制御の破壊に使用されるTCP接続を含む、何らかの理由で）、このOwamp-Controlセッションによって生まれたすべてのOwamp-Testセッションの結果は無効と見なされる場合があります。
Number of Sessions indicates the number of session description records that immediately follow the Stop-Sessions header.
セッションの数は、ストップセッションヘッダーに直後に続くセッション説明レコードの数を示します。
Number of Sessions MUST contain the number of send sessions started by the local side of the control connection that have not been previously terminated by a Stop-Sessions command (i.e., the Control-Client MUST account for each accepted Request-Session where Conf-Receiver was set; the Control-Server MUST account for each accepted Request-Session where Conf-Sender was set). If the Stop-Sessions message does not account for exactly the send sessions controlled by that side, then it is to be considered invalid and the connection SHOULD be closed and any results obtained considered invalid.
セッションの数には、ストップセッションコマンドによって以前に終了したことのないコントロール接続のローカル側によって開始された送信セッションの数を含める必要があります（つまり、コントロールクライアントは、conf-Receiverで受け入れられた要求セッションごとに説明する必要があります設定されました。コントロールサーバーは、コンフセンダーが設定された受け入れられた要求セッションごとに説明する必要があります。Stop-Sessionsメッセージがその側で制御された送信セッションを正確に考慮していない場合、それは無効であると見なされ、接続を閉じて、得られた結果は無効と見なされます。
Each session description record represents one OWAMP-Test session.
各セッションの説明レコードは、1つのオウムテストセッションを表します。
SID is the session identifier (SID) used to indicate which send session is being described.
SIDは、どのセッションセッションが記載されているかを示すために使用されるセッション識別子（SID）です。
Next Seqno indicates the next sequence number that would have been sent from this send session. For completed sessions, this will equal NumPackets from the Request-Session.
次のSeqnoは、この送信セッションから送信される次のシーケンス番号を示します。完了したセッションの場合、これはリクエストセッションからのナンバーパケットに等しくなります。
Number of Skip Ranges indicates the number of holes that actually occurred in the sending process. This is a range of packets that were never actually sent by the sending process. For example, if a send session is started too late for the first 10 packets to be sent and this is the only hole in the schedule, then "Number of Skip Ranges" would be 1. The single Skip Range description will have First Seqno Skipped equal to 0 and Last Seqno Skipped equal to 9. This is described further in the "Sender Behavior" section.
スキップ範囲の数は、送信プロセスで実際に発生した穴の数を示します。これは、送信プロセスによって実際に送信されたことのないパケットの範囲です。たとえば、送信セッションが開始された場合、最初の10個のパケットが送信され、これがスケジュールの唯一のホールである場合、「スキップ範囲の数」が1になります。0に等しく、最後のSeqnoは9に等しくスキップされました。これは、「送信者の動作」セクションでさらに説明されています。
If the OWAMP-Control connection breaks when the Stop-Sessions command is sent, the receiver MAY not completely invalidate the session results. It MUST discard all record of packets that follow (in other words, that have greater sequence number than) the last packet that was actually received before any lost packet records. This will help differentiate between packet losses that occurred in the network and packets the sending process may have never sent.
Stop-Sessionsコマンドが送信されたときにOwamp-Control接続が壊れた場合、受信者はセッションの結果を完全に無効にしない場合があります。失われたパケットレコードの前に実際に受信された最後のパケットを（言い換えれば、シーケンス数が大きい）パケットのすべてのレコードを破棄する必要があります。これは、ネットワークで発生したパケット損失と、送信プロセスが送信したことのないパケットを区別するのに役立ちます。
If a receiver of an OWAMP-Test session learns, through an OWAMP-Control Stop-Sessions message, that the OWAMP-Test sender's last sequence number is lower than any sequence number actually received, the results of the complete OWAMP-Test session MUST be invalidated.
OWAMP-TESTセッションの受信者が、OWAMP-Control Stop-Sessionsメッセージを通じて、Owamp-Test Senderの最後のシーケンス番号が実際に受信したシーケンス番号よりも低いことを学習する場合、完全なOwamp-Testセッションの結果は無効。
A receiver of an OWAMP-Test session, upon receipt of an OWAMP-Control Stop-Sessions command, MUST discard any packet records -- including lost packet records -- with a (computed) send time that falls between the current time minus Timeout and the current time. This ensures statistical consistency for the measurement of loss and duplicates in the event that the Timeout is greater than the time it takes for the Stop-Sessions command to take place.
OWAMP-Control Stop-Sessionsコマンドを受信したときに、OWAMP-TESTセッションの受信者は、現在の時間からタイムアウトとタイムアウトの間に低下する（計算された）送信時間を含むパケットレコード（紛失したパケットレコードを含む）を破棄する必要があります。現在の時刻。これにより、タイムアウトがSTOPセッションコマンドが行われるのにかかる時間よりも大きい場合に、損失の測定と重複の統計的一貫性が保証されます。
To effect complete sessions, each side of the control connection SHOULD wait until all sessions are complete before sending the Stop-Sessions message. The completed time of each session is determined as Timeout after the scheduled time for the last sequence number. Endpoints MAY add a small increment to the computed completed time for send endpoints to ensure that the Stop-Sessions message reaches the receiver endpoint after Timeout.
完全なセッションを実施するために、コントロール接続の各側面は、すべてのセッションが完了するまで待機してから、STOPセッションメッセージを送信する必要があります。各セッションの完了時間は、最後のシーケンス番号のスケジュールされた時間の後のタイムアウトとして決定されます。エンドポイントは、計算された完了時間に小さな増分を追加して、エンドポイントを送信するために、ストップセッションメッセージがタイムアウト後に受信機エンドポイントに到達するようにする場合があります。
To effect a premature stop of sessions, the party that initiates this command MUST stop its OWAMP-Test send streams to send the Session Packets Sent values before sending this command. That party SHOULD wait until receiving the response Stop-Sessions message before stopping the receiver streams so that it can use the values from the received Stop-Sessions message to validate the data.
セッションの時期尚早の停止を実施するために、このコマンドを開始する当事者は、このコマンドを送信する前に、セッションパケットの送信値を送信するためにストリームを送信する停止を停止する必要があります。その当事者は、受信された停止セッションメッセージの値を使用してデータを検証できるように、レシーバーストリームを停止する前に、応答ストップセッションメッセージを受信するまで待つ必要があります。
The format of this client command is as follows:
このクライアントコマンドの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | |
+-+-+-+-+-+-+-+-+ |
| MBZ (7 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Begin Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Begin Seq is the sequence number of the first requested packet. End Seq is the sequence number of the last requested packet. If Begin Seq is all zeros and End Seq is all ones, complete session is said to be requested.
開始四点は、最初の要求されたパケットのシーケンス番号です。End Seqは、最後に要求されたパケットのシーケンス番号です。開始seqがすべてゼロであり、seqがすべて1つである場合、完全なセッションが要求されると言われています。
If a complete session is requested and the session is still in progress or has terminated in any way other than normally, the request to fetch session results MUST be denied. If an incomplete session is requested, all packets received so far that fall into the requested range SHOULD be returned. Note that, since no commands can be issued between Start-Sessions and Stop-Sessions, incomplete requests can only happen on a different OWAMP-Control connection (from the same or different host as Control-Client).
完全なセッションが要求され、セッションがまだ進行中であるか、通常以外の方法で終了した場合、セッションの結果を取得するリクエストは拒否されなければなりません。不完全なセッションが要求された場合、要求された範囲に分類されるこれまでに受信したすべてのパケットを返す必要があります。スタートセッションとストップセッションの間にコマンドを発行できないため、不完全なリクエストは、異なるowampコントロール接続（コントロールクライアントと同じまたは異なるホストから）でのみ発生する可能性があることに注意してください。
The server MUST respond with a Fetch-Ack message. The format of this server response is as follows:
サーバーは、Fetch-ackメッセージで応答する必要があります。このサーバーの応答の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | Finished | MBZ (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Skip Ranges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Again, non-zero in the Accept field means a rejection of command. The server MUST specify zero for all remaining fields if Accept is non-zero. The client MUST ignore all remaining fields (except for the HMAC) if Accept is non-zero. The full list of available Accept values is described in Section 3.3, "Values of the Accept Field".
繰り返しますが、ゼロ以外のフィールドはコマンドの拒否を意味します。受領がゼロでない場合、サーバーは、残りのすべてのフィールドにゼロを指定する必要があります。受け入れがゼロである場合、クライアントは残りのすべてのフィールド（HMACを除く）を無視する必要があります。利用可能な受け入れ値の完全なリストは、セクション3.3「Acceptフィールドの値」で説明されています。
Finished is non-zero if the OWAMP-Test session has terminated.
OWAMPテストセッションが終了した場合、完成はゼロではありません。
Next Seqno indicates the next sequence number that would have been sent from this send session. For completed sessions, this will equal NumPackets from the Request-Session. This information is only available if the session has terminated. If Finished is zero, then Next Seqno MUST be set to zero by the server.
次のSeqnoは、この送信セッションから送信される次のシーケンス番号を示します。完了したセッションの場合、これはリクエストセッションからのナンバーパケットに等しくなります。この情報は、セッションが終了した場合にのみ利用可能です。終了がゼロの場合、次のSeqnoをサーバーによってゼロに設定する必要があります。
Number of Skip Ranges indicates the number of holes that actually occurred in the sending process. This information is only available if the session has terminated. If Finished is zero, then Skip Ranges MUST be set to zero by the server.
スキップ範囲の数は、送信プロセスで実際に発生した穴の数を示します。この情報は、セッションが終了した場合にのみ利用可能です。終了がゼロの場合、サーバーによってスキップ範囲をゼロに設定する必要があります。
Number of Records is the number of packet records that fall within the requested range. This number might be less than the Number of Packets in the reproduction of the Request-Session command because of a session that ended prematurely, or it might be greater because of duplicates.
レコードの数は、要求された範囲内にあるパケットレコードの数です。この数は、早期に終了したセッションのため、リクエストセッションコマンドの再現のパケットの数よりも少ないか、重複のために大きい場合があります。
If Accept was non-zero, this concludes the response to the Fetch-Session message. If Accept was 0, the server then MUST immediately send the OWAMP-Test session data in question.
受け入れがゼロ以外の場合、これはフェッチセッションメッセージへの応答を終了します。受け入れが0の場合、サーバーはすぐに問題のOWAMP-TESTセッションデータを送信する必要があります。
The OWAMP-Test session data consists of the following (concatenated):
Owamp-Testセッションのデータは、次の（連結）で構成されています。
+ A reproduction of the Request-Session command that was used to start the session; it is modified so that actual sender and receiver port numbers that were used by the OWAMP-Test session always appear in the reproduction.
+ セッションを開始するために使用されたリクエストセッションコマンドの複製。OWAMPテストセッションで使用された実際の送信者と受信機のポート番号が常に複製に表示されるように変更されます。
+ Zero or more (as specified) Skip Range descriptions. The last (possibly full, possibly incomplete) block (16 octets) of Skip Range descriptions is padded with zeros, if necessary.
+ ゼロ以上（指定されている）スキップ範囲の説明。スキップレンジの説明の最後の（おそらく完全な、おそらく不完全な）ブロック（16オクテット）には、必要に応じてゼロが詰め込まれています。
+ 16 octets of HMAC.
+ HMACの16オクテット。
+ Zero or more (as specified) packet records. The last (possibly full, possibly incomplete) block (16 octets) of data is padded with zeros, if necessary.
+ ゼロ以上（指定されている）パケットレコード。データの最後の（おそらく完全な、おそらく不完全な）ブロック（16オクテット）は、必要に応じてゼロでパディングされています。
+ 16 octets of HMAC.
+ HMACの16オクテット。
Skip Range descriptions are simply two sequence numbers that, together, indicate a range of packets that were not sent:
スキップ範囲の説明は、単に送信されなかったパケットの範囲を示している2つのシーケンス番号です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| First Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Skip Range descriptions should be sent out in order, as sorted by First Seqno. If any Skip Ranges overlap or are out of order, the session data is to be considered invalid and the connection SHOULD be closed and any results obtained considered invalid.
最初のseqnoでソートされたように、スキップ範囲の説明を整理する必要があります。スキップの範囲が重複しているか、故障していない場合、セッションデータは無効であると見なされ、接続を閉じて、得られた結果は無効と見なされます。
Each packet record is 25 octets and includes 4 octets of sequence number, 8 octets of send timestamp, 2 octets of send timestamp error estimate, 8 octets of receive timestamp, 2 octets of receive timestamp error estimate, and 1 octet of Time To Live (TTL), or Hop Limit in IPv6:
各パケットレコードは25オクテットで、シーケンス番号の4オクテット、送信タイムスタンプ8オクテット、送信タイムスタンプエラー推定の2オクテット、受信タイムスタンプの8オクテット、受信タイムスタンプエラーの推定値2オクテット、1オクテットの時間（ttl）、またはIPv6のホップ制限：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00| Seq Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04| Send Error Estimate | Receive Error Estimate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
08| Send Timestamp |
12| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16| Receive Timestamp |
20| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24| TTL |
+-+-+-+-+-+-+-+-+
Packet records are sent out in the same order the actual packets were received. Therefore, the data is in arrival order.
パケットレコードは、実際のパケットを受信したのと同じ順序で送信されます。したがって、データは到着順になります。
Note that lost packets (if any losses were detected during the OWAMP-Test session) MUST appear in the sequence of packets. They can appear either at the point when the loss was detected or at any later point. Lost packet records are distinguished as follows:
失われたパケット（OWAMPテストセッション中に損失が検出された場合）は、パケットのシーケンスに表示される必要があることに注意してください。それらは、損失が検出された時点で、または後のポイントで表示される可能性があります。紛失したパケットレコードは次のように区別されます。
+ A send timestamp filled with the presumed send time (as computed by the send schedule).
+ 推定された送信時間で満たされた送信タイムスタンプ（送信スケジュールで計算されます）。
+ A send error estimate filled with Multiplier=1, Scale=64, and S=0 (see the OWAMP-Test description for definition of these quantities and explanation of timestamp format and error estimate format).
+ 乗数= 1、スケール= 64、およびs = 0で満たされた送信エラー推定値（これらの数量の定義とタイムスタンプ形式の説明とエラー推定形式の説明については、owamp-testの説明を参照）。
+ A normal receive error estimate as determined by the error of the clock being used to declare the packet lost. (It is declared lost if it is not received by the Timeout after the presumed send time, as determined by the receiver's clock.)
+ 失われたパケットを宣言するために使用されているクロックのエラーによって決定される通常の受信エラー推定値。（受信者の時計で決定されたと推定された送信時間後にタイムアウトで受信されない場合、それは紛失されたと宣言されます。）
+ A receive timestamp consisting of all zero bits.
+ すべてのゼロビットで構成される受信タイムスタンプ。
+ A TTL value of 255.
+ 255のTTL値。
This section describes OWAMP-Test protocol. It runs over UDP, using sender and receiver IP and port numbers negotiated during the Request-Session exchange.
このセクションでは、Owamp-Testプロトコルについて説明します。リクエストセッションの交換中にネゴシエートされた送信者と受信機のIPおよびポート番号を使用して、UDPを介して実行されます。
As with OWAMP-Control, OWAMP-Test has three modes: unauthenticated, authenticated, and encrypted. All OWAMP-Test sessions that are spawned by an OWAMP-Control session inherit its mode.
Owamp-Controlと同様に、Owamp-Testには3つのモードがあります。Owamp-Controlセッションによって生成されるすべてのオウムテストセッションは、そのモードを継承します。
OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and OWAMP-Test receiver can potentially all be different machines. (In a typical case, we expect that there will be only two machines.)
Owamp-Controlクライアント、Owamp-Control Server、Owamp-Test Sender、およびOwamp-Test受信機は、すべてが異なるマシンになる可能性があります。（典型的なケースでは、マシンが2つしかないと予想されます。）
Send schedules based on slots, described previously, in conjunction with scheduled session start time, enable the sender and the receiver to compute the same exact packet sending schedule independently of each other. These sending schedules are independent for different OWAMP-Test sessions, even if they are governed by the same OWAMP-Control session.
スロットに基づいてスケジュールを送信して、スケジュールされたセッション開始時間と組み合わせて、送信者と受信機が互いに独立してスケジュールを送信するのとまったく同じパケット送信スケジュールを計算できるようにします。これらの送信スケジュールは、同じOWAMP-Controlセッションによって管理されている場合でも、異なるオウムテストセッションで独立しています。
Consider any OWAMP-Test session. Once Start-Sessions exchange is complete, the sender is ready to start sending packets. Under normal OWAMP use circumstances, the time to send the first packet is in the near future (perhaps a fraction of a second away). The sender SHOULD send packets as close as possible to their scheduled time, with the following exception: if the scheduled time to send is in the past, and is separated from the present by more than Timeout time, the sender MUST NOT send the packet. (Indeed, such a packet would be considered lost by the receiver anyway.) The sender MUST keep track of which packets it does not send. It will use this to tell the receiver what packets were not sent by setting Skip Ranges in the Stop-Sessions message from the sender to the receiver upon completion of the test. The Skip Ranges are also sent to a Fetch-Client as part of the session data results. These holes in the sending schedule can happen if a time in the past was specified in the Request-Session command, or if the Start-Sessions exchange took unexpectedly long, or if the sender could not start serving the OWAMP-Test session on time due to internal scheduling problems of the OS. Packets that are in the past but are separated from the present by less than Timeout value SHOULD be sent as quickly as possible. With normal test rates and timeout values, the number of packets in such a burst is limited. Nevertheless, hosts SHOULD NOT intentionally schedule sessions so that such bursts of packets occur.
オウムテストセッションを検討してください。Start-Sessions Exchangeが完了すると、送信者はパケットの送信を開始する準備ができています。通常のOWAMPの使用状況では、最初のパケットを送信する時間は近い将来です（おそらく1秒のほんの一部です）。送信者は、次の例外を除いて、スケジュールされた時間にできるだけ近いパケットを送信する必要があります。送信時間が過去に行われ、タイムアウト時間よりも現在から分離されている場合、送信者はパケットを送信してはなりません。（実際、そのようなパケットはとにかく受信機によって失われたと見なされます。）送信者は、送信されないパケットを追跡する必要があります。これを使用して、テストの完了時に送信者からレシーバーにSKIP範囲を設定することにより、受信機に送信されなかったものを伝えます。スキップ範囲は、セッションデータの結果の一部としてフェッチクライアントにも送信されます。送信スケジュールのこれらの穴は、過去の時間がリクエストセッションコマンドで指定された場合、またはスタートセッションの交換が予期せずに長くなった場合、または送信者が期限内にOWAMPテストセッションの提供を開始できなかった場合に発生する可能性があります。OSの内部スケジューリングの問題に。過去にあるが、タイムアウト値未満で現在から分離されているパケットは、できるだけ早く送信する必要があります。通常のテストレートとタイムアウト値では、このようなバーストのパケットの数は限られています。それにもかかわらず、ホストは、このようなパケットのバーストが発生するように、意図的にセッションをスケジュールするべきではありません。
Regardless of any scheduling delays, each packet that is actually sent MUST have the best possible approximation of its real time of departure as its timestamp (in the packet).
スケジューリングの遅延に関係なく、実際に送信される各パケットには、タイムスタンプとしてのリアルタイムの最良の近似値が必要です（パケット内）。
The sender sends the receiver a stream of packets with the schedule specified in the Request-Session command. The sender SHOULD set the TTL in IPv4 (or Hop Limit in IPv6) in the UDP packet to 255. The format of the body of a UDP packet in the stream depends on the mode being used.
送信者は、リクエストセッションコマンドで指定されたスケジュールを使用して、受信者にパケットのストリームを送信します。送信者は、UDPパケットのIPv4（またはIPv6のホップ制限）にTTLを255に設定する必要があります。ストリーム内のUDPパケットのボディの形式は、使用されているモードによって異なります。
For unauthenticated mode:
認証されていないモードの場合：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For authenticated and encrypted modes:
認証された暗号化されたモードの場合：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the timestamp is the same as in [RFC1305] and is as follows: the first 32 bits represent the unsigned integer number of seconds elapsed since 0h on 1 January 1900; the next 32 bits represent the fractional part of a second that has elapsed since then.
タイムスタンプの形式は[RFC1305]と同じであり、次のとおりです。最初の32ビットは、1900年1月1日の0H以降の符号なし整数秒数を表します。次の32ビットは、それ以来経過した秒の分数部分を表します。
So, Timestamp is represented as follows:
したがって、タイムスタンプは次のように表されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fractional part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Estimate specifies the estimate of the error and synchronization. It has the following format:
エラー推定値は、エラーと同期の推定値を指定します。次の形式があります。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|Z| Scale | Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first bit, S, SHOULD be set if the party generating the timestamp has a clock that is synchronized to UTC using an external source (e.g., the bit should be set if GPS hardware is used and it indicates that it has acquired current position and time or if NTP is used and it indicates that it has synchronized to an external source, which includes stratum 0 source, etc.). If there is no notion of external synchronization for the time source, the bit SHOULD NOT be set. The next bit has the same semantics as MBZ fields elsewhere: it MUST be set to zero by the sender and ignored by everyone else. The next six bits, Scale, form an unsigned integer; Multiplier is an unsigned integer as well. They are interpreted as follows: the error estimate is equal to Multiplier*2^(-32)*2^Scale (in seconds). (Notation clarification: 2^Scale is two to the power of Scale.) Multiplier MUST NOT be set to zero. If Multiplier is zero, the packet SHOULD be considered corrupt and discarded.
タイムスタンプを生成するパーティが外部ソースを使用してUTCに同期するクロックを持っている場合、最初のビットsを設定する必要があります（たとえば、GPSハードウェアを使用している場合はビットを設定する必要があり、現在の位置を取得したことを示します。時間またはNTPが使用されている場合、Stratum0ソースなどを含む外部ソースに同期していることを示します。時間ソースの外部同期の概念がない場合、ビットを設定しないでください。次のビットには、他の場所のMBZフィールドと同じセマンティクスがあります。送信者がゼロに設定し、他のすべての人に無視する必要があります。次の6つのビット、スケールは、署名されていない整数を形成します。乗数は、署名されていない整数でもあります。それらは次のように解釈されます：エラー推定は乗数に等しくなります*2^（ - 32）*2^スケール（秒単位）。（表記の明確化：2^スケールはスケールの力の2つです。）乗数はゼロに設定してはなりません。乗数がゼロの場合、パケットは腐敗し、破棄されると見なされる必要があります。
Sequence numbers start with zero and are incremented by one for each subsequent packet.
シーケンス番号はゼロで始まり、後続のパケットごとに1つずつ増加します。
The minimum data segment length is, therefore, 14 octets in unauthenticated mode, and 48 octets in both authenticated mode and encrypted modes.
したがって、最小データセグメントの長さは、認証モードと暗号化されたモードの両方で、認証モードで14オクテット、48オクテットです。
The OWAMP-Test packet layout is the same in authenticated and encrypted modes. The encryption and authentication operations are, however, different. The difference is that in encrypted mode both the sequence number and the timestamp are protected to provide maximum data confidentiality and integrity protection, whereas in authenticated mode the sequence number is protected while the timestamp is sent in clear text. Sending the timestamp in clear text in authenticated mode allows one to reduce the time between when a timestamp is obtained by a sender and when the packet is shipped out. In encrypted mode, the sender has to fetch the timestamp, encrypt it, and send it; in authenticated mode, the middle step is removed, potentially improving accuracy (the sequence number can be encrypted and authenticated before the timestamp is fetched).
OWAMP-TESTパケットレイアウトは、認証されたモードと暗号化されたモードで同じです。ただし、暗号化と認証操作は異なります。違いは、暗号化モードでは、シーケンス番号とタイムスタンプの両方が保護され、最大のデータの機密性と整合性保護を提供するのに対し、認証モードではタイムスタンプが明確なテキストで送信される間にシーケンス番号が保護されます。認証されたモードでクリアテキストでタイムスタンプを送信すると、送信者がタイムスタンプが取得されたときとパケットが出荷されるときの間の時間を短縮できます。暗号化モードでは、送信者はタイムスタンプを取得し、暗号化して送信する必要があります。認証モードでは、中央のステップが削除され、精度が向上する可能性があります（タイムスタンプが取得される前にシーケンス数を暗号化して認証できます）。
In authenticated mode, the first block (16 octets) of each packet is encrypted using AES Electronic Cookbook (ECB) mode.
認証モードでは、各パケットの最初のブロック（16オクテット）は、AES Electronic Cookbook（ECB）モードを使用して暗号化されます。
Similarly to each OWAMP-Control session, each OWAMP-Test session has two keys: an AES Session-key and an HMAC Session-key. However, there is a difference in how the keys are obtained: in the case of OWAMP-Control, the keys are generated by the client and communicated (as part of the Token) during connection setup as part of Set-Up-Response message; in the case of OWAMP-Test, described here, the keys are derived from the OWAMP-Control keys and the SID.
各OWAMP-Controlセッションと同様に、各Owampテストセッションには、AESセッションキーとHMACセッションキーの2つのキーがあります。ただし、キーの取得方法には違いがあります。OWAMP-Controlの場合、キーはクライアントによって生成され、セットアップ応答メッセージの一部として接続セットアップ中に（トークンの一部として）通信されます。ここで説明するOwamp-Testの場合、キーはOwamp-ControlキーとSIDから派生しています。
The OWAMP-Test AES Session-key is obtained as follows: the OWAMP-Control AES Session-key (the same AES Session-key as is used for the corresponding OWAMP-Control session, where it is used in a different chaining mode) is encrypted, using AES, with the 16-octet session identifier (SID) as the key; this is a single-block ECB encryption; its result is the OWAMP-Test AES Session-key to use in encrypting (and decrypting) the packets of the particular OWAMP-Test session. Note that all of OWAMP-Test AES Session-key, OWAMP-Control AES Session-key, and the SID are comprised of 16 octets.
OWAMP-TEST AESセッションキーは次のように取得されます。OWAMP-Control AESセッションキー（別のチェーンモードで使用される対応するOwamp-Controlセッションに使用されるのと同じAESセッションキー）はAEを使用して暗号化され、16オクテットのセッション識別子（SID）をキーとして。これは単一ブロックECB暗号化です。その結果、特定のOWAMPテストセッションのパケットを暗号化（および復号化）して使用するOWAMP-TEST AES SESSION-KEYが発生しました。OWAMP-TEST AESセッションキー、OWAMPコントロールAESセッションキー、およびSIDは16オクテットで構成されていることに注意してください。
The OWAMP-Test HMAC Session-key is obtained as follows: the OWAMP-Control HMAC Session-key (the same HMAC Session-key as is used for the corresponding OWAMP-Control session) is encrypted, using AES, with the 16-octet session identifier (SID) as the key; this is a two-block CBC encryption, always performed with IV=0; its result is the OWAMP-Test HMAC Session-key to use in authenticating the packets of the particular OWAMP-Test session. Note that all of OWAMP-Test HMAC Session-key and OWAMP-Control HMAC Session-key are comprised of 32 octets, while the SID is 16 octets.
OWAMP-TEST HMACセッションキーは次のように取得されます。OWAMP-Control HMAC Session-Key（対応するOwamp-Controlセッションに使用されるのと同じHMAC Session-Key）は、AEを使用して暗号化されています。キーとしてセッション識別子（SID）。これは2ブロックのCBC暗号化で、常にIV = 0で実行されます。その結果、特定のOwamp-Testセッションのパケットの認証に使用するOwamp-Test HMAC Session-Keyが使用されます。Owamp-Test HMAC Session-KeyとOwamp-Control HMAC Session-Keyはすべて32個のオクテットで構成されており、SIDは16オクテットであることに注意してください。
ECB mode used for encrypting the first block of OWAMP-Test packets in authenticated mode does not involve any actual chaining; this way, lost, duplicated, or reordered packets do not cause problems with deciphering any packet in an OWAMP-Test session.
認証されたモードでOwamp-Testパケットの最初のブロックを暗号化するために使用されるECBモードは、実際のチェーンは含まれません。このようにして、紛失、複製、または並べ替えられたパケットは、オウムテストセッションでパケットを解読することに問題を引き起こしません。
In encrypted mode, the first two blocks (32 octets) are encrypted using AES CBC mode. The AES Session-key to use is obtained in the same way as the key for authenticated mode. Each OWAMP-Test packet is encrypted as a separate stream, with just one chaining operation; chaining does not span multiple packets so that lost, duplicated, or reordered packets do not cause problems. The initialization vector for the CBC encryption is a value with all bits equal to zero.
暗号化モードでは、最初の2つのブロック（32オクテット）がAES CBCモードを使用して暗号化されます。使用するAESセッションキーは、認証モードのキーと同じ方法で取得されます。各OWAMP-TESTパケットは、1つのチェーン操作を備えた別のストリームとして暗号化されています。チェーンは複数のパケットにまたがっていないため、紛失、複製、または並べ替えられたパケットが問題を引き起こさないようにします。CBC暗号化の初期化ベクトルは、すべてのビットがゼロに等しい値です。
Implementation note: Naturally, the key schedule for each OWAMP-Test session MAY be set up only once per session, not once per packet.
実装注：当然、各オウムテストセッションの重要なスケジュールは、セッションごとに1回だけセットアップでき、パケットごとに1回ではありません。
HMAC in OWAMP-Test only covers the part of the packet that is also encrypted. So, in authenticated mode, HMAC covers the first block (16 octets); in encrypted mode, HMAC covers two first blocks (32 octets). In OWAMP-Test HMAC is not encrypted (note that this is different from OWAMP-Control, where encryption in stream mode is used, so everything including the HMAC blocks ends up being encrypted).
Owamp-TestのHMACは、暗号化されたパケットの部分のみをカバーします。したがって、認証されたモードでは、HMACは最初のブロック（16オクテット）をカバーします。暗号化モードでは、HMACは2つの最初のブロック（32オクテット）をカバーします。Owamp-Testでは、HMACは暗号化されていません（これは、ストリームモードの暗号化が使用されるOwamp-Controlとは異なるため、HMACブロックを含むすべてが暗号化されることに注意してください）。
In unauthenticated mode, no encryption or authentication is applied.
認識されていないモードでは、暗号化や認証は適用されません。
Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be generated independently of any other pseudo-random numbers mentioned in this document). However, implementations MUST provide a configuration parameter, an option, or a different means of making Packet Padding consist of all zeros.
オウムテストのパケットパディングは擬似ランダムでなければなりません（この文書に記載されている他の擬似ランダム数とは無関係に生成する必要があります）。ただし、実装は、構成パラメーター、オプション、またはすべてのゼロで構成されるパケットパディングを作成する別の手段を提供する必要があります。
The time elapsed between packets is computed according to the slot schedule as mentioned in Request-Session command description. At that point, we skipped over the issue of computing exponentially distributed pseudo-random numbers in a reproducible fashion. It is discussed later in a separate section.
リクエストセッションコマンドの説明に記載されているように、パケット間で経過する時間は、スロットスケジュールに従って計算されます。その時点で、私たちは、指数関数的に分布した擬似ランダム数を再現可能な方法で計算する問題をスキップしました。後で別のセクションで説明します。
The receiver knows when the sender will send packets. The following parameter is defined: Timeout (from Request-Session). Packets that are delayed by more than Timeout are considered lost (or "as good as lost"). Note that there is never an actual assurance of loss by the network: a "lost" packet might still be delivered at any time. The original specification for IPv4 required that packets be delivered within TTL seconds or never (with TTL having a maximum value of 255). To the best of the authors' knowledge, this requirement was never actually implemented (and, of course, only a complete and universal implementation would ensure that packets do not travel for longer than TTL seconds). In fact, in IPv6, the name of this field has actually been changed to Hop Limit. Further, IPv4 specification makes no claims about the time it takes the packet to traverse the last link of the path.
受信者は、送信者がいつパケットを送信するかを知っています。次のパラメーターが定義されています：タイムアウト（リクエストセッションから）。タイムアウト以上に遅れているパケットは、失われたと見なされます（または「失われたのと同じくらい良い」）。ネットワークによる実際の損失の保証は決してないことに注意してください。「失われた」パケットはいつでも配信される可能性があります。IPv4の元の仕様では、パケットをTTL秒以内に配信するか、決して（TTLの最大値が255の値があります）が必要でした。著者の知る限り、この要件は実際に実装されることはありませんでした（そしてもちろん、完全かつ普遍的な実装のみが、パケットがTTL秒よりも長く移動しないことを保証します）。実際、IPv6では、このフィールドの名前が実際にホップ制限に変更されています。さらに、IPv4仕様は、パスの最後のリンクをトラバースするのにパケットをかける時間について主張しません。
The choice of a reasonable value of Timeout is a problem faced by a user of OWAMP protocol, not by an implementor. A value such as two minutes is very safe. Note that certain applications (such as interactive "one-way ping" might wish to obtain the data faster than that.
タイムアウトの合理的な価値の選択は、実装者ではなく、OWAMPプロトコルのユーザーが直面する問題です。2分などの値は非常に安全です。特定のアプリケーション（インタラクティブな「一方向ping」などのアプリケーションは、それよりも速くデータを取得したい場合があることに注意してください。
As packets are received,
パケットが受信されると、
+ timestamp the received packet;
+ タイムスタンプ受信パケット。
+ in authenticated or encrypted mode, decrypt and authenticate as necessary (packets for which authentication fails MUST be discarded); and
+ 認証または暗号化されたモードでは、必要に応じて復号化して認証します（認証が失敗するパケットは破棄する必要があります）。と
+ store the packet sequence number, send time, receive time, and the TTL for IPv4 (or Hop Limit for IPv6) from the packet IP header for the results to be transferred.
+ パケットシーケンス番号を保存し、時間を送信し、時間を受信し、TTLはIPv4のTTL（またはIPv6のホップ制限）をパケットIPヘッダーから転送します。
Packets not received within the Timeout are considered lost. They are recorded with their true sequence number, presumed send time, receive time value with all bits being zero, and a TTL (or Hop Limit) of 255.
タイムアウト内で受信されていないパケットは失われたと見なされます。それらは、真のシーケンス番号で記録され、送信時間と推定され、すべてのビットがゼロであるか、255のTTL（またはホップ制限）で時間の値を受け取ります。
Implementations SHOULD fetch the TTL/Hop Limit value from the IP header of the packet. If an implementation does not fetch the actual TTL value (the only good reason not to do so is an inability to access the TTL field of arriving packets), it MUST record the TTL value as 255.
実装は、パケットのIPヘッダーからTTL/ホップ制限値を取得する必要があります。実装が実際のTTL値を取得しない場合（そうしない唯一の理由は、到着パケットのTTLフィールドにアクセスできないことです）、TTL値を255として記録する必要があります。
Packets that are actually received are recorded in the order of arrival. Lost packet records serve as indications of the send times of lost packets. They SHOULD be placed either at the point where the receiver learns about the loss or at any later point; in particular, one MAY place all the records that correspond to lost packets at the very end.
Packets that have send time in the future MUST be recorded normally, without changing their send timestamp, unless they have to be discarded. (Send timestamps in the future would normally indicate clocks that differ by more than the delay. Some data -- such as jitter -- can be extracted even without knowledge of time difference. For other kinds of data, the adjustment is best handled by the data consumer on the basis of the complete information in a measurement session, as well as, possibly, external data.)
将来の時間を送信したパケットは、廃棄する必要がない限り、送信タイムスタンプを変更することなく、正常に記録する必要があります。（将来のタイムスタンプを送信することは通常、遅延よりも異なるクロックを示します。ジッターなどの一部のデータは、時間差の知識がなくても抽出できます。データ消費者測定セッションの完全な情報に基づいて、おそらく外部データ。）
Packets with a sequence number that was already observed (duplicate packets) MUST be recorded normally. (Duplicate packets are sometimes introduced by IP networks. The protocol has to be able to measure duplication.)
すでに観察されているシーケンス番号を持つパケット（重複パケット）は正常に記録する必要があります。（重複パケットは、IPネットワークによって導入されることがあります。プロトコルは重複を測定できる必要があります。）
If any of the following is true, the packet MUST be discarded:
以下のいずれかが当てはまる場合、パケットを破棄する必要があります。
+ Send timestamp is more than Timeout in the past or in the future.
+ 送信タイムスタンプは、過去または将来のタイムアウト以上のものです。
+ Send timestamp differs by more than Timeout from the time when the packet should have been sent according to its sequence number.
+ 送信タイムスタンプは、シーケンス番号に従ってパケットが送信されるべき時にタイムアウト以上に異なります。
+ In authenticated or encrypted mode, HMAC verification fails.
+ 認証または暗号化されたモードでは、HMAC検証に失敗します。
Here we describe the way exponential random quantities used in the protocol are generated. While there is a fair number of algorithms for generating exponential random variables, most of them rely on having logarithmic function as a primitive, resulting in potentially different values, depending on the particular implementation of the math library. We use algorithm 3.4.1.S from [KNUTH], which is free of the above-mentioned problem, and which guarantees the same output on any implementation. The algorithm belongs to the ziggurat family developed in the 1970s by G. Marsaglia, M. Sibuya, and J. H. Ahrens [ZIGG]. It replaces the use of logarithmic function by clever bit manipulation, still producing the exponential variates on output.
ここでは、プロトコルで使用される指数関数的なランダム量が生成される方法について説明します。指数関数的なランダム変数を生成するためのかなりの数のアルゴリズムがありますが、それらのほとんどは、数学ライブラリの特定の実装に応じて、対数関数をプリミティブとして持つことに依存しています。[Knuth]のアルゴリズム3.4.1.sを使用します。これには、上記の問題があり、実装で同じ出力を保証します。このアルゴリズムは、1970年代にG. Marsaglia、M。Sibuya、およびJ. H. Ahrens [Zigg]によって開発されたジグラト科に属します。これは、対数関数の使用を巧妙なビット操作に置き換え、出力で指数バリエートを生成します。
For ease of exposition, the algorithm is first described with all arithmetic operations being interpreted in their natural sense. Later, exact details on data types, arithmetic, and generation of the uniform random variates used by the algorithm are given. It is an almost verbatim quotation from [KNUTH], p.133.
博覧会を容易にするために、アルゴリズムは最初に記述され、すべての算術演算が自然な意味で解釈されます。その後、データ型、算術、およびアルゴリズムで使用される均一なランダムバリエートの生成に関する正確な詳細が与えられます。これは、[Knuth]、p.133からのほとんど逐語的な引用です。
Algorithm S: Given a real positive number "mu", produce an exponential random variate with mean "mu".
アルゴリズムs：実際の正の数字「mu」が与えられた場合、平均「mu」との指数関数的なランダムバリエートが生成されます。
First, the constants
まず、定数
Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11
are computed in advance. The exact values which MUST be used by all implementations are given in the next section. This is necessary to ensure that exactly the same pseudo-random sequences are produced by all implementations.
事前に計算されます。すべての実装で使用する必要がある正確な値は、次のセクションに記載されています。これは、まったく同じ擬似ランダムシーケンスがすべての実装によって生成されるようにするために必要です。
S1. [Get U and shift.] Generate a 32-bit uniform random binary fraction
S1。[uを取得してシフトします。] 32ビットの均一なランダムバイナリ分率を生成します
U = (.b0 b1 b2 ... b31) [note the binary point]
Locate the first zero bit b_j and shift off the leading (j+1) bits,
setting U <- (.b_{j+1} ... b31)
Note: In the rare case that the zero has not been found, it is prescribed that the algorithm return (mu*32*ln2).
注：まれにゼロが見つからなかったというまれな場合、アルゴリズムが戻ることが規定されています（MU*32*LN2）。
S2. [Immediate acceptance?] If U < ln2, set X <- mu*(j*ln2 + U) and terminate the algorithm. (Note that Q[1] = ln2.) S3. [Minimize.] Find the least k >= 2 such that U < Q[k]. Generate k new uniform random binary fractions U1,...,Uk and set V <- min(U1,...,Uk).
S2。[即時の受け入れ？] u <ln2の場合、x <-mu*（j*ln2 u）を設定し、アルゴリズムを終了します。（q [1] = ln2。）S3。[最小化。] u <q [k]となるように、最小k> = 2を見つけます。K New均一なランダムバイナリ画分U1、...、英国とSET V <-min（U1、...、UK）を生成します。
S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2.
S4。[回答を提供します。] x <-mu*（j v）*ln2を設定します。
The high-level algorithm operates on real numbers, typically represented as floating point numbers. This specification prescribes that unsigned 64-bit integers be used instead.
高レベルのアルゴリズムは実数で動作し、通常は浮動小数点数として表されます。この仕様は、代わりに署名されていない64ビット整数を使用することを規定しています。
u_int64_t integers are interpreted as real numbers by placing the decimal point after the first 32 bits. In other words, conceptually, the interpretation is given by the following map:
U_INT64_T整数は、最初の32ビットの後に小数点を配置することにより、実数と解釈されます。言い換えれば、概念的には、解釈は次の地図で与えられます。
u_int64_t u;
u_int64_t u;
u |--> (double)u / (2**32)
The algorithm produces a sequence of such u_int64_t integers that, for any given value of SID, is guaranteed to be the same on any implementation.
アルゴリズムは、SIDの任意の値に対して、実装で同じであることが保証されるようなU_INT64_T整数のシーケンスを生成します。
We specify that the u_int64_t representations of the first 11 values of the Q array in the high-level algorithm MUST be as follows:
高レベルのアルゴリズムのQアレイの最初の11値のU_INT64_T表現は、次のようにする必要があることを指定します。
#1 0xB17217F8, #2 0xEEF193F7, #3 0xFD271862, #4 0xFF9D6DD0, #5 0xFFF4CFD0, #6 0xFFFEE819, #7 0xFFFFE7FF, #8 0xFFFFFE2B, #9 0xFFFFFFE0, #10 0xFFFFFFFE, #11 0xFFFFFFFF
＃1 0xb17217f8、＃2 0xeef193f7、＃3 0xfd271862、＃4 0xff9d6dd0、＃5 0xffff4cfd0、＃6 0xfffee819、＃7 0xfffffe7ff、＃8 0xfffffe2b、＃9 0xfffffe2
For example, Q[1] = ln2 is indeed approximated by 0xB17217F8/(2**32) = 0.693147180601954; for j > 11, Q[j] is 0xFFFFFFFF.
Small integer j in the high-level algorithm is represented as u_int64_t value j * (2**32).
高レベルのアルゴリズムの小整数Jは、U_INT64_T値J*（2 ** 32）として表されます。
Operation of addition is done as usual on u_int64_t numbers; however, the operation of multiplication in the high-level algorithm should be replaced by
(u, v) |---> (u * v) >> 32.
（u、v）| --->（u * v）>> 32。
Implementations MUST compute the product (u * v) exactly. For example, a fragment of unsigned 128-bit arithmetic can be implemented for this purpose (see the sample implementation in Appendix A).
実装は、製品（u * v）を正確に計算する必要があります。たとえば、この目的のために、署名されていない128ビット算術の断片を実装できます（付録Aのサンプル実装を参照）。
The procedure for obtaining a sequence of 32-bit random numbers (such as U in algorithm S) relies on using AES encryption in counter mode. To describe the exact working of the algorithm, we introduce two primitives from Rijndael. Their prototypes and specification are given below, and they are assumed to be provided by the supporting Rijndael implementation, such as [RIJN].
32ビットの乱数のシーケンスを取得する手順（アルゴリズムのUなど）は、カウンターモードでAES暗号化の使用に依存しています。アルゴリズムの正確な作業を説明するために、Rijndaelから2つのプリミティブを紹介します。それらのプロトタイプと仕様は以下に示されており、[rijn]などのサポートするrijndaelの実装によって提供されると想定されています。
+ A function that initializes a Rijndael key with bytes from seed (the SID will be used as the seed):
+ 種子からのバイトを使用してRijndaelキーを初期化する関数（SIDはシードとして使用されます）：
void KeyInit(unsigned char seed[16]);
void keyinit（unsigned charシード[16]）;
+ A function that encrypts the 16-octet block inblock with the specified key, returning a 16-octet encrypted block. Here, keyInstance is an opaque type used to represent Rijndael keys:
+ 指定されたキーで16オクテットのブロックインブロックを暗号化する関数で、16オクテットの暗号化されたブロックを返します。ここで、KeyInstanceはRijndaelキーを表すために使用される不透明なタイプです。
void BlockEncrypt(keyInstance key, unsigned char inblock[16]);
void blockencrypt（keyinstance key、unsigned char inblock [16]）;
Algorithm Unif: given a 16-octet quantity seed, produce a sequence of unsigned 32-bit pseudo-random uniformly distributed integers. In OWAMP, the SID (session ID) from Control protocol plays the role of seed.
アルゴリズムUnif：16オクテットの量の種子が与えられた場合、署名されていない32ビットの擬似ランダムの均一に分布した整数のシーケンスを生成します。OWAMPでは、コントロールプロトコルのSID（セッションID）がシードの役割を果たします。
U1. [Initialize Rijndael key] key <- KeyInit(seed) [Initialize an unsigned 16-octet (network byte order) counter] c <- 0
U1。[Rijndael Keyを初期化] Key <-KeyInit（Seed）[符号なしの16-OCTET（ネットワークバイトの順序）カウンターを初期化] C <-0
U2. [Need more random bytes?] Set i <- c mod 4. If (i == 0) set s
<- BlockEncrypt(key, c)
U3. [Increment the counter as unsigned 16-octet quantity] c <- c + 1
U3。[符号なしの16オクテット数量としてカウンターを増やす] c <-c 1
U4. [Do output] Output the i_th quartet of octets from s starting from high-order octets, converted to native byte order and represented as OWPNum64 value (as in 3.b).
U4。[出力をします]オクテットのi_thカルテットは、高次のオクテットから始まり、ネイティブバイトの順序に変換され、owpnum64値として表されます（3.bのように）出力します。
U5. [Loop] Go to step U2.
U5。[ループ]ステップU2に移動します。
The goal of authenticated mode is to let one passphrase-protect the service provided by a particular OWAMP-Control server. One can imagine a variety of circumstances where this could be useful. Authenticated mode is designed to prohibit theft of service.
認証モードの目標は、特定のOwamp-Controlサーバーが提供するサービスをPassPhraseで保護することです。これが役立つ可能性のあるさまざまな状況を想像できます。認証モードは、サービスの盗難を禁止するように設計されています。
An additional design objective of the authenticated mode was to make it impossible for an attacker who cannot read traffic between OWAMP-Test sender and receiver to tamper with test results in a fashion that affects the measurements, but not other traffic.
認証されたモードの追加の設計目的は、Owamp-Test送信者と受信機の間のトラフィックを読み取れない攻撃者が、測定に影響を与えるが、他のトラフィックに影響を与える方法でテスト結果を改ざんすることを不可能にすることでした。
The goal of encrypted mode is quite different: to make it hard for a party in the middle of the network to make results look "better" than they should be. This is especially true if one of client and server does not coincide with either sender or receiver.
暗号化されたモードの目標はまったく異なります。ネットワークの真ん中にいるパーティーが、結果が本来あるべきよりも「より良い」ように見えるようにすることを難しくすることです。これは、クライアントとサーバーのいずれかが送信者または受信機のいずれかと一致しない場合に特に当てはまります。
Encryption of OWAMP-Control using AES CBC mode with blocks of HMAC after each message aims to achieve two goals: (i) to provide secrecy of exchange, and (ii) to provide authentication of each message.
各メッセージが2つの目標を達成することを目的とした後、HMACのブロックを使用したAES CBCモードを使用したOWAMP-Controlの暗号化：（i）交換の秘密を提供すること、および（ii）各メッセージの認証を提供するために。
OWAMP-Test sessions directed at an unsuspecting party could be used for denial of service (DoS) attacks. In unauthenticated mode, servers SHOULD limit receivers to hosts they control or to the OWAMP-Control client.
疑いを持たない当事者に向けられたオウムテストセッションは、サービス拒否（DOS）攻撃に使用できます。認定されていないモードでは、サーバーは受信機が制御またはOwamp-Controlクライアントにホストに制限する必要があります。
Unless otherwise configured, the default behavior of servers MUST be to decline requests where the Receiver Address field is not equal to the address that the control connection was initiated from or an address of the server (or an address of a host it controls). Given the TCP handshake procedure and sequence numbers in the control connection, this ensures that the hosts that make such requests are actually those hosts themselves, or at least on the path towards them. If either this test or the handshake procedure were omitted, it would become possible for attackers anywhere in the Internet to request that large amounts of test packets be directed against victim nodes somewhere else.
特に構成されていない限り、サーバーのデフォルトの動作は、受信機のアドレスフィールドが制御接続が開始されたアドレスまたはサーバーのアドレス（またはコントロールするホストのアドレス）に等しくない場合、リクエストを拒否することでなければなりません。制御接続内のTCPハンドシェイクの手順とシーケンス番号を考えると、これにより、そのような要求を行うホストが実際にそれらのホスト自体、または少なくともそれらへのパス上にあることが保証されます。このテストまたはハンドシェイク手順のいずれかが省略された場合、インターネットのどこでも攻撃者が大量のテストパケットを他のどこかの被害者ノードに向けるよう要求することが可能になります。
In any case, OWAMP-Test packets with a given source address MUST only be sent from the node that has been assigned that address (i.e., address spoofing is not permitted).
いずれにせよ、特定のソースアドレスを持つOWAMPテストパケットは、そのアドレスが割り当てられたノードからのみ送信する必要があります（つまり、アドレスのスプーフィングは許可されていません）。
OWAMP-Test sessions could be used as covert channels of information. Environments that are worried about covert channels should take this into consideration.
OWAMP-TESTセッションは、秘密の情報チャネルとして使用できます。秘密のチャネルが心配な環境は、これを考慮に入れる必要があります。
Notice that AES, in counter mode, is used for pseudo-random number generation, so implementation of AES MUST be included even in a server that only supports unauthenticated mode.
カウンターモードでは、擬似ランダム数の生成にAEが使用されるため、AESの実装は、認知度のないモードのみをサポートするサーバーにも含める必要があることに注意してください。
An OWAMP server can consume resources of various kinds. The two most important kinds of resources are network capacity and memory (primary or secondary) for storing test results.
OWAMPサーバーは、さまざまな種類のリソースを消費できます。最も重要な2つの種類のリソースは、テスト結果を保存するためのネットワーク容量とメモリ（プライマリまたはセカンダリ）です。
Any implementation of OWAMP server MUST include technical mechanisms to limit the use of network capacity and memory. Mechanisms for managing the resources consumed by unauthenticated users and users authenticated with a KeyID and passphrase SHOULD be separate. The default configuration of an implementation MUST enable these mechanisms and set the resource use limits to conservatively low values.
OWAMPサーバーの実装には、ネットワーク容量とメモリの使用を制限するための技術的メカニズムを含める必要があります。KeyIDとパスフレーズで認証された認証されていないユーザーによって消費されたリソースを管理するためのメカニズムは、別々にする必要があります。実装のデフォルトの構成は、これらのメカニズムを有効にし、リソース使用制限を控えめに低い値に設定する必要があります。
One way to design the resource limitation mechanisms is as follows: assign each session to a user class. User classes are partially ordered with "includes" relation, with one class ("all users") that is always present and that includes any other class. The assignment of a session to a user class can be based on the presence of authentication of the session, the KeyID, IP address range, time of day, and, perhaps, other factors. Each user class would have a limit for usage of network capacity (specified in units of bit/second) and memory for storing test results (specified in units of octets). Along with the limits for resource use, current use would be tracked by the server. When a session is requested by a user in a specific user class, the resources needed for this session are computed: the average network capacity use (based on the sending schedule) and the maximum memory use (based on the number of packets and number of octets each packet would need to be stored internally -- note that outgoing sessions would not require any memory use). These resource use numbers are added to the current resource use numbers for the given user class; if such addition would take the resource use outside of the limits for the given user class, the session is rejected. When resources are reclaimed, corresponding measures are subtracted from the current use. Network capacity is reclaimed as soon as the session ends. Memory is reclaimed when the data is deleted. For unauthenticated sessions, memory consumed by an OWAMP-Test session SHOULD be reclaimed after the OWAMP-Control connection that initiated the session is closed (gracefully or otherwise). For authenticated sessions, the administrator who configures the service should be able to decide the exact policy, but useful policy mechanisms that MAY be implemented are the ability to automatically reclaim memory when the data is retrieved and the ability to reclaim memory after a certain configurable (based on user class) period of time passes after the OWAMP-Test session terminates.
リソース制限メカニズムを設計する1つの方法は、次のとおりです。各セッションをユーザークラスに割り当てます。ユーザークラスは、「含まれる」関係で部分的に注文され、常に存在し、他のクラスを含む1つのクラス（「すべてのユーザー」）があります。セッションのユーザークラスへの割り当ては、セッションの認証の存在、KeyID、IPアドレス範囲、時刻、およびおそらく他の要因に基づいています。各ユーザークラスには、ネットワーク容量（ビット/秒単位で指定）の使用制限と、テスト結果を保存するためのメモリ（オクテットの単位で指定）があります。リソース使用の制限に加えて、現在の使用はサーバーによって追跡されます。特定のユーザークラスのユーザーがセッションを要求すると、このセッションに必要なリソースが計算されます：平均ネットワーク容量使用（送信スケジュールに基づく）と最大メモリ使用（パケットの数と数に基づいて）各パケットは内部に保存する必要があります。発信セッションではメモリの使用は必要ないことに注意してください）。これらのリソース使用番号は、指定されたユーザークラスの現在のリソース使用番号に追加されます。そのような追加が、指定されたユーザークラスの制限以外でリソースを使用する場合、セッションは拒否されます。リソースが再生されると、対応する測定値が現在の使用から差し引かれます。セッションが終了するとすぐに、ネットワーク容量が再生されます。データが削除されると、メモリが回収されます。無慈悲なセッションでは、オウムテストセッションによって消費されるメモリは、セッションを開始したOWAMPコントロール接続が閉じられた後に（優雅にまたはその他）再生する必要があります。認証されたセッションの場合、サービスを構成する管理者は正確なポリシーを決定できるはずですが、実装される可能性のある有用なポリシーメカニズムは、データが取得されたときにメモリを自動的に回収する能力と、特定の構成可能な後にメモリを取り戻す機能です（ユーザークラスに基づいて）オウムテストセッションが終了した後の期間が経過します。
At an early stage in designing the protocol, we considered using Transport Layer Security (TLS) [RFC2246, RFC3546] and IPsec [RFC2401] as cryptographic security mechanisms for OWAMP; later, we also considered DTLS. The disadvantages of those are as follows (not an exhaustive list):
プロトコルの設計の初期段階では、OWAMPの暗号化セキュリティメカニズムとして、トランスポートレイヤーセキュリティ（TLS）[RFC2246、RFC3546]およびIPSEC [RFC2401]を使用することを検討しました。後で、DTLも検討しました。それらの欠点は次のとおりです（網羅的なリストではありません）：
Regarding TLS:
TLSについて：
+ TLS could be used to secure TCP-based OWAMP-Control, but it would be difficult to use it to secure UDP-based OWAMP-Test: OWAMP-Test packets, if lost, are not resent, so packets have to be (optionally) encrypted and authenticated while retaining individual usability. Stream-based TLS cannot be easily used for this.
+ TLSはTCPベースのOWAMPコントロールを保護するために使用できますが、UDPベースのOWAMPテストを保護するために使用することは困難です。OWAMP-TESTパケットは、失われていない場合、パケットを（オプションで）必要とする必要があります個々の使いやすさを維持しながら、暗号化および認証されています。これには、ストリームベースのTLSを簡単に使用できません。
+ Dealing with streams, TLS does not authenticate individual messages (even in OWAMP-Control). The easiest way out would be to add some known-format padding to each message and to verify that the format of the padding is intact before using the message. The solution would thus lose some of its appeal ("just use TLS"). It would also be much more difficult to evaluate the security of this scheme with the various modes and options of TLS; it would almost certainly not be secure with all. The capacity of an attacker to replace parts of messages (namely, the end) with random garbage could have serious security implications and would need to be analyzed carefully. Suppose, for example, that a parameter that is used in some form to control the rate were replaced by random garbage; chances are that the result (an unsigned integer) would be quite large.
+ TLSは、ストリームを扱っても、個々のメッセージを認証しません（Owamp-Controlでも）。最も簡単な方法は、各メッセージにいくつかの既知の形式のパディングを追加し、メッセージを使用する前にパディングの形式が無傷であることを確認することです。したがって、ソリューションはその魅力の一部を失います（「TLSを使用するだけ」）。また、TLSのさまざまなモードとオプションを使用して、このスキームのセキュリティを評価することもはるかに困難です。ほぼ間違いなくすべての人に安全ではありません。攻撃者がメッセージの一部（すなわち、終わり）をランダムなゴミに置き換える能力は、深刻なセキュリティの意味を持つ可能性があり、慎重に分析する必要があります。たとえば、レートを制御するために何らかの形で使用されるパラメーターがランダムなゴミに置き換えられたとします。結果（署名されていない整数）が非常に大きくなる可能性があります。
+ Dependent on the mode of use, one can end up with a requirement for certificates for all users and a PKI. Even if one is to accept that PKI is desirable, there just isn't a usable one today.
+ 使用モードに応じて、すべてのユーザーとPKIの証明書の要件が得られる可能性があります。PKIが望ましいことを受け入れることであっても、今日は使用可能なものはありません。
+ TLS requires a fairly large implementation. OpenSSL, for example, is larger than our implementation of OWAMP as a whole. This can matter for embedded implementations.
+ TLSには、かなり大きな実装が必要です。たとえば、OpenSSLは、OWAMP全体の実装よりも大きいです。これは、埋め込まれた実装で重要です。
Regarding DTLS:
DTLについて：
+ Duplication and, similarly, reordering are network phenomena that OWAMP needs to be able to measure; yet anti-replay measures and reordering protection of DTLS would prevent the duplicated and reordered packets from reaching the relevant part of the OWAMP code. One could, of course, modify DTLS so that these protections are weakened or even specify examining the messages in a carefully crafted sequence somewhere in between DTLS checks; but then, of course, the advantage of using an existing protocol would not be realized.
+ 重複と同様に、並べ替えは、OWAMPが測定できる必要があるネットワーク現象です。しかし、DTLのレプレイ防止対策と並べ替えの保護は、重複したパケットと並べ替えられたパケットがOWAMPコードの関連部分に到達するのを防ぎます。もちろん、これらの保護が弱体化するようにDTLを変更するか、DTLSチェックの間のどこかで慎重に作成されたシーケンスでメッセージを調べることを指定することさえできます。しかし、もちろん、既存のプロトコルを使用するという利点は実現されません。
+ In authenticated mode, the timestamp is in the clear and is not protected cryptographically in any way, while the rest of the message has the same protection as in encrypted mode. This mode allows one to trade off cryptographic protection against accuracy of timestamps. For example, the APAN hardware implementation of OWAMP [APAN] is capable of supporting authenticated mode. The accuracy of these measurements is in the sub-microsecond range. The errors in OWAMP measurements of Abilene [Abilene] (done using a software implementation, in its encrypted mode) exceed 10us. Users in different environments have different concerns, and some might very well care about every last microsecond of accuracy. At the same time, users in these same environments might care about access control to the service. Authenticated mode permits them to control access to the server yet to use unprotected timestamps, perhaps generated by a hardware device.
+ 認証されたモードでは、タイムスタンプはクリアにあり、いかなる方法でも暗号化されていませんが、残りのメッセージは暗号化モードと同じ保護を持っています。このモードにより、タイムスタンプの精度から暗号化保護をオフにすることができます。たとえば、OWAMP [APAN]のAPANハードウェア実装は、認証モードをサポートできます。これらの測定の精度は、サブマイクロンド秒範囲です。Abilene [Abilene]のOWAMP測定のエラー（暗号化されたモードでソフトウェア実装を使用して実行）は10Uを超えています。さまざまな環境のユーザーには懸念が異なり、一部のユーザーはすべての最後のマイクロ秒の精度を非常によく気にかけているかもしれません。同時に、これらの同じ環境のユーザーは、サービスへのアクセス制御に関心があるかもしれません。認証されたモードでは、おそらくハードウェアデバイスによって生成された保護されていないタイムスタンプを使用していないサーバーへのアクセスを制御できます。
Regarding IPsec:
+ What we now call authenticated mode would not be possible (in IPsec you can't authenticate part of a packet).
+ 現在、認証モードと呼ばれるものは不可能です（IPSECでは、パケットの一部を認証できません）。
+ The deployment paths of IPsec and OWAMP could be separate if OWAMP does not depend on IPsec. After nine years of IPsec, only 0.05% of traffic on an advanced backbone network, such as Abilene, uses IPsec (for comparison purposes with encryption above layer 4, SSH use is at 2-4% and HTTPS use is at 0.2-0.6%). It is desirable to be able to deploy OWAMP on as large a number of different platforms as possible.
+ OWAMPがIPSECに依存しない場合、IPSECとOWAMPの展開パスは分離できます。IPSECの9年後、Abileneなどの高度なバックボーンネットワーク上のトラフィックの0.05％のみがIPSECを使用します（レイヤー4を超える暗号化と比較して、SSHの使用は2〜4％、HTTPSの使用は0.2-0.6％です。）。できるだけ多くの異なるプラットフォームをOWAMPに展開できることが望ましいです。
+ The deployment problems of a protocol dependent on IPsec would be especially acute in the case of lightweight embedded devices. Ethernet switches, DSL "modems", and other such devices mostly do not support IPsec.
+ IPSECに依存するプロトコルの展開の問題は、軽量埋め込みデバイスの場合に特に急性になります。イーサネットスイッチ、DSL「モデム」、およびその他のそのようなデバイスは、ほとんどIPSECをサポートしていません。
+ The API for manipulating IPsec from an application is currently poorly understood. Writing a program that needs to encrypt some packets, to authenticate some packets, and to leave some open -- for the same destination -- would become more of an exercise in IPsec than in IP measurement.
+
For the enumerated reasons, we decided to use a simple cryptographic protocol (based on a block cipher in CBC mode) that is different from TLS and IPsec.
列挙された理由から、TLSやIPSECとは異なる単純な暗号化プロトコル（CBCモードのブロック暗号に基づく）を使用することにしました。
It might become necessary in the future to replace AES, or the way it is used in OWAMP, with a new cryptographic primitive, or to make other security-related changes to the protocol. OWAMP provides a well-defined point of extensibility: the Modes word in the server greeting and the Mode response in the Set-Up-Response message. For example, if a simple replacement of AES with a different block cipher with a 128-bit block is needed, this could be accomplished as follows: take two bits from the reserved (MBZ) part of the Modes word of the server greeting; use one of these bits to indicate encrypted mode with the new cipher and another one to indicate authenticated mode with the new cipher. (Bit consumption could, in fact, be reduced from two to one, if the client is allowed to return a mode selection with more than a single bit set: one could designate a single bit to mean that the new cipher is supported (in the case of the server) or selected (in the case of the client) and continue to use already allocated bits for authenticated and encrypted modes; this optimization is unimportant conceptually, but it could be useful in practice to make the best use of bits.) Then, if the new cipher is negotiated, all subsequent operations simply use it instead of AES. Note that the normal transition sequence would be used in such a case: implementations would probably first start supporting and preferring the new cipher, and then drop support for the old cipher (presumably no longer considered secure).
If the need arises to make more extensive changes (perhaps to replace AES with a 256-bit-block cipher), this would be more difficult and would require changing the layout of the messages. However, the change can still be conducted within the framework of OWAMP extensibility using the Modes/Mode words. The semantics of the new bits (or single bit, if the optimization described above is used) would include the change to message layout as well as the change in the cryptographic primitive.
Each of the bits in the Modes word can be used for an independent extension. The extensions signaled by various bits are orthogonal; for example, one bit might be allocated to change from AES-128 to some other cipher, another bit might be allocated to add a protocol feature (such as, e.g., support for measuring over multicast), yet another might be allocated to change a key derivation function, etc. The progression of versions is not a linear order, but rather a partial order. An implementation can implement any subset of these features (of course, features can be made mandatory to implement, e.g., new more secure ciphers if they are needed).
モードワード内の各ビットは、独立した拡張機能に使用できます。さまざまなビットで通知される拡張機能は直交です。たとえば、AES-128から他の暗号に変更するために1つのビットが割り当てられる可能性があります。もう1つは、プロトコル機能（たとえば、マルチキャストを測定するためのサポートなど）を追加するために割り当てられる可能性がありますが、別のビットはAを変更するために割り当てられる場合があります。キー派生関数など。バージョンの進行は線形順序ではなく、部分的な順序です。実装は、これらの機能の任意のサブセットを実装できます（もちろん、機能を実装するために機能を義務付けることができます。たとえば、必要に応じて新しい安全な暗号など）。
Should a cipher with a different key size (say, a 256-bit key) become needed, a new key derivation function for OWAMP-Test keys would also be needed. The semantics of change in the cipher SHOULD then in the future be tied to the semantics of change in the key derivation function (KDF). One KDF that might be considered for the purpose might be a pseudo-random function (PRF) with appropriately sized output, such as 256 bits (perhaps HMAC-SHA256, if it is then still considered a secure PRF), which could then be used to derive the OWAMP-Test session keys from the OWAMP-Control session key by using the OWAMP-Control session key as the HMAC key and the SID as HMAC message.
異なるキーサイズ（たとえば、256ビットキー）が必要な暗号が必要になった場合、Owampテストキーの新しいキー派生関数も必要です。その場合、暗号の変化のセマンティクスは、将来、キー導出関数（KDF）の変化のセマンティクスに結び付けられるべきです。目的のために考慮される可能性のあるKDFの1つは、256ビット（おそらくHMAC-Sha256、場合でも安全なPRFと見なされる場合）などの適切なサイズの出力を備えた擬似ランダム関数（PRF）である可能性があります。HMACキーとしてOWAMP-Controlセッションキーを、SIDをHMACメッセージとして使用して、Owamp-ControlセッションキーからOwamp-Testセッションキーを導き出すため。
Note that the replacement scheme outlined above is trivially susceptible to downgrade attacks: a malicious party in the middle can flip modes bits as the mode is negotiated so that the oldest and weakest mode supported by the two parties is used. If this is deemed problematic at the time of cryptographic primitive replacement, the scheme might be augmented with a measure to prevent such an attack (by perhaps exchanging the modes again once a secure communications channel is established, comparing the two sets of mode words, and dropping the connection should they not match).
上記で概説した交換スキームは、攻撃を格下げしやすいものであることに注意してください。中央の悪意のあるパーティーは、モードがネゴシエートされると、2つのパーティがサポートする最も古くて弱いモードが使用されるように、モードをフリップすることができます。これが暗号化のプリミティブ置換時に問題と見なされている場合、スキームはそのような攻撃を防ぐための尺度で増強される可能性があります（おそらく、安全な通信チャネルが確立されたら、モードの2つのセットを比較し、そして2つのモードを比較すると、モードを再度交換することにより、一致しない場合は接続を削除します）。
OWAMP-Control uses long-term keys with manual management. These keys are used to automatically negotiate session keys for each OWAMP-Control session running in authenticated or encrypted mode. The number of these keys managed by a server scales linearly with (and, in fact, is equal to) the number of administratively different users (perhaps particular humans, roles, or robots representing sites) that need to connect to this server. Similarly, the number of different manual keys managed by each client is the number of different servers that the client needs to connect to. This use of manual long-term keys is compliant with [BCP107].
Owamp-Controlは、手動管理を備えた長期キーを使用します。これらのキーは、認証されたモードまたは暗号化モードで実行されている各owamp-controlセッションのセッションキーを自動的にネゴシエートするために使用されます。サーバーによって管理されるこれらのキーの数は、このサーバーに接続する必要がある管理上異なるユーザー（おそらく特定の人間、役割、またはサイトを表すロボット）の数とともに直線的にスケーリングします（実際には等しい）。同様に、各クライアントが管理する異なる手動キーの数は、クライアントが接続する必要がある異なるサーバーの数です。この手動の長期キーの使用は、[BCP107]に準拠しています。
A natural idea is to use the current time as salt when deriving session keys. Unfortunately, this appears to be too limiting.
自然なアイデアは、セッションキーを導き出すときに現在の時間を塩として使用することです。残念ながら、これは制限が大きすぎるようです。
Although OWAMP is often run on hosts with well-synchronized clocks, it is also possible to run it on hosts with clocks completely untrained. The delays obtained thus are, of course, not directly usable; however, some metrics, such as unidirectional loss, reordering, measures of congestion such as the median delay minus minimum, and many others are usable directly and immediately (and improve upon the information that would have been provided by a round-trip measurement). Further, even delay information can be useful with appropriate post-processing. Indeed, one can even argue that running the clocks free and post-processing the results of a mesh of measurements will result in better accuracy, as more information is available a posteriori and correlation of data from different hosts is possible in post-processing, but not with online clock training.
OWAMPは、よく同期された時計を持つホストで実行されることがよくありますが、クロックが完全に訓練されていないホストで実行することもできます。したがって、得られた遅延は、もちろん、直接使用できません。ただし、一方向性の損失、並べ替え、遅延遅延マイナス最小などの輻輳の測定などの一部のメトリックは、直接かつ直接使用可能です（そして、往復測定によって提供される情報を改善します）。さらに、遅延情報でさえ、適切な後処理で役立ちます。確かに、クロックを自由に実行し、測定メッシュの結果を再処理することはより良い精度をもたらすと主張することさえできます。オンラインクロックトレーニングではありません。
Given this, time is not used as salt in key derivation.
これを考えると、時間はキー導出の塩として使用されません。
OWAMP relies on AES-CBC for confidentiality and on HMAC-SHA1 truncated to 128 bits for message authentication. Random IV choice is important for prevention of a codebook attack on the first block (it should also be noted that, with its 128-bit block size, AES is more resistant to codebook attacks than are ciphers with shorter blocks; we use random IV anyway).
OWAMPは、機密性のためにAES-CBCと、メッセージ認証のために128ビットに切り捨てられたHMAC-SHA1に依存しています。ランダムIVの選択は、最初のブロックに対するコードブック攻撃の防止に重要です（128ビットブロックサイズでは、AESは、より短いブロックを持つ暗号よりもコードブック攻撃に対して耐性があることにも注意してください。とにかくランダムIVを使用します。）。
HMAC MUST verify. It is crucial to check for this before using the message; otherwise, existential forgery becomes possible. The complete message for which HMAC verification fails MUST be discarded (both for short messages consisting of a few blocks and potentially for long messages, such as a response to the Fetch-Session command). If such a message is part of OWAMP-Control, the connection MUST be dropped.
HMACは確認する必要があります。メッセージを使用する前に、これを確認することが重要です。そうでなければ、実存的な偽造が可能になります。HMAC検証に失敗する完全なメッセージは破棄する必要があります（数ブロックで構成される短いメッセージの場合、フェッチセッションコマンドへの応答などの長いメッセージの場合は両方）。そのようなメッセージがOwamp-Controlの一部である場合、接続をドロップする必要があります。
Since OWAMP messages can have different numbers of blocks, the existential forgery attack described in example 9.62 of [MENEZES] becomes a concern. To prevent it (and to simplify implementation), the length of any message becomes known after decrypting its first block.
OWAMPメッセージには異なる数のブロックがある可能性があるため、[メネゼス]の例9.62に記載されている実存的な偽造攻撃が懸念事項になります。それを防ぐため（および実装を簡素化するために）、メッセージの長さは最初のブロックを復号化した後に知られます。
A special case is the first (fixed-length) message sent by the client. There, the token is a concatenation of the 128-bit challenge (transmitted by the server in the clear), a 128-bit AES Session-key (generated randomly by the client, encrypted with AES-CBC with IV=0), and a 256-bit HMAC-SHA1 Session-key used for authentication. Since IV=0, the challenge (a single cipher block) is simply encrypted with the secret key. Therefore, we rely on resistance of AES to chosen plaintext attacks (as the challenge could be substituted by an attacker). It should be noted that the number of blocks of chosen plaintext an attacker can have encrypted with the secret key is limited by the number of sessions the client wants to initiate. An attacker who knows the encryption of a server's challenge can produce an existential forgery of the session key and thus disrupt the session; however, any attacker can disrupt a session by corrupting the protocol messages in an arbitrary fashion. Therefore, no new threat is created here; nevertheless, we require that the server never issues the same challenge twice. (If challenges are generated randomly, a repetition would occur, on average, after 2^64 sessions; we deem this satisfactory as this is enough even for an implausibly busy server that participates in 1,000,000 sessions per second to go without repetitions for more than 500 centuries.) With respect to the second part of the token, an attacker can produce an existential forgery of the session key by modifying the second half of the client's token while leaving the first part intact. This forgery, however, would be immediately discovered by the client when the HMAC on the server's next message (acceptance or rejection of the connection) does not verify.
特別なケースは、クライアントから送信された最初の（固定長）メッセージです。そこでは、トークンは、128ビットチャレンジ（クリアでサーバーによって送信される）、128ビットAESセッションキー（クライアントによってランダムに生成され、IV = 0のAES-CBCで暗号化された）の連結です。認証に使用される256ビットHMAC-SHA1セッションキー。IV = 0なので、課題（単一の暗号ブロック）は、シークレットキーで単純に暗号化されています。したがって、選択したプレーンテキスト攻撃にAEの抵抗に依存しています（課題は攻撃者によって置き換える可能性があるため）。攻撃者がシークレットキーで暗号化することができる選択されたプレーンテキストのブロックの数は、クライアントが開始したいセッションの数によって制限されることに注意する必要があります。サーバーの課題の暗号化を知っている攻撃者は、セッションキーの実存的な偽造を生み出し、セッションを混乱させる可能性があります。ただし、攻撃者は、プロトコルメッセージを任意の方法で破損することにより、セッションを混乱させる可能性があります。したがって、ここに新しい脅威は作成されません。それにもかかわらず、サーバーが同じチャレンジを2回発行しないことを要求します。（課題がランダムに生成された場合、2^64セッションの後、平均して繰り返しが発生します。これは、500以上の繰り返しなしに1秒あたりの1,000,000セッションに参加することでも、これは十分であると考えています。何世紀にもわたって。）トークンの第2部に関して、攻撃者は、最初の部分を無傷のままにしながら、クライアントのトークンの後半を変更することにより、セッションキーの実存的な偽造を生成できます。ただし、この偽造は、サーバーの次のメッセージ（接続の受け入れまたは拒否）のHMACが確認されない場合、すぐにクライアントによって発見されます。
We would like to thank Guy Almes, Mark Allman, Jari Arkko, Hamid Asgari, Steven Van den Berghe, Eric Boyd, Robert Cole, Joan Cucchiara, Stephen Donnelly, Susan Evett, Sam Hartman, Kaynam Hedayat, Petri Helenius, Scott Hollenbeck, Russ Housley, Kitamura Yasuichi, Daniel H. T. R. Lawson, Will E. Leland, Bruce A. Mah, Allison Mankin, Al Morton, Attila Pasztor, Randy Presuhn, Matthew Roughan, Andy Scherrer, Henk Uijterwaal, and Sam Weiler for their comments, suggestions, reviews, helpful discussion and proof-reading.
ガイ・アルームス、マーク・オールマン、ジャリ・アークコ、ハミド・アスガリ、スティーブン・ヴァン・デン・ベルゲ、エリック・ボイド、ロバート・コール、ジョーン・クッキアラ、スティーブン・ドネリー、スーザン・イヴェット、サム・ハートマン、カイナム・ヘダヤット、ペトリ・ヘレニウス、スコット・ホレンベック、Housley、Kitamura Yasuichi、Daniel H. T. R. Lawson、Will E. Leland、Bruce A. Mah、Allison Mankin、Al Morton、Attila Pasztor、Randy Presuhn、Matthew Roughan、Andy Scherrer、Henk Uijterwaal、およびSam Weilerのコメント、提案、レビュー、役立つ議論と校正。
IANA has allocated a well-known TCP port number (861) for the OWAMP-Control part of the OWAMP protocol.
IANAは、OWAMPプロトコルのOwamp-Control部分によく知られているTCPポート番号（861）を割り当てました。
The protocol does not carry any information in a natural language, with the possible exception of the KeyID in OWAMP-Control, which is encoded in UTF-8.
このプロトコルは、UTF-8にエンコードされたOwamp-ControlのKeyIDの可能性を除き、自然言語で情報を運ぶことはありません。
[AES] Advanced Encryption Standard (AES), http://csrc.nist.gov/encryption/aes/
[AES] Advanced Encryption Standard（AES）、http://csrc.nist.gov/encryption/aes/
[BCP107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[BCP107] Bellovin、S。およびR. Housley、「暗号化キー管理のためのガイドライン」、BCP 107、RFC 4107、2005年6月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「IPパフォーマンスメトリックのフレームワーク」、RFC 2330、1998年5月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの一方向遅延メトリック」、RFC 2679、1999年9月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの一元配置パケット損失メトリック」、RFC 2680、1999年9月。
[RFC2836] Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 2836, May 2000.
[RFC2836] Brim、S.、Carpenter、B。、およびF. Le Faucheur、「ホップの動作識別コード」、RFC 2836、2000年5月。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[RFC2898] Kaliski、B。、「PKCS＃5：パスワードベースの暗号仕様バージョン2.0」、RFC 2898、2000年9月。
[APAN] Z. Shu and K. Kobayashi, "HOTS: An OWAMP-Compliant Hardware Packet Timestamper", In Proceedings of PAM 2005, http://www.springerlink.com/index/ W4GBD39YWC11GQTN.pdf
[Apan] Z. Shu and K. kobayashi、「Hots：An Owamp-Compliant Hardware Packet Timestamper」、PAM 2005の議事録、http：//www.springerlink.com/index/ w4gbd39ywc11gqtn.pdf
[BRIX] Brix Networks, http://www.brixnet.com/
[Brix] Brix Networks、http://www.brixnet.com/
[ZIGG] J. H. Ahrens, U. Dieter, "Computer methods for sampling from the exponential and normal distributions", Communications of ACM, volume 15, issue 10, 873-882, 1972. http://doi.acm.org/10.1145/355604.361593
[Zigg] J. H. Ahrens、U。Dieter、「指数分布と通常の分布からのサンプリングのためのコンピューター方法」、ACMの通信、第15巻、第10号、873-882、1972。http：//doi.acm.org/10.11455/355604.361593
[MENEZES] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, Handbook of Applied Cryptography, CRC Press, revised reprint with updates, 1997.
[Menezes] A. J. Menezes、P。C。Van Oorschot、およびS. A. Vanstone、Applied Cryptographyのハンドブック、CRC Press、Revided Reprint with Updates、1997。
[KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd edition, 1998.
[Knuth] D. Knuth、The Art of Computerプログラミング、Vol.2、3rd Edition、1998。
[Abilene] One-way Latency Measurement (OWAMP), http://e2epi.internet2.edu/owamp/
[Abilene]一元配置潜伏測定（owamp）、http：//e2epi.internet2.edu/owamp/
[RIJN] Reference ANSI C Implementation of Rijndael, http://www.esat.kuleuven.ac.be/~rijmen/ rijndael/rijndaelref.zip
[rijn] Rijndael、http：//www.esat.kuleuven.ac.be/~rijmen/ rijndael/rijndaelref.zipのリファレンスAnsi c実装
[RIPE] RIPE NCC Test-Traffic Measurements home, http://www.ripe.net/test-traffic/.
[RIPE] RIPE NCCテスト - トラフィック測定ホーム、http：//www.ripe.net/test-traffic/。
[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/.
[測量士]測量士のホームページ、http：//www.advanced.org/surveyor/。
[SURVEYOR-INET] S. Kalidindi and M. Zekauskas, "Surveyor: An Infrastructure for Network Performance Measurements", Proceedings of INET'99, June 1999. http://www.isoc.org/inet99/proceedings/4h/4h_2.htm
[Surveyor-Inet] S. KalidindiおよびM. Zekauskas、「測量士：ネットワークパフォーマンス測定のためのインフラストラクチャ」、1999年6月のINET'99の議事録。.htm
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装、分析」、RFC 1305、1992年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
[RFC3546] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 3546、2003年6月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
Appendix A: Sample C Code for Exponential Deviates
付録A：指数逸脱のサンプルCコード
The values in array Q[] are the exact values that MUST be used by all implementations (see Sections 5.1 and 5.2). This appendix only serves for illustrative purposes.
配列q []の値は、すべての実装で使用する必要がある正確な値です（セクション5.1および5.2を参照）。この付録は、説明のためにのみ機能します。
/*
** Example usage: generate a stream of exponential (mean 1)
** random quantities (ignoring error checking during initialization).
** If a variate with some mean mu other than 1 is desired, the output
** of this algorithm can be multiplied by mu according to the rules
** of arithmetic we described.
** Assume that a 16-octet 'seed' has been initialized
** (as the shared secret in OWAMP, for example)
** unsigned char seed[16];
** OWPrand_context next;
** (initialize state)
** OWPrand_context_init(&next, seed);
** (generate a sequence of exponential variates)
** while (1) {
** u_int64_t num = OWPexp_rand64(&next);
<do something with num here>
...
** }
*/
#include <stdlib.h>
typedef u_int64_t u_int64_t;
typedef u_int64_t u_int64_t;
/* (K - 1) is the first k such that Q[k] > 1 - 1/(2^32). */
#define K 12
#define BIT31 0x80000000UL /* See if first bit in the lower
32 bits is zero. */
#define MASK32(n) ((n) & 0xFFFFFFFFUL)
#define EXP2POW32 0x100000000ULL
#define exp2pow32 0x100000000ull
typedef struct OWPrand_context {
unsigned char counter[16];/* Counter (network byte order).*/
keyInstance key; /* Key to encrypt the counter.*/
unsigned char out[16]; /* The encrypted block.*/
} OWPrand_context;
} owprand_context;
/*
** The array has been computed according to the formula:
**
** Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!)
**
** as described in algorithm S. (The values below have been
** multiplied by 2^32 and rounded to the nearest integer.)
** These exact values MUST be used so that different implementation
** produce the same sequences.
*/
static u_int64_t Q[K] = {
0, /* Placeholder - so array indices start from 1. */
0xB17217F8,
0xEEF193F7,
0xFD271862,
0xFF9D6DD0,
0xFFF4CFD0,
0xFFFEE819,
0xFFFFE7FF,
0xFFFFFE2B,
0xFFFFFFE0,
0xFFFFFFFE,
0xFFFFFFFF
};
/* this element represents ln2 */
#define LN2 Q[1]
/*
** Convert an unsigned 32-bit integer into a u_int64_t number.
*/
u_int64_t
OWPulong2num64(u_int32_t a)
{
return ((u_int64_t)1 << 32) * a;
}
/*
** Arithmetic functions on u_int64_t numbers.
*/
/*
** Addition.
*/
u_int64_t
OWPnum64_add(u_int64_t x, u_int64_t y)
{
return x + y;
}
/*
** Multiplication. Allows overflow. Straightforward implementation
** of Algorithm 4.3.1.M (p.268) from [KNUTH].
*/
u_int64_t
OWPnum64_mul(u_int64_t x, u_int64_t y)
{
unsigned long w[4];
u_int64_t xdec[2];
u_int64_t ydec[2];
int i, j; u_int64_t k, t, ret;
int i、j;u_int64_t k、t、ret;
xdec[0] = MASK32(x);
xdec[1] = MASK32(x>>32);
ydec[0] = MASK32(y);
ydec[1] = MASK32(y>>32);
for (j = 0; j < 4; j++)
w[j] = 0;
for (j = 0; j < 2; j++) {
k = 0;
for (i = 0; ; ) {
t = k + (xdec[i]*ydec[j]) + w[i + j];
w[i + j] = t%EXP2POW32;
k = t/EXP2POW32;
if (++i < 2)
continue;
else {
w[j + 2] = k;
break;
}
}
}
ret = w[2];
ret <<= 32;
return w[1] + ret;
}
/*
** Seed the random number generator using a 16-byte quantity 'seed'
** (== the session ID in OWAMP). This function implements step U1
** of algorithm Unif.
*/
void OWPrand_context_init(OWPrand_context *next, unsigned char *seed) { int i;
void owprand_context_init（owprand_context *next、unsigned char *seed）{int i;
/* Initialize the key */
rijndaelKeyInit(next->key, seed);
/* Initialize the counter with zeros */
memset(next->out, 0, 16);
for (i = 0; i < 16; i++)
next->counter[i] = 0UL;
}
/*
** Random number generating functions.
*/
/*
** Generate and return a 32-bit uniform random value (saved in the
**less significant half of the u_int64_t). This function implements
**steps U2-U4 of the algorithm Unif.
*/
u_int64_t
OWPunif_rand64(OWPrand_context *next)
{
int j;
u_int8_t *buf;
u_int64_t ret = 0;
/* step U2 */
u_int8_t i = next->counter[15] & (u_int8_t)3;
if (!i)
rijndaelEncrypt(next->key, next->counter, next->out);
/* Step U3. Increment next.counter as a 16-octet single
quantity in network byte order for AES counter mode. */
for (j = 15; j >= 0; j--)
if (++next->counter[j])
break;
/* Step U4. Do output. The last 4 bytes of ret now contain
the random integer in network byte order */
buf = &next->out[4*i];
for (j=0; j<4; j++) {
ret <<= 8;
ret += *buf++;
}
return ret;
}
/*
** Generate an exponential deviate with mean 1.
*/
u_int64_t
OWPexp_rand64(OWPrand_context *next)
{
unsigned long i, k;
u_int32_t j = 0;
u_int64_t U, V, J, tmp;
/* Step S1. Get U and shift */
U = OWPunif_rand64(next);
while ((U & BIT31) && (j < 32)) { /* Shift until first 0. */
U <<= 1;
j++;
}
/* Remove the 0 itself. */
U <<= 1;
U = MASK32(U); /* Keep only the fractional part. */
J = OWPulong2num64(j);
/* Step S2. Immediate acceptance? */
if (U < LN2) /* return (j*ln2 + U) */
return OWPnum64_add(OWPnum64_mul(J, LN2), U);
/* Step S3. Minimize. */
for (k = 2; k < K; k++)
if (U < Q[k])
break;
V = OWPunif_rand64(next);
for (i = 2; i <= k; i++) {
tmp = OWPunif_rand64(next);
if (tmp < V)
V = tmp;
}
/* Step S4. Return (j+V)*ln2 */
return OWPnum64_mul(OWPnum64_add(J, V), LN2);
}
Appendix B: Test Vectors for Exponential Deviates
It is important that the test schedules generated by different implementations from identical inputs be identical. The non-trivial part is the generation of pseudo-random exponentially distributed deviates. To aid implementors in verifying interoperability, several test vectors are provided. For each of the four given 128-bit values of SID represented as hexadecimal numbers, 1,000,000 exponentially distributed 64-bit deviates are generated as described above. As they are generated, they are all added to each other. The sum of all 1,000,000 deviates is given as a hexadecimal number for each SID. An implementation MUST produce exactly these hexadecimal numbers. To aid in the verification of the conversion of these numbers to values of delay in seconds, approximate values are given (assuming lambda=1). An implementation SHOULD produce delay values in seconds that are close to the ones given below.
同一の入力からの異なる実装によって生成されるテストスケジュールを同一にすることが重要です。非自明の部分は、擬似ランダムの指数分布偏差の生成です。実装者が相互運用性を検証するのを支援するために、いくつかのテストベクトルが提供されます。16進数として表されるSIDの128ビット値の4つの値のそれぞれについて、上記のように1,000,000の指数関数的に分布した64ビット偏差が生成されます。それらが生成されると、それらはすべてお互いに追加されます。すべての1,000,000の逸脱の合計は、各SIDの16進数として与えられます。実装は、これらの16進数を正確に生成する必要があります。これらの数値の秒数の値への変換の検証を支援するために、おおよその値が与えられます（Lambda = 1を仮定）。実装では、以下に示すものに近い数秒で遅延値を生成する必要があります。
SID = 0x2872979303ab47eeac028dab3829dab2 SUM[1000000] = 0x000f4479bd317381 (1000569.739036 seconds)
SID = 0x2872979303AB47EEAC028DAB3829DAB2 SUM [1000000] = 0x000F4479BD317381（1000569.739036秒）
SID = 0x0102030405060708090a0b0c0d0e0f00 SUM[1000000] = 0x000f433686466a62 (1000246.524512 seconds)
SID = 0x010203030405060708090A0B0C0D0E0F00 SUM [1000000] = 0x000F433686466662（1000246.524512秒）
SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds)
sid = 0xdeadbeefdeadeadeadbeefdeadbeef sum [1000000] = 0x000f416c8884d2d3（99788.533277秒）
SID = 0xfeed0feed1feed2feed3feed4feed5ab SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds)
sid = 0xfeed0feed1feed2feed3feed4feed5ab sum [1000000] = 0x000f3f0b4b416ec8（99179.293967秒）
Authors' Addresses
著者のアドレス
Stanislav Shalunov Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104
Stanislav Shalunov Internet2 1000 Oakbrook Drive、Suite 300 Ann Arbor、MI 48104
EMail: shalunov@internet2.edu
WWW: http://www.internet2.edu/~shalunov/
Benjamin Teitelbaum Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104
Benjamin Teitelbaum Internet2 1000 Oakbrook Drive、Suite 300 Ann Arbor、MI 48104
EMail: ben@internet2.edu
WWW: http://people.internet2.edu/~ben/
Anatoly Karp Computer Sciences Department University of Wisconsin-Madison Madison, WI 53706
アナトリーカープコンピューターサイエンス学部ウィスコンシンマディソン大学マディソン、ウィスコンシン州53706
EMail: akarp@cs.wisc.edu
Jeff W. Boote Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104
Jeff W. Boote Internet2 1000 Oakbrook Drive、Suite 300 Ann Arbor、MI 48104
EMail: boote@internet2.edu
Matthew J. Zekauskas Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104
Matthew J. Zekauskas Internet2 1000 Oakbrook Drive、Suite 300 Ann Arbor、MI 48104
EMail: matt@internet2.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。