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)
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).
著作権（C）インターネット協会（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）時間を通じて、それらに利用可能な非常に正確なタイムソースを持っていますサーバ。 IPPM片道アクティブ測定値を収集するための技術を標準化することによって、我々はIPPMメトリックが現在可能であるよりも、インターネットパスのはるかに広いメッシュ全体に収集することができる環境を作成したいと考えています。一つの特に魅力的なビジョンは、pingのようなICMPベースのツールを使用して、ラウンドトリップ時間の測定値として当たり前のように一方向遅延の測定になるだろうオープンOWAMPサーバの広範囲の展開です。
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.
セキュリティ機能は、オプションの認証および/またはコントロールとテストメッセージの暗号化が含まれます。これらの機能は、結果や特殊なOWAMPテストストリームへの治療や検査結果を改ざんするために、送信者が生成したタイムスタンプを変更しようと試みを提供しようとman-in-the-middle攻撃への不正アクセスを防止するために有用であり得ます。
In this document, the key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" are to be interpreted as described in [RFC2119].
この文書では、キーワード「MUST」、「REQUIRED」は、「推奨」、「SHOULD」、および[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 - コントロールとOWAMPテスト：OWAMPは、実際には2つの相互に関連するプロトコルから構成されています。 OWAMP - 制御は、開始起動、テストセッションを停止し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 - テストOWAMP、制御以外の制御プロトコルと組み合わせて使用することができるが、著者らは、意図的にいずれかの共通制御プロトコルとしてOWAMP - コントロールの実装と展開を奨励するために同一のRFCの両方のプロトコルを含めることを選択しました活性測定を-way。実装し、展開するのは簡単である、完全かつオープン片道アクティブ測定ソリューションは、ドメイン間片道アクティブ測定がpingと同じくらい当たり前になる可能性がある中で、将来を確保するために重要です。我々は予想しなかったりOWAMP - コントロールは、汎用拡張可能な測定の基礎を形成し、制御プロトコルを監視することをお勧めしますどちらも。
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 - 制御が簡単な方法で一方向活性測定セッションおよび結果検索のネゴシエーションをサポートするように設計されています。セッション開始時に、送信者と受信者のアドレスとポート番号、セッション開始時刻、セッションの長さ、テストパケットサイズ、テストストリームの平均ポアソンサンプリング間隔、および非常に一般的な[RFC 2330]のいくつかの属性概念の交渉があります差別化サービスネットワークを横切って一方向ネットワーク特性の測定をサポートするために使用することができるパケットのサイズとホップごとのふるまい（PHB）[RFC2474]を含むパケットタイプの。また、OWAMP - コントロールは、テストストリームを記述するセッションごとの暗号化と認証の両方のテストおよび制御トラフィックのために、テストストリームエンドポイントのプロキシとして機能することができ、測定サーバ、および擬似ランダムポアソン過程のためのシード値の交換をサポートしています送信者によって生成されます。
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 - コントロールが効果的に企業のプライベートネットワーク内で監視の展開をネットワークに任意のホスト上で実行されている公的にアクセス可能な測定ビーコンから、様々な環境で一方向のアクティブな測定をサポートすることができると信じています。簡易ネットワーク管理プロトコル（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;
セッション送信者OWAMP - テストセッションの送信エンドポイント。
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;
一つ以上のOWAMP - テストセッションを管理するサーバエンドシステムは、セッション・エンドポイントにセッションごとの状態を設定することが可能であり、テストセッションの結果を返すことが可能です。
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
OWAMP - テストセッションのための要求を開始する制御クライアントエンドシステムは、セッションのセットの開始をトリガし、その終了をトリガすることができます。そして
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.
異なる論理ロールは、同じホストで再生することができます。 、サーバーとのセッションレシーバの役割を果たし取得クライアント、およびセッション送信者、および他のコントロールクライアントの役割を果たして1：たとえば、上の図では、実際には2つだけのホストがある可能性があります。これは、以下に示します。
+-----------------+ +------------------+
| 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).
最後に、多くのインターネット経路がATM上セグメント輸送IP、遅延と損失の測定値を含むためする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テスト：上記のように、OWAMPは、二つの相互に関連するプロトコルから構成されています。前者は、TCP上に積層され、開始し、測定セッションを制御し、その結果をフェッチするために使用されます。後者のプロトコルは、UDP上に積層され、被試験インターネット経路に沿っシングルトン計測パケットを送信するために使用されます。
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 - コントロールメッセージは（早期停止 - セッションメッセージの可能性を除いて）OWAMP - テストセッションが実際に開始され、それらが完了した後だけ前に送信されます。
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.
認証されていない、認証済み、および暗号化：OWAMP - コントロールとOWAMP - テストプロトコルは、3つの動作モードをサポートしています。認証済みまたは暗号化モードは、エンドポイントが共有秘密を持っている必要があります。
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.
各OWAMP制御メッセージのタイプは、最初の16個のオクテットを読んだ後に見出すことができます。各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 - コントロールセッションに関連付けられた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:
まず、クライアントは、サーバがサーバの挨拶で応答well-knownポート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.)
以下のモードの値は意味がある：暗号化のための認証のために認証されていない1、2、及び4。サーバーから送信されたモードフィールドの値は、ビット単位のORこのセッション中にサポートしていく所存ですモード値です。このように、モード32ビット値の最後の3ビットが使用されます。最初の29ビットはゼロでなければなりません。クライアントはモード値の最初の29ビットの値を無視しなければなりません。 （ビットは将来のプロトコル拡張のために利用可能であるこのように、これは、意図拡張機構です。）
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.
塩とCountは後述のように共有秘密の鍵を導出する際に使用するパラメータです。
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:
そうでない場合、クライアントは次のセットアップ-Responseメッセージで応じなければなりません：
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.
ここで、モードは、クライアントがこのOWAMP - コントロールセッション中に使用することを選択したモードです。また、このOWAMP - コントロールセッションの制御下で開始されたすべてのOWAMP - テストセッションのために使用されます。モードでは、1つのまたは0のビットは、最後の3ビットに設定されなければなりません。それは最後の3ビットに設定される1ビットである場合、このビットは、サーバ（すなわち、同じビットサーバ挨拶にサーバによって設定されていなければならない）を使用することに合意したモードを指定する必要があります。モードの最初の29ビットはゼロでなければなりません。サーバは、最初の29ビットの値を無視しなければなりません。ゼロモードビットがクライアントによって設定されている場合、クライアントはセッションを続行しないことを示します。この場合には、クライアントとサーバは、OWAMP - コントロールセッションに関連付けられているTCPコネクションを閉じる必要があります。
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.)
認証されていないモードでは、鍵ID、トークン、およびクライアント-IVは未使用です。それ以外の場合は、鍵IDはしばらくトークンクライアントは、認証や暗号化に使用することを希望する秘密の共有サーバーに指示します長さはUTF-8文字列、最大80個のオクテット（文字列が短い場合、それはゼロオクテットで埋められている）であり、 16オクテットの挑戦、暗号化に使用される16オクテットAESセッションキー、および認証のために使用される32オクテットHMAC-SHA1セッション・キーを連結したものです。トークン自体は、暗号ブロック連鎖（CBC）の[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は、単にユニークである必要があります（つまり、それは同じ秘密鍵を使用して、異なるセッションのために繰り返されてはなりません-random数ソース：これが行われている場合、同じ秘密鍵で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は、サーバーによってランダムに生成されます。認証されていないモードでは、サーバー-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フィールドは、通信を継続するために、サーバーの意欲を示しています。受け入れフィールドのゼロ値は、サーバが認証を受け入れ、さらに取引を行う意志があることを意味しています。非ゼロ値は、サーバが何らかの理由で、このOWAMP - コントロールセッションでさらに取引を行うことを望んでいない、認証を受け入れるか、しないことを示しています。利用可能受け入れ値の完全なリストは、「acceptフィールドの値」、セクション3.3に記載されています。
If a negative (non-zero) response is sent, the server MAY (and the client SHOULD) close the connection after this message.
ネガティブ（非ゼロ）応答が送信された場合、サーバーMAY、このメッセージの後に接続を閉じる（およびクライアントが必要があります）。
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 - 制御コマンド」で説明したように、非ゼロである受け入れない限り、認証と暗号化モードでは、開始時刻は、暗号化されています。 （コントロール接続を初期化することができない限り、認証および暗号化モードに入ることができません。）
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 - コントロールの各メッセージの認証が（この文書に記載されているコマンドと呼ぶ）をそれにHMACを追加することによって達成されます。 OWAMPが使用するHMACはHMAC-SHA1は、128ビットに切り捨てられます。このように、すべてのHMACフィールドは16オクテットです。 HMACは、キーを必要とします。 HMACセッションキーはOWAMP - コントロール接続設定中のAESセッションキーと一緒に通信されます。 HMACセッション鍵は、独立してAESセッションキーを導出することべきである（もちろんの実装、両方のキーのためのランダムビットを生成するために同じ機構を使用してもよいです）。各HMACは前のHMAC（それは含まない）の間に、新たなHMACの始まりまでの一定方向に送られたすべてのものをカバーして送りました。暗号化が設定されると、この方法では、OWAMP - コントロール接続の各ビットは、一度だけHMACによって認証されます。
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ブロックはストリームの残りの部分と一緒に暗号化されているので、認証は、暗号化の前に起こります。復号化するとき、順序は、もちろん、逆になる：最初のものは、復号化し、一方は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 - 制御プロトコルで使用されています。次のように有効な受け入れのフィールド値のフルセットは、以下のとおりです。
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 - コントロールに関しては同一であり、唯一OWAMPテストが異なっている）において、全てのさらなる通信が（CBCモードを使用して）AESセッション鍵で暗号化され、HMACセッション鍵で認証します。クライアントは、IVなどのクライアント-IVとストリーム暗号を使用してちょうど確立OWAMP - コントロール接続を介して送信し、すべてを暗号化します。これに対応し、サーバは、IVとしてサーバー-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を含むブロック以下のブロックで始まります。二つの流れ（クライアントからサーバに行く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.
クライアントは、スタートセッションコマンドを送信した後、その双方が（不特定の順序で）ストップセッションコマンドを送信し、受信するまで、活性測定を実施していると言われます。同様に、サーバは、それがスタートセッションコマンドを受信した後、その双方が（不特定の順序で）ストップセッションコマンドを送信し、受信するまで活性測定を実施していると言われます。
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):
これはすぐに一つ以上のスケジュールスロットの説明（スケジュール・スロットの数は、上記のフィールド「スケジュールスロットの数」で指定されている）が続きます。
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.
リクエスト-sessionコマンド：すべてのこれらのメッセージは、一つの論理メッセージを構成しています。
Above, the first octet (1) indicates that this is the Request-Session command.
上記、（1）最初のオクテットがこの要求-sessionコマンドであることを示しています。
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では、SenderとReceiverのIPバージョン番号です。 IPバージョン番号が4である場合、12個のオクテットは、送信者アドレス及び受信機アドレスに格納された4オクテットの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.)
コンファレンス・送信者とコンファレンス・レシーバは、クライアントによって0または1に設定しなければなりません。値が1の場合、サーバは、1とゼロ以外の値を解釈する必要があり、サーバは、対応するエージェント（送信または受信）を設定するように求められています。この場合、対応するポートの値は、サーバによって無視されるべきです。カンファレンス・センダとカンファレンスレシーバの少なくとも一方が1（いずれもサーバが設定可能な2つのホスト間のセッションを実行するように依頼されている場合に、設定することができる。）しなければなりません
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).
スケジュールスロットの数は、前に述べたように、HMACの二つのブロックの間に行くスロットレコードの数を指定します。テストパケットを（次のセクションを参照）を送信するタイミングを決定するために、送信者によって使用されます。
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).
パケットの数（サーバーまたはクライアントのいずれかが早期にセッションを中止できることに注意してください）このOWAMP - テストセッションの間に送信されるように、アクティブ計測パケットの数です。
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.
コンファレンス・送信者が設定されていない場合、送信元ポートはOWAMP - テストパケットが送信されるからUDPポートです。コンファレンス・レシーバが設定されていない場合、レシーバーポートはパケットが送信されることが要求されたUDPポートOWAMP - テストです。
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は、セッション識別子です。これは、フェッチセッションをコマンドの引数として後のセッションで使用することができます。 SIDは、常に受信側で生成され、コンファレンス・レシーバは0。この方法の場合にのみ意味があります。 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テストパケットに付加されるオクテットの数（OWAMPテストの議論においてパディングの詳細を参照します）。
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.
開始時間は、セッションは、（スタート・セッションのコマンドが発行される前にではなく）開始する時間です。このタイムスタンプはOWAMPテストタイムスタンプと同じ形式です。
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.
タイムアウト（または損失しきい値）は（タイムスタンプとして表される）の時間間隔です。それが送られた後、それはタイムアウト秒の間に受信されない場合は、現在のリクエスト-sessionコマンドによって設定されているテストセッションに属するパケットが失われたとみなされます。
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].
タイプP記述子は、（非常に大きい）TYPE-P空間のサブセットのみをカバーします。タイプPの記述子の最初の2ビットが00である場合、その後の6ビットは[RFC2474]で定義されるように、送信されたOWAMPテストパケットの要求された差別化サービスコードポイント（DSCP）値を指定します。タイプPの記述の最初の2ビットが01である場合、その後の16ビットは、[RFC2836]で定義されるように、要求された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.
コンファレンス・送信者が設定されている場合は、Type-Pの記述は、その値に応じてパケットを送信する送信者を設定するために使用されるべきです。コンファレンス・送信者が設定されていない場合は、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.
コンファレンス・送信者が設定され、サーバはそれができないか、OWAMP - テストパケットに対応する属性を設定したくないタイプ-Pの記述を認識するか、またはしない場合は、セッション要求を拒否すべきです。コンファレンス・送信者が設定されていない場合、サーバーは、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フィールド内のゼロは、サーバがセッションを行うために喜んでであることを意味します。非ゼロ値は、要求の拒絶を示します。利用可能受け入れ値の完全なリストは、「acceptフィールドの値」、セクション3.3に記載されています。
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.
応答でのポートの意味は、応答を求め、クエリ内のコンファレンス・送信者とコンファレンス・レシーバの値に依存します。両方が設定されている場合、ポートフィールドが未使用です。唯一のコンファレンス・送信者が設定されている場合、ポートはOWAMP - テストパケットを期待するからポートです。唯一のコンファレンス・レシーバが設定されている場合、ポートはOWAMP - テストパケットが送信されるポートです。
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は発電機に属する4オクテットのIPv4 IP番号、8オクテットのタイムスタンプ、及び4オクテットのランダム値の連結によって構成されるべきです。発電機が（ループバックを除く）任意のIPv4アドレスを持っている場合、そのうちの一つは、すべての通信が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.
これを実現するために、我々は、スロットの与えられた数とスケジュールを持っています。各スロットは、タイプおよびパラメータを有しています。二つのタイプがサポートされています（0のコードによって示される）指数分布疑似ランダム量と（1の符号によって示される）一定量。パラメータは、タイムスタンプとして表され、時間間隔を指定しています。 （分布密度関数は、ラムダ*のEXP（-lambda * x）はxの正の値の場合と同様に発現される場合、又は1 /ラムダ）タイプ0スロット（指数分布疑似ランダム量）のために、この間隔は、平均値です。タイプ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節で議論されています。
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つのスロットが、ゼロパラメーターを有する非ゼロパラメータとタイプ1とタイプ0。
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.
さらに、完全に任意のスケジュールは、スケジュールスロットの数に等しいテストパケットの数を作ることによって（非効率的とはいえ）に指定することができます。この場合、完全なスケジュールは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つ以上のテストセッションを要求したと肯定的にAccept-セッションの応答を受信した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:
サーバーは（可能な限り迅速に送ってください）スタート-Ackメッセージで応じなければなりません。開始-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.
受け入れがゼロでない場合、[スタート] - セッション要求が拒否されました。ゼロは、コマンドが受け入れられたことを意味します。利用可能受け入れ値の完全なリストは、「acceptフィールドの値」、セクション3.3に記載されています。サーバーMAY、およびクライアントは、拒否の場合の接続を閉じる必要があります。
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テストは、それがサーバーからスタート-ACK応答を見た直後にストリーム（スタート・セッションのコマンドが受け入れられた場合）、またはすぐにいずれか遅い自分の指定した開始時刻、後に開始する必要があります。下記の別のセクションでOWAMP - テスト送信者の行動についての詳細を参照してください。
The Stop-Sessions message may be issued by either the Control-Client or the Server. The format of this command is as follows:
ストップ・セッションのメッセージは、Control-、クライアントまたはサーバによって発行することができます。次に、このコマンドの形式は次のとおりです。
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:
上記フィールド「スキップ範囲の数」で指定したように、これはすぐにゼロ以上のスキップ範囲の記述が続いています。範囲は、単に一緒に、送信されなかったパケットの範囲を示す二つのシーケンス番号であるスキップ。
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オクテット）ストップ・セッションメッセージを完了するために端部に連結されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All these records comprise one logical message: the Stop-Sessions command.
ストップ・セッションのコマンド：これらのすべてのレコードを1つの論理メッセージを含んでいます。
Above, the first octet (3) indicates that this is the Stop-Sessions command.
上記、最初のオクテットは、（3）これはストップ-sessionsコマンドであることを示しています。
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".
非ゼロ値は、いくつかの並べ替えの失敗を示し受け入れます。ゼロ値は、正常な（しかしおそらく早期）完了したことを示します。利用可能受け入れ値の完全なリストは、「acceptフィールドの値」、セクション3.3に記載されています。
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.
（いずれかの当事者からの）ゼロ以外の値を持っていた受け入れた場合、このOWAMP - コントロールセッションによって生成されたすべてのOWAMP - テストセッションの結果は、このセッションのSIDと取得セッションが異なるOWAMP-のために動作しても、無効と見なされるべきですコントロールセッション。受け入れが（何らかの理由で、OWAMP - コントロールブレイクのために使用されるTCP接続を含む）すべてで送信されなかった場合は、このOWAMP - コントロールセッションによって生成されたすべてのOWAMP - テストセッションの結果は無効とみなすことができます。
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.
セッション数が以前に停止-sessionsコマンドによって終了されていない制御接続のローカル側によって開始された送信セッションの数を含まなければならない（すなわち、コントロールクライアントは、各受け入れ要求 - セッションコンファレンス・レシーバを考慮しなければなりません設定された、コントロール・サーバーは、各受け入れ要求 - セッションコンファレンス・送信者が設定された）を考慮しなければなりません。ストップ・セッションのメッセージは、その側で制御を正確に送信セッションを考慮していない場合、それは無効と見なされるために、接続が閉じられるべきと任意の結果が無効とみなさ得です。
Each session description record represents one OWAMP-Test session.
各セッション記述レコードは、一OWAMPテストセッションを表します。
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は、この送信セッションから送信されたであろう次のシーケンス番号を示します。完了したセッションのために、これは、Request-セッションからNumPacketsに等しくなります。
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個のパケットが送信されるために遅すぎる開始され、これはスケジュールで唯一の穴である、単一のスキップ範囲の記述は、まずSEQNOスキップを持つことになります。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.
ストップ・セッションのコマンドが送信されるときにOWAMP - コントロールの接続が破損した場合は、受信機は完全にセッションの結果を無効にしないことがあります。これは、実際に失われたパケットを記録する前に受信した最後のパケット（より大きいシーケンス番号を持つ他の言葉で、）に従うパケットのすべてのレコードを捨てなければなりません。これは、ネットワークで発生し、送信プロセスが送信されたことがないかもしれパケットのパケット損失を区別するのに役立ちます。
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 - テストセッションの受信機はOWAMPテスト送信者の最後のシーケンス番号は、実際に受信したシーケンス番号より小さいこと、OWAMP - コントロールストップセッションメッセージを通じて、学習している場合、完全なOWAMP - テストセッションの結果でなければなりません無効化されました。
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 - テストセッションの受信機は、OWAMP - コントロールストップセッションコマンドを受信すると、任意のパケットのレコードを破棄しなければならない - 失われたパケットの記録を含む - （計算）と現在の時刻との間にある時間を送信マイナスタイムアウトと現在の時刻。これは、タイムアウトが、それは場所を取るためにコマンドを停止、セッションにかかる時間よりも大きくなった場合の損失や重複を測定するための統計的な一貫性を保証します。
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.
すべてのセッションが停止-セッションメッセージを送信する前に完了するまで、完全なセッションを行うために、コントロール接続の各側は待つ必要があります。各セッションの完了時には、最後のシーケンス番号のためにスケジュールされた時間後にタイムアウトとして決定されます。エンドポイントは、ストップ・セッションのメッセージがタイムアウトした後、受信エンドポイントに到達することを確実にするために、送信エンドポイントの計算完了時に小さな増分を追加するかもしれません。
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.
セッションの早期停止を行うために、このコマンドを開始当事者がそのOWAMPテストは、このコマンドを送信する前に値が送信されたセッションパケットを送信するためのストリームを送信するのを止めなければなりません。その当事者は、それがデータを検証するために、受信したストップ・セッションメッセージからの値を使用できるように、受信機の流れを停止する前に応答を停止し、セッションメッセージを受信するまで待つ必要があります。
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.
配列は、最初の要求パケットのシーケンス番号で開始します。終了配列は、最後に要求されたパケットのシーケンス番号です。配列はすべてゼロで開始および終了配列は、すべてのものの場合は、完全なセッションが要求されると言われています。
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).
完全なセッションが要求され、セッションがまだ進行中であるか、通常以外の方法で終了した場合、セッションの結果をフェッチする要求が拒否されなければなりません。不完全なセッションが要求された場合、要求された範囲に該当し、これまでに受け取ったすべてのパケットが返されます。何のコマンドがスタート・セッションの間発行されていないとストップセッションをすることができるため、不完全なリクエストのみ（コントロール-Clientと同じまたは異なるホストからの）異なるOWAMP - コントロール接続で発生する可能性があり、注意してください。
The server MUST respond with a Fetch-Ack message. The format of this server response is as follows:
サーバは、フェッチ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".
ここでも、acceptフィールド内の非ゼロは、コマンドの拒絶を意味しています。受け入れが非ゼロの場合、サーバーは、残りのすべてのフィールドにゼロを指定しなければなりません。クライアントが受け入れた場合は、非ゼロである（HMACを除く）すべての残りのフィールドを無視しなければなりません。利用可能受け入れ値の完全なリストは、「acceptフィールドの値」、セクション3.3に記載されています。
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は、この送信セッションから送信されたであろう次のシーケンス番号を示します。完了したセッションのために、これは、Request-セッションからNumPacketsに等しくなります。セッションが終了した場合は、この情報にのみ使用可能です。終了がゼロである場合、次の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.
レコード数は、要求された範囲内のパケットレコードの数です。この数は、理由は途中で終了したセッションの要求-sessionコマンドの再生のパケット数よりも少ないかもしれない、またはそれがあるため、重複の大きいかもしれません。
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 - テストセッションデータを送らなければなりません。
The OWAMP-Test session data consists of the following (concatenated):
OWAMPテストセッションデータは、以下の（連結）で構成されています。
+ 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.
セッションを開始するために使用されたリクエスト-sessionコマンドの再生を+。 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つのオクテットを（含みますIPv6ではTTL）、またはホップリミット：
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テストの説明を参照）+。
+ 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は、すべてのゼロ・ビットから成るタイムスタンプを受け取ります。
+ 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テストプロトコルを記述する。これは、Request-セッション交換中にネゴシエート、送信者と受信者の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 - コントロールと同じように、OWAMP - テストは、3つのモードがあります。 OWAMP - コントロールセッションによって生成されるすべてのOWAMP - テストセッションは、そのモードを継承します。
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サーバー、OWAMP - テストの送信者、およびOWAMP - テストレシーバは、潜在的にすべての異なるマシンすることができます。 （典型的なケースでは、我々は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 - コントロールセッションに支配されている場合でも、別のOWAMP - テストセッションのために独立しています。
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.
すべてのOWAMP - テストセッションを考えてみましょう。 [スタート] - セッション交換が完了すると、送信者は、パケットの送信を開始する準備ができています。通常のOWAMP使用状況下では、最初のパケットを送信する時間が近い将来（第2離れたのかもしれない分率）です。送信者は、以下の例外を除いて、自分のスケジュールされた時間にできるだけ近いパケットを送信する必要があります送信するためにスケジュールされた時間が過去にあり、タイムアウト時間を超えて存在から分離されている場合、送信側はパケットを送ってはいけません。 （実際、このようなパケットはとにかく受信機によって失われたと考えられる。）、送信者は、それが送信されませんどのパケットを追跡する必要があります。それはどのようなパケットスキップを設定することにより、送信されなかったテストの完了時に送信側から受信側への停止・セッションのメッセージの範囲である受信機に伝えるためにこれを使用します。スキップ範囲は、セッションデータ結果の一部としてフェッチクライアントに送信されます。送信者が期限にOWAMP - テストセッションのサービスを開始できなかった場合は、過去の時間が要求-sessionコマンドで指定された場合、または[スタート] - セッション交換が予想外に時間がかかった場合、または送信スケジュールにおけるこれらの穴に発生することがあります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.
送信側は受信側に要求-sessionコマンドで指定したスケジュールでパケットのストリームを送信します。送信側は、ストリーム内のUDPパケットの本体の形式が使用されているモードに依存して255にUDPパケットに（IPv6では又はホップ限界）IPv4のTTLを設定する必要があります。
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.
タイムスタンプを生成する当事者がGPSハードウェアが使用される場合（例えば、ビットが設定されるべきである外部ソースを使用して、UTCに同期したクロックを有する場合に最初のビット、Sは、設定されるべきであり、それは現在の位置を取得したことを示し時刻またはNTPが使用され、それが階層0のソースなど）を含む外部ソースに同期していることを示す場合。タイムソース用の外部同期の概念が存在しない場合は、ビットは設定しないでください。次のビットは、他の場所MBZフィールドと同じ意味を持っている：それは、送信者によってゼロに設定し、他の皆は無視しなければなりません。次の6ビットは、スケールは、符号なし整数を形成します。乗算器は、同様の符号なし整数です。 （ - 32）* 2 ^スケール（秒）誤差推定は、乗算* 2 ^に等しい次のようにそれらが解釈されます。 （表記解明：2 ^スケールは、スケールのパワーに2である。）乗算器をゼロに設定してはいけません。乗数がゼロの場合、パケットが破損しているとみなされ、廃棄されるべきである（SHOULD）。
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テストパケットレイアウトは認証および暗号化モードで同じです。暗号化と認証操作が、しかし、異なっています。違いは、タイムスタンプがクリアテキストで送信されている間、認証済みモードでは、シーケンス番号が保護されているのに対し、暗号化モードでシーケンス番号とタイムスタンプの両方が、最大データの機密性と完全性保護を提供するために、保護されていることです。認証されたモードでクリアテキストでタイムスタンプを送信すると、1はタイムスタンプが送信者によって得られた場合、パケットが出荷されるまでの時間を短縮することができます。暗号化モードでは、送信者は、タイムスタンプを取得し、それを暗号化し、それを送信する必要があります。認証されたモードでは、中間ステップは、潜在的に（タイムスタンプがフェッチされる前にシーケンス番号を暗号化して認証することができる）の精度を向上させる、除去されます。
In authenticated mode, the first block (16 octets) of each packet is encrypted using AES Electronic Cookbook (ECB) mode.
認証されたモードでは、各パケットの最初のブロックは、（16オクテット）AES電子クックブック（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.
AESセッションキー及びHMACセッションキー：同様に各OWAMP制御セッションに、各OWAMPテストセッションは、2つのキーを有しています。しかし、鍵が得られる方法に違いがあります：OWAMP - コントロールの場合には、キーがクライアントによって生成されたとセットアップ-Responseメッセージの一部として、接続設定時に（トークンの一部として）通信します;ここで説明OWAMPテストの場合には、キーはOWAMP制御キーおよび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 - コントロールAESセッションキー（それは異なる連鎖モードで使用され、対応するOWAMP - コントロールセッションに使用されるのと同じAESセッション鍵）は次のようにOWAMPテストAESセッションキーを得ますキーとして16オクテットのセッション識別子（SID）と、AESを使用して、暗号化されました。これは、シングルブロックのECB暗号化です。その結果は、特定のOWAMP - テストセッションのパケットを暗号化（および復号化）で使用するOWAMPテストAESセッション鍵です。 OWAMP - テスト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テストHMACセッション鍵が得られる：OWAMP - コントロールHMACセッション鍵（対応OWAMP - コントロールセッションに使用されるのと同じHMACセッションキー）16オクテットで、AESを使用して、暗号化されていますセッション識別子（SID）をキーとして、これはいつもIV = 0で行わ2ブロックのCBC暗号化、です。その結果は、特定のOWAMP - テストセッションのパケットの認証に使用するOWAMPテストHMACセッション鍵です。 SIDは16オクテットであるOWAMPテストHMACセッション鍵とOWAMP - コントロールHMACセッションキーの全ては、32個のオクテットで構成されていることに留意されたいです。
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テストパケットの最初のブロックを暗号化するために使用されるECBモード。このようにして、失われた、重複、または並べ替えのパケットはOWAMP - テストセッション内の任意のパケットを解読すると問題が発生することはありません。
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.
暗号化モードでは、最初の二つのブロック（32オクテット）はAES CBCモードを使用して暗号化されています。使用するAESセッションキーは、認証モードのためのキーと同じようにして得られています。各OWAMPテストパケットが一つだけ連鎖操作で、別々のストリームとして暗号化されています。 、紛失、重複、または並べ替えパケットが問題を起こさないように、連鎖は複数のパケットにまたがっていません。 CBC暗号化のための初期化ベクトルは、ゼロに等しいすべてのビットを有する値です。
Implementation note: Naturally, the key schedule for each OWAMP-Test session MAY be set up only once per session, not once per packet.
実装上の注意：当然のことながら、それぞれのOWAMP - テストセッションのための鍵スケジュールはない、一度パケットあたり、一回だけセッションごとに設定することができます。
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テストでHMACはまた、暗号化されたパケットの一部を覆っています。したがって、認証されたモードで、HMACは、最初のブロック（16オクテット）を覆っています。暗号化モードでは、HMACは、2つの第1のブロック（32オクテット）を覆います。 OWAMPテストHMACに（これはストリームモードでの暗号化が使用されているOWAMP-制御とは異なることに注意してくださいので、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.
OWAMPテストのパケットパディングは、擬似ランダム（これは、独立して、本書に記載された任意の他の擬似乱数を生成しなければならない）であるべきです。しかし、実装は、設定パラメータ、オプション、またはパケットのパディングがすべてゼロで構成させる別の手段を提供しなければなりません。
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は255の最大値を有する）TTL秒または決して内に送達されることを必要としました。筆者の知る限りでは、この要件は、実際に実装されなかった（そして、もちろん、唯一の完全かつ普遍的な実装では、パケットが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.
+パケットのシーケンス番号を保存、時間を送信、転送すべき結果を得るために、パケットのIPヘッダからの時間、および（IPv6の又はホップ限界）IPv4のTTLを受け取ります。
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.
タイムアウト内に受信されないパケットは、失われたと考えられています。彼らは、彼らの真のシーケンス番号を記録し、時間を送信するすべてのビットがゼロであるとの時間値を受け取ると推定され、TTL（又はホップ限界）255。
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フィールドにアクセスすることができないことである）フェッチしていない場合、それは255としてTTL値を記録しなければなりません。
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.
実際に受信されたパケットは到着順に記録されています。失われたパケットのレコードが失われたパケットの送信回数の兆候としての役割を果たす。彼らは、いずれかの受信機は損失について、または任意の後の時点で学習する点に配置されるべきです。具体的には、1が一番最後に失われたパケットに対応するすべてのレコードを入れることができます。
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.
ここでは、プロトコルで使用される指数関数的にランダムな量を生成する方法を説明します。指数確率変数を生成するためのアルゴリズムのかなりの数があるが、それらのほとんどは、潜在的に異なる値が得られ、プリミティブとして対数関数を有する数学ライブラリの特定の実装に応じに依存しています。私たちは、どのような実装で同じ出力を保証し、上記の問題の自由である[クヌース]、およびからアルゴリズム3.4.1.Sを使用しています。アルゴリズムはG. Marsaglia、M.渋谷、及びJ. H.アーレンス[ZIGG]によって1970年代に開発されたジグラットファミリーに属します。それはまだ出力に指数関数的変量を生成する、巧妙なビット操作によって対数関数の使用を置き換えます。
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.
説明の容易さのために、アルゴリズムは、最初にそれらの自然な意味で解釈されるすべての算術演算して説明します。その後、データ・タイプ、演算、およびアルゴリズムによって使用される一様ランダム変量の生成に関する正確な詳細が与えられます。これは、[クヌース]、P.133からほとんどそのまま引用です。
Algorithm S: Given a real positive number "mu", produce an exponential random variate with mean "mu".
アルゴリズムSは：正の実数「ムー」を考えると、平均「ミュー」の指数ランダム変量を生成します。
First, the constants
まず、定数
Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11
Q [K] =（LN 2）/（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]
U =（.b0 B1、B2···B31）[バイナリ点に注意してください]
Locate the first zero bit b_j and shift off the leading (j+1) bits, setting U <- (.b_{j+1} ... b31)
最初のゼロのビットb_jを見つけて、U <設定、先頭の（J + 1）ビットをオフシフト - （.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.)
S2。 [即時受諾？]もしU <LN2、設定X < - ミュー*（jは*のLN2 + U）、アルゴリズムを終了します。 （すなわち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).
S3。 [最小化]> = 2このようなU <Q [k]は、その少なくともKを探します。分（U1、...、英国） - K新しい一様ランダムバイナリ画分のU1を生成し、...、英国および<Vを設定します。
S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2.
S4。 [答えを提供します。] X <セット - ミュー*（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 |--> (double)u / (2**32)
U | - >（ダブル）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 0xFFF4CFD0、＃6 0xFFFEE819、＃7 0xFFFFE7FF、＃8 0xFFFFFE2B、＃9 0xFFFFFFE0、＃10 0xFFFFFFFE、＃11から0xFFFFFFFF
For example, Q[1] = ln2 is indeed approximated by 0xB17217F8/(2**32) = 0.693147180601954; for j > 11, Q[j] is 0xFFFFFFFF.
例えば、Qは、[1] = LN2は、実際0xB17217F8によって/（2 ** 32）= 0.693147180601954を近似されます。 J> 11のために、Q [j]が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_int64_t番号に行われます。しかし、高レベルのアルゴリズムにおける乗算の操作を置き換えてください
(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].
（そのようなアルゴリズムSでUとして）32ビットの乱数列を取得するための手順は、カウンタモードでAES暗号化を使用することに依存しています。アルゴリズムの正確な動作を説明するために、我々は、ラインダールから2つのプリミティブを紹介します。そのプロトタイプと仕様は以下の通りである、そしてそれらは、[Rijnに】として、支持ラインダール実装によって提供されているものとします。
+ A function that initializes a Rijndael key with bytes from seed (the SID will be used as the seed):
シード（SIDがシードとして使用される）からのバイトのラインダールキーを初期化する機能を+。
void KeyInit(unsigned char seed[16]);
ボイド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オクテットブロックinblockを暗号化する機能を+。ここで、keyInstanceはラインダールキーを表すために使用される不透明なタイプです。
void BlockEncrypt(keyInstance key, unsigned char inblock[16]);
ボイドBlockEncrypt（keyInstanceキー、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。 [初期化ラインダールキー]キー< - 0 - KeyInit（シード）をC <符号なし16オクテット（ネットワークバイト順）カウンタの初期化]
U2. [Need more random bytes?] Set i <- c mod 4. If (i == 0) set s <- BlockEncrypt(key, c)
U2。 [より多くのランダムなバイトが必要ですか？]私は<セット - C MOD 4（I == 0）の<設定されている場合 - BlockEncrypt（キー、C）を
U3. [Increment the counter as unsigned 16-octet quantity] c <- c + 1
U3。 C + 1 - C <符号なし16オクテット量としてカウンタをインクリメント]
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。 、S高次オクテットから開始してからの出力オクテットのi_thカルテット[出力を行い]ネイティブバイトオーダに変換し（3.Bのように）OWPNum64値として表されます。
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 - コントロールサーバが提供するサービスをパスフレーズは、守るようにすることです。一つは、これが役に立つかもしれない様々な状況を想像することができます。認証されたモードは、サービスの窃盗を禁止するように設計されています。
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 - テスト送信者と受信者間のトラフィックを読み取ることができない、攻撃者のためにそれを不可能にすることだったが、ない他のトラフィック。
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.
為替の秘密を提供するために、（I）、および（ii）各メッセージの認証を提供するために、各メッセージは、2つの目標を達成することを目的とした後、HMACのブロックでAES CBCモードを使用してOWAMP - コントロールの暗号化。
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.
疑うことを知らないパーティに向けOWAMP - テストセッションは、サービス拒否（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テストセッションは情報の隠れチャネルとして使用することができます。隠れチャネルを心配している環境では、これを考慮する必要があります。
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.
AESカウンタモードでは、偶数のみ非認証モードをサポートするサーバーに擬似乱数生成のために使用されるので、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サーバは、様々な種類のリソースを消費することができます。リソースの二つの最も重要な種類のテスト結果を格納するためのネットワーク容量とメモリ（一次または二次）です。
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サーバのいずれかの実装では、ネットワーク容量及びメモリの使用を制限する技術的メカニズムを含まなければなりません。鍵IDとパスフレーズで認証され、認証されていないユーザーやユーザーによって消費されるリソースを管理するためのメカニズムは、別々であるべきです。実装のデフォルト設定では、これらのメカニズムを有効にして、保存的に低い値にリソース使用制限を設定しなければなりません。
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.
ユーザクラスに各セッションを割り当てる：リソース制限機構を設計する一つの方法は、以下の通りです。ユーザークラスは、部分的に常に存在し、それが他のクラスを含んで一つのクラス（「すべてのユーザー」）と、関係「を含む」と一緒に注文されています。ユーザクラスへのセッションの割り当ては、セッションの認証、KeyIDを、IPアドレス範囲、一日の時間、および、おそらく、他の因子の存在に基づくことができます。各ユーザクラス（オクテット単位で指定）テスト結果を格納するためのネットワーク容量（ビット/秒の単位で指定）とメモリの使用量の制限を有することになります。リソース使用の制限に伴い、現在の使用は、サーバによって追跡されるであろう。セッションが特定のユーザクラスのユーザによって要求された場合、このセッションのために必要なリソースが計算される（送信スケジュールに基づく）平均ネットワーク容量使用と最大メモリ使用（パケットの数の数に基づいてオクテットは、各パケットが内部的に保存される必要があるであろう - ）の発信セッションが任意のメモリを使用する必要はないことに注意してください。これらのリソース使用数は、所与のユーザクラスの現在のリソース使用の番号に追加されます。そのような添加は、特定のユーザークラスの制限の外のリソースの使用を取るならば、セッションは拒否されます。リソースが再利用された場合、対応策は、現在の使用から減算されます。ネットワーク容量は、すぐにセッションが終了して再利用されます。データが削除されると、メモリが再利用されます。セッションを開始しOWAMP制御接続（正常または他の方法で）閉じられた後に認証されていないセッションのために、OWAMP - テストセッションによって消費されるメモリが再利用されるべきです。認証されたセッションでは、サービスを設定する管理者は、正確な政策を決定することができるはずですが、実現することができる便利なポリシーメカニズムは、自動的にデータが取得されたメモリを再利用する機能と、（特定の設定可能な後にメモリを再利用する機能がありますユーザー・クラスに基づいて）の期間は、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]を使用したと考えられ、後で、我々はまた、DTLSを検討しました。 （完全なリストではない）、次のようにそれらの欠点は以下のとおりです。
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 - テストパケットが、失われた場合、再送されていません個々の利便性を維持しながら）、暗号化および認証されました。ストリームベースの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.
使用形態に応じて+、1は、すべてのユーザーとPKIの証明書の要件で終わることができます。 1は、PKIが望ましいことを受け入れるする場合であっても、ちょうど今日使用可能な1がありません。
+ 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:
DTLSについて：
+ 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が測定できるようにする必要があるネットワークの現象です。まだDTLSのアンチリプレイ対策や並べ替え保護がOWAMPコードの関連部分に到達するの重複や並べ替えのパケットを防止するであろう。これらの保護は、DTLSチェックの間のどこかに巧妙に作成された順序でメッセージを調べて指定しても弱くなったりしているように、一つは、当然のことながら、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.
+認証済みモードでは、タイムスタンプが明確であり、メッセージの残りの部分は、暗号化モードと同じ保護を持ちながら、どのような方法で暗号で保護されていません。このモードでは、1つのタイムスタンプの精度に対して暗号保護をトレードオフすることができます。例えば、OWAMP [APAN]のAPANのハードウェア実装は、認証モードをサポートすることができます。これらの測定の精度は、サブマイクロ秒の範囲です。 （その暗号化モードでは、ソフトウェア実装を使用して行わ）アビリーン[アビリーン]のOWAMP測定における誤差は10USを超えます。異なる環境でのユーザーが別の懸念を持っている、といくつかは非常によく、精度のすべての最後のマイクロ秒を気にすることがあります。同時に、これらの同じ環境のユーザーは、サービスへのアクセス制御を気にすることがあります。認証されたモードは、おそらくハードウェアデバイスによって生成された保護されていないタイムスタンプを、使用することをまだサーバーへのアクセスを制御するためにそれらを許可します。
Regarding IPsec:
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年後には、そのようなアビリーンなどの高度なバックボーンネットワーク上のトラフィックのわずか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.
+アプリケーションからIPsecを操作するためのAPIは、現在、十分に理解されていません。同じ宛先のための - - いくつかのパケットを認証するために、そしていくつかのオープンを残すために、いくつかのパケットを暗号化する必要があるプログラムを書くことは、IPの測定に比べてのIPsecでの運動の多くをなります。
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).
これは、新しい暗号化プリミティブで、AES、またはそれはOWAMPで使用されている方法を置き換えるために、将来的に必要になるかもしれない、またはプロトコルに他のセキュリティ関連の変更を行うこと。サーバーの挨拶とセットアップ-ResponseメッセージのMode応答のモードワード：OWAMPは、拡張性の明確に定義されたポイントを提供します。サーバグリーティングのモードワードの予約（MBZ）部から2ビットを取り、128ビットのブロックと異なるブロック暗号とAESの簡単な交換が必要な場合、例えば、これは次のように達成することができます新しい暗号と新しい暗号で認証モードを示すために別のものを使用して暗号化モードを示すために、これらのビットのいずれかを使用します。一つは、新たな暗号がサポートされていることを意味するために単一のビットを指定することができ（中：クライアントは、単一のビットセット以上でモードの選択を返すことが許されている場合（ビット消費量は、実際には、2から1に減少させることができましたサーバーの場合）または（）クライアントの場合に選択し、認証および暗号化モードのためにすでに割り当てられたビットを使用し続け;。この最適化は概念的に重要ではありませんが、それはビットを最大限に活用するために、実際に役に立つかもしれません）新しい暗号が交渉された場合はその後、後続のすべての操作は、単にAESの代わりに使用します。通常の遷移シーケンスは、このような場合に使用されることに注意してください：実装は、おそらく最初に新しい暗号をサポートし、好む開始してから、古い暗号（おそらくもはや安全であると考える）のサポートをドロップします。
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.
必要性はより広範な変更を加えることが生じた場合、これはもっと難しいだろう（おそらく256ビットブロック暗号とAESを置き換えるために）とメッセージのレイアウトを変更することが必要となります。しかし、変更は依然としてモード/モード・ワードを使用してOWAMPの拡張の枠組みの中で行うことができます。新しいビット（又は上述の最適化が使用される場合、単一ビット）の意味は、メッセージのレイアウトの変更、並びに暗号プリミティブの変化を含むであろう。
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).
モード・ワード内のビットの各々は、独立した拡張のために使用することができます。様々なビットによって信号拡張が直交しています。例えば、1つのビットは、いくつかの他の暗号化にAES-128から変更するために割り当てられたことがあり、他のビットは、（例えば、例えば、マルチキャストにわたって測定するためのサポート）プロトコルの機能を追加するために割り当てられるかもしれない、さらに別の変化に割り当てされるかもしれません等バージョンの進行の鍵導出関数は、線形順序ではなく、半順序。実装は、（もちろん、機能はそれらが必要な場合、例えば、新しい、より安全な暗号を実装するために義務化することができます）これらの機能の任意のサブセットを実装することができます。
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）の変化のセマンティクスに接続する必要があります。その後、使用され得る適切な大きさの出力と擬似ランダム関数（PRF）であるかもしれない目的のために考慮されるかもしれない一つKDFのような256ビット（おそらくHMAC-SHA256、それは次いで、依然として安全なPRFを考えた場合）、 HMACキーとしてOWAMP - コントロールセッションキー及びHMACメッセージとしてSIDを使用して、OWAMP - コントロールセッションキーからOWAMPテストセッションキーを導出します。
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つの当事者によってサポートされている最古の最も弱いモードが使用されるように、中央に悪意のある当事者は、モードビットを反転することができます。これは、暗号プリミティブ交換時に問題とみなされる場合、スキームは、モードワードの二組を比較すると、安全な通信チャネルが確立されると、おそらく再びモードを交換することにより（このような攻撃を防ぐための措置で増強されるかもしれない、そして接続をドロップすると、彼らは）一致していなければなりません。
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 - コントロールは、手動の管理との長期的なキーを使用しています。これらのキーは自動的に認証または暗号化されたモードで実行されている各OWAMP - コントロールセッションのためのセッションキーを交渉するために使用されています。サーバが管理するこれらのキーの数は、管理上の異なるユーザの数（おそらく特にヒト、ロール、またはサイトを表すロボット）は、このサーバに接続する必要がある（実際には、に等しく、）とともに直線的に比例します。同様に、各クライアントで管理される異なる手動キーの数は、クライアントが接続する必要が異なるサーバーの数です。手動長期キーの使用は[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に依存し、HMAC-SHA1にメッセージ認証のための128ビットに切り捨てられます。ランダム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 - コントロールの一部である場合、接続が切断されなければなりません。
Since OWAMP messages can have different numbers of blocks, the existential forgery attack described in example 9.62 of [MENEZES]
OWAMPメッセージがブロックの異なる数を有することができるので、存在的偽造攻撃は[メネゼス]の実施例9.62に記載さ
becomes a concern. To prevent it (and to simplify implementation), the length of any message becomes known after decrypting its first block.
問題となります。それを防ぐために（および実装を簡素化するために）、任意のメッセージの長さは、その最初のブロックを復号化した後、公知のようになります。
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.
特別な場合は、クライアントによって送信された最初の（固定長）メッセージです。そこでは、トークンは、（IV = 0とAES-CBCで暗号化されたクライアントによってランダムに生成され、）（明確にサーバーが送信した）128ビットの挑戦、128ビットのAESセッションキーの連結であり、認証に使用する256ビットのHMAC-SHA1セッションキー。 IV = 0ので、挑戦（単一の暗号ブロック）は、単純に、秘密鍵で暗号化されています。したがって、我々は（チャレンジが攻撃者によって置き換えることができるよう）平文攻撃を選択するためにAESの抵抗に依存しています。攻撃者が秘密鍵で暗号化していることができます選択平文のブロックの数は、クライアントが開始することを望んでいるセッションの数によって制限されることに留意すべきです。サーバーの挑戦の暗号化を知っている攻撃者は、セッション鍵の実存偽造を生産するため、セッションを中断させることができます。しかしながら、任意の攻撃者が任意の方法でプロトコルメッセージを破壊することによって、セッションを中断させることができます。そのため、新たな脅威は、ここで作成されません。それにもかかわらず、私たちは、サーバが二度同じチャレンジを発行しないことが必要です。 （課題は、ランダムに生成されている場合は、繰り返しが2 ^ 64のセッションの後、平均して、発生するであろう。これも500以上のために繰り返しなしで行くこと毎秒1,000,000セッションに参加信じ難い忙しいサーバーのために十分であると我々はこの満足を考えます世紀。）トークンの第二の部分に関しては、攻撃者は、そのまま最初の部分を残しながら、クライアントのトークンの後半を変更することによって、セッションキーの実存偽造を生成することができます。サーバーの次のメッセージ（接続の合否）の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.
私たちはガイAlmes、マーク・オールマン、ヤリArkko、ハミドAsgari、スティーブンヴァンデンベルジェ、エリック・ボイド、ロバート・コール、ジョーンCucchiara、スティーブン・ドネリー、スーザンEvett、サム・ハートマン、Kaynamヘダーヤト、ペトリHeleniusの、スコットホレンベック、ラスに感謝したいと思いますHousley氏、北村泰一、ダニエルHTRローソン、ウィルE.リーランド、ブルースA.麻雀、アリソンマンキン、アル・モートン、アッティラPasztor、ランディPresuhn、マシューRoughan、アンディ・シェラー、ヘンクUijterwaal、そしてサム・ワイラー彼らのコメント、提案のため、レビュー、有益な議論とプルーフリーディング。
IANA has allocated a well-known TCP port number (861) for the OWAMP-Control part of the OWAMP protocol.
IANAはOWAMPプロトコルのOWAMP制御部のためのよく知られた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 - コントロールに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.、ベラー、M.、およびR.カネッティ、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]パクソン、V.、Almes、G.、Mahdavi、J.、およびM.マティス、 "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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "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]つば、S.、大工、B.、およびF.ル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.シュウ及びK.小林、 "HOTS：OWAMP準拠のハードウェアパケットタイムスタンパー" PAM 2005年議事録において、http://www.springerlink.com/index/ W4GBD39YWC11GQTN.pdf
[BRIX] Brix Networks, http://www.brixnet.com/
[BRIX]ブリックスネットワーク、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] JHアーレンス、U.ディーター、「指数関数と正規分布からサンプリングするためのコンピュータ方法」、ACM、ボリューム15、10号、873から882まで、1972年の通信http://doi.acm.org/10.1145 /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.
[メネゼス] A. J.メネゼス、P. C.バンOorschot、及びS. A. Vanstone著、応用暗号ハンドブック、CRCプレス、更新、1997と改訂再版。
[KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd edition, 1998.
[クヌース] D.クヌース、コンピュータプログラミング、第2巻、第3版、1998年のアート。
[Abilene] One-way Latency Measurement (OWAMP), http://e2epi.internet2.edu/owamp/
【アビリーン】一方向遅延測定（OWAMP）、http://e2epi.internet2.edu/owamp/
[RIJN] Reference ANSI C Implementation of Rijndael, http://www.esat.kuleuven.ac.be/~rijmen/ rijndael/rijndaelref.zip
【ライン川】ANSI Cリファレンス実装またはラインダール、http://www.esat.kuleuven.ac.be/~rijmen/ラインダール/ rijndaelref.zip
[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/.
[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、 "サーベイヤー：ネットワーク・パフォーマンス測定のためのインフラストラクチャ"、INET'99、1999年6月の議事http://www.isoc.org/inet99/proceedings/4h/4h_2 .htm
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305]ミルズ、D.、 "ネットワーク時間プロトコル（バージョン3）仕様、実装と分析"、RFC 1305、1992年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、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]ブレイク・ウィルソン、S.、Nystrom、M.、ホップウッド、D.、ミケルセン、J.、およびT.ライト、 "トランスポート層セキュリティ（TLS）の拡張"、RFC 3546、2003年6月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、3、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、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];
**（例えば、OWAMPに共有秘密として）** 16オクテット「シード」が初期化されていると仮定する** unsigned char型の種子[16]。
** OWPrand_context next;
**次OWPrand_context。
** (initialize state) ** OWPrand_context_init(&next, seed);
（次＆シード）**（初期化状態）** OWPrand_context_init。
** (generate a sequence of exponential variates) ** while (1) { ** u_int64_t num = OWPexp_rand64(&next); <do something with num here> ... ** } */
**（指数関数的変量のシーケンスを生成する）一方、（1）{** u_int64_t NUM = OWPexp_rand64（＆次）。 ... **} * / <ここnumが何かをします>
#include <stdlib.h>
書式#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; }
{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;
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;
[J] = 0、W（J ++; J <4 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. */
** 16バイトの量「シード」**（== OWAMPのセッションID）を用いて乱数ジェネレータのシード。この関数は、アルゴリズムUNIFのステップU1 **を実装しています。 * /
void OWPrand_context_init(OWPrand_context *next, unsigned char *seed) { int i;
OWPrand_context_init（OWPrand_context *次に、unsigned char型の*種子）{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
付録B：指数外れるためのテストベクトル
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.
同じ入力から異なる実装によって生成されたテストスケジュールが同一であることが重要です。非自明な部分は、擬似ランダム指数分布ずれの発生です。相互運用性を検証することで実装を支援するために、いくつかのテストベクターが提供されます。 SIDの4与えられた128ビット値のそれぞれは、16進数として表現するために上述したように、1,000,000指数分布64ビットずれが生成されます。それらが生成されると、それらはすべて相互に追加されます。全て1,000,000ずれの合計が各SID 16進数として与えられます。実装は、まさにこれらの16進数を生成しなければなりません。秒の遅延値にこれらの数字の変換の検証を支援するために、近似値（ラムダ= 1と仮定して）与えられています。実装は下記のものに近い秒の遅延値を生成しなければなりません。
SID = 0x2872979303ab47eeac028dab3829dab2
SUM[1000000] = 0x000f4479bd317381 (1000569.739036 seconds)
SID = 0x0102030405060708090a0b0c0d0e0f00 SUM[1000000] = 0x000f433686466a62 (1000246.524512 seconds)
SID = 0x0102030405060708090a0b0c0d0e0f00 SUM [1000000] = 0x000f433686466a62（1000246.524512秒）
SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds)
SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef SUM [1000000] = 0x000f416c8884d2d3（999788.533277秒）
SID = 0xfeed0feed1feed2feed3feed4feed5ab SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds)
SID = 0xfeed0feed1feed2feed3feed4feed5ab SUM [1000000] = 0x000f3f0b4b416ec8（999179.293967秒）
Authors' Addresses
著者のアドレス
Stanislav Shalunov Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104
スタニスラフ・シャルノブインターネット2千オークブルックドライブ、スイート300アナーバー、MI 48104
EMail: shalunov@internet2.edu WWW: http://www.internet2.edu/~shalunov/
電子メール：shalunov@internet2.edu WWW：http://www.internet2.edu/~shalunov/
Benjamin Teitelbaum Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104
ベンジャミンTeitelbaumインターネット2千オークブルックドライブ、スイート300アナーバー、MI 48104
EMail: ben@internet2.edu WWW: http://people.internet2.edu/~ben/
電子メール：ben@internet2.edu WWW：http://people.internet2.edu/~ben/
Anatoly Karp Computer Sciences Department University of Wisconsin-Madison Madison, WI 53706
ウィスコンシン大学マディソンマディソン、WI 53706のアナトリー・カープコンピュータサイエンス学部大学
EMail: akarp@cs.wisc.edu
メールアドレス：akarp@cs.wisc.edu
Jeff W. Boote Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104
ジェフW. BOOTEインターネット2千オークブルックドライブ、スイート300アナーバー、MI 48104
EMail: boote@internet2.edu
メールアドレス：boote@internet2.edu
Matthew J. Zekauskas Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104
マシューJ. Zekauskasインターネット2千オークブルックドライブ、スイート300アナーバー、MI 48104
EMail: matt@internet2.edu
メールアドレス：matt@internet2.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。