RFC4656 日本語訳
4656 A One-way Active Measurement Protocol (OWAMP). S. Shalunov, B.Teitelbaum, A. Karp, J. Boote, M. Zekauskas. September 2006. (Format: TXT=132303 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Shalunov
Request for Comments: 4656 B. Teitelbaum
Category: Standards Track A. Karp
J. Boote
M. Zekauskas
Internet2
September 2006
Shalunovがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4656年のB.タイテルバウムカテゴリ: 標準化過程A.カープJ.Boote M.Zekauskas Internet2 September 2006
A One-way Active Measurement Protocol (OWAMP)
A One-道のアクティブな測定プロトコル(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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
One-道のActive Measurementプロトコル(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
1. 序論…2 1.1. テストと制御プロトコルの関係…3 1.2. 論理的なモデル…4 2. 概要について議定書の中で述べてください…5 3. OWAMP-コントロール…6 3.1. 接続セットアップ…6 3.2. 保全保護(HMAC)…11 3.3. 値、野原を受け入れてください…11 3.4. OWAMP-コントロールは命令します…12 3.5. テストセッションを作成します…13 3.6. スケジュールを送ってください…18 3.7. テストセッションを始めます…19 3.8. 停止セッション…20 3.9. フェッチセッション…24
Shalunov, et al. Standards Track [Page 1] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[1ページ]RFC4656
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
4. OWAMP-テスト…27 4.1. 送付者の振舞い…28 4.1.1. パケットタイミング…28 4.1.2. パケット・フォーマットと内容をOWAMPテストしてください…29 4.2. 受信機の振舞い…33 5. 指数関数的に計算するのは擬似乱数を分配しました…35 5.1. アルゴリズムのハイレベルの記述…35 5.2. データ型、表現、および演算…36 5.3. 一定の無作為の量…37 6. セキュリティ問題…38 6.1. 序論…38 6.2. 第三者サービス妨害を防ぎます…38 6.3. ひそかな情報通信路…39 6.4. 実装にAESを含んでいるという要件…39 6.5. リソースは制限を使用します…39 6.6. OWAMPにおける暗号の基関数の使用…40 6.7. 暗号の原始の交換…42 6.8. 長期の手動で管理されたキー…43 6.9. (Not) 塩として時間を費やします…44 6.10. AES-CBCとHMACの使用…44 7. 承認…45 8. IANA問題…45 9. 国際化問題…46 10. 参照…46 10.1. 標準の参照…46 10.2. 有益な参照…47 付録A: Cコードを抽出する、指数、逸脱します…49 付録B: ベクトルをテストする、指数、逸脱します…54
1. Introduction
1. 序論
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パフォーマンスMetrics(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
(GPS)とCDMAベースの時間ソース、ホストがますます直接か非常に正確な時間ソースか、彼らのNetwork Timeプロトコル(NTP)のプライマリ(層1)の時間サーバの近接を通して彼らにとって利用可能にする手頃な全地球側位システムのますます広い有用性で。 IPPMの一方向アクティブな測定を集めるためのテクニックを標準化することによって、私たちは、IPPM測定基準が現在可能であるというよりもインターネット経路のはるかに広いメッシュの向こう側に集められるかもしれない環境を作成することを望んでいます。 特にビジョンを強制する1つは開いているOWAMPサーバの広範囲の展開のものです。
Shalunov, et al. Standards Track [Page 2] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[2ページ]RFC4656
that would make measurement of one-way delay as commonplace as measurement of round-trip time using an ICMP-based tool like ping.
それで、一方向遅れの測定は、ピングのようなICMPベースのツールを使用することで往復の時間の測定と同じくらい平凡になるでしょう。
Additional design goals of OWAMP include: being hard to detect and manipulate, security, logical separation of control and test functionality, and support for small test packets. (Being hard to detect makes interference with measurements more difficult for intermediaries in the middle of the network.)
OWAMPの追加デザイン目標は: 小さいテストパケットの検出して、操りにくい、セキュリティ、コントロールの論理的な分離、テストの機能性、およびサポート。 (検出しにくいのに、測定値の干渉はネットワークの中央で仲介者には、より難しくなります。)
OWAMP test traffic is hard to detect because it is simply a stream of UDP packets from and to negotiated port numbers, with potentially nothing static in the packets (size is negotiated, as well). OWAMP also supports an encrypted mode that further obscures the traffic and makes it impossible to alter timestamps undetectably.
それが単にポートナンバーと、そして、交渉されたポートナンバーへのUDPパケットの流れであるので、OWAMPテストトラフィックは検出しにくいです、潜在的にパケットで静的でない無で(また、サイズは交渉されます)。 また、OWAMPはさらにトラフィックをあいまいにして、undetectablyにタイムスタンプを変更するのを不可能にする暗号化されたモードをサポートします。
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テストストリームに特別な処理を提供するのを試みる介入者攻撃または試験の成績を改竄するように送付者が発生しているタイムスタンプを変更するその試みを防ぐために役に立つかもしれません。
In this document, the key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" are to be interpreted as described in [RFC2119].
本書では、「必要で」、“SHOULD"の、そして、「お勧め」のキーワード“MUST"、および「5月」は[RFC2119]で説明されるように解釈されることになっています。
1.1. Relationship of Test and Control Protocols
1.1. テストと制御プロトコルの関係
OWAMP actually consists of two inter-related protocols: OWAMP-Control and OWAMP-Test. OWAMP-Control is used to initiate, start, and stop test sessions and to fetch their results, whereas OWAMP-Test is used to exchange test packets between two measurement nodes.
OWAMPは実際に2つの相互関連するプロトコルから成ります: OWAMP-コントロールとOWAMP-テスト。 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の両方のプロトコルを含んでいるのを故意に選びました。 実装して、配布するのが簡単な完全で開いている一方向アクティブな測定対策を持っているのは相互ドメインの一方向活発な測定がピングと同じくらい平凡になることができた未来を確実にするのに重要です。 私たちは、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
OWAMP-コントロールは、正直な態度で一方向活発な測定の交渉にセッションをサポートして、結果に検索をサポートするように設計されています。 セッション開始に、aがあります。
Shalunov, et al. Standards Track [Page 3] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[3ページ]RFC4656
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.
横切って一方向ネットワークの特性の測定をサポートするのに使用できたパケットサイズと1ホップあたりの振舞い(PHB)[RFC2474]を含むパケットタイプの非常に一般的な[RFC2330]概念の送付者、受信機アドレス、およびポートナンバーの交渉、セッション開始時刻、セッションの長さ、テストパケットサイズ、テストストリームのために間隔を抽出している意地悪なポアソン、およびいくつかの属性がサービスネットワークを差別化しました。 さらに、OWAMP-コントロールは送付者によって生成されたテストストリームについて説明する疑似無作為のポアソン過程のための種子価値のテスト、コントロールトラフィック、テストのためのプロキシが終点を流すとき行動できる測定サーバ、および交換の両方のために1セッションあたりの暗号化と認証をサポートします。
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-コントロールがさまざまな環境における一方向活発な測定をサポートすることができると信じています、私設の企業ネットワークの中で任意のホストでネットワーク監視展開へ走る公的にアクセスしやすい測定標識から。 Simple Network Managementプロトコル(SNMP)か独占ネットワーク管理プロトコルによる統合が必要であるなら、ゲートウェイは作成されるかもしれません。
1.2. Logical Model
1.2. 論理的なモデル
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;
テストセッションの結果を返す1つ以上のOWAMP-テストセッションを管理している、セッション終点の1セッションあたりの状態を構成できる、できるサーバAnエンドシステム。
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
コントロールクライアントAnはOWAMP-テストセッションを求める要求を開始して、1セットのセッションの始まりの引き金となって、彼らの終了の引き金となるかもしれないシステムを、終わらせます。 そして
Fetch-Client An end system that initiates requests to fetch
the results of completed OWAMP-Test sessions.
フェッチクライアントAnは完成したOWAMP-テストセッションの結果をとって来るという要求を開始するシステムを終わらせます。
Shalunov, et al. Standards Track [Page 4] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[4ページ]RFC4656
One possible scenario of relationships between these roles is shown below.
これらの役割の間の関係の1つの可能なシナリオが以下に示されます。
+----------------+ +------------------+
| Session-Sender |--OWAMP-Test-->| Session-Receiver |
+----------------+ +------------------+
^ ^
| |
| |
| |
| +----------------+<----------------+
| | Server |<-------+
| +----------------+ |
| ^ |
| | |
| OWAMP-Control OWAMP-Control
| | |
v v v
+----------------+ +-----------------+
| Control-Client | | Fetch-Client |
+----------------+ +-----------------+
+----------------+ +------------------+ | セッション送付者|--OWAMP-テスト-->| セッション受信機| +----------------+ +------------------+ ^ ^ | | | | | | | +----------------+ <。----------------+ | | サーバ| <、-、-、-、-、-、--+ | +----------------+ | | ^ | | | | | OWAMP-制御OWAMP-コントロール| | | v対+に----------------+ +-----------------+ | コントロールクライアント| | フェッチクライアント| +----------------+ +-----------------+
(Unlabeled links in the figure are unspecified by this document and may be proprietary protocols.)
(図のラベルされていないリンクは、このドキュメントで不特定であり、固有のプロトコルであるかもしれません。)
Different logical roles can be played by the same host. For example, in the figure above, there could actually be only two hosts: one playing the roles of Control-Client, Fetch-Client, and Session- Sender, and the other playing the roles of Server and Session- Receiver. This is shown below.
同じホストは異なった論理的な役割を果たすことができます。 例えば、図には、2人のホストしか実際に上では、いないかもしれません: Control-クライアント、Fetch-クライアント、およびSession送付者の役割、およびServerとSession受信機この役割が以下に示される他のプレーを果たす1つ。
+-----------------+ +------------------+
| Control-Client |<--OWAMP-Control-->| Server |
| Fetch-Client | | |
| Session-Sender |---OWAMP-Test----->| Session-Receiver |
+-----------------+ +------------------+
+-----------------+ +------------------+ | コントロールクライアント| <--OWAMP-コントロール-->| サーバ| | フェッチクライアント| | | | セッション送付者|---OWAMP-テスト----->| セッション受信機| +-----------------+ +------------------+
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セルのペイロードの中に合う小さいテストパケットを考慮するように設計されています(これは非認証されたモードで達成されるだけです)。
Shalunov, et al. Standards Track [Page 5] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[5ページ]RFC4656
2. Protocol Overview
2. プロトコル概要
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は2つの相互関連するプロトコルから成ります: 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、および残りがOWAMP-テストセッションの持続時間のために開くこの接続にTCP接続を確立します。 OWAMPサーバSHOULDはこのウェルノウンポートを聞きます。
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-テストセッションが実際に始められる前とだけ完成した(早めのStop-セッションメッセージの可能な例外で)後に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.
別の方法で指定されない場合、本書では定義されたすべてのマルチ八重奏量がネットワークバイトオーダーにおける符号のない整数として表されます。
3. OWAMP-Control
3. OWAMP-コントロール
The type of each OWAMP-Control message can be found after reading the first 16 octets. The length of each OWAMP-Control message can be computed upon reading its fixed-size part. No message is shorter than 16 octets.
最初の16の八重奏を読んだ後に、それぞれのOWAMP-コントロールメッセージのタイプを見つけることができます。 固定サイズ部分を読むとき、それぞれの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.
-サーバで攻撃、または限りないメモリ使用量を修理してください。SHOULDが未使用の状態を梢消する実装が否定を防ぐ、-、例えば、それが予想された後に完全なコントロールメッセージが何らかの数の分以内に受け取られないなら、TCP接続は下げられるOWAMP-コントロールセッションSHOULDと交際しました。 他の問題の欠如では、30分は妥当な上限のように見えます。
3.1. Connection Setup
3.1. 接続設定
Before either a Control-Client or a Fetch-Client can issue commands to a Server, it has to establish a connection to the server.
Control-クライアントかFetch-クライアントのどちらかがServerに命令を出すことができる前に、それはサーバに取引関係を築かなければなりません。
First, a client opens a TCP connection to the server on a well-known port 861. The server responds with a server greeting:
まず最初に、クライアントはウェルノウンポート861のサーバにTCP接続を開きます。 サーバはサーバ挨拶で反応します:
Shalunov, et al. Standards Track [Page 6] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[6ページ]RFC4656
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 未使用です(12の八重奏)。| | | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | モード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 挑戦(16の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 塩(16の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (4つの八重奏)を数えてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MBZ(12の八重奏)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.)
以下のMode値は重要です: 1、非認証、2、認証、4、暗号化されています。 サーバによって送られたModes野原の値はそれがサポートしても構わないと今会期中に思っている最頻値のビット的なORです。 したがって、Modesの32ビットの価値の最後の3ビットは使用されています。 最初の29ビットはゼロであるに違いありません。 クライアントはModes価値の最初の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であるに違いありません。 SHOULDを数えてください。さらに計算しているとして増強されて、パワーが一般的になるということになってください。
Shalunov, et al. Standards Track [Page 7] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[7ページ]RFC4656
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.
Modes値がゼロであるなら、サーバは、クライアントとコミュニケートすることを願わないで、すぐに、接続を終えるかもしれません。 ゼロに合わせるために等しいModesとの挨拶を受けるなら、クライアントSHOULDは接続を終えます。 クライアントの必要なモードが入手できないなら、クライアントは接続を終えるかもしれません。
Otherwise, the client MUST respond with the following Set-Up-Response message:
さもなければ、クライアントは応答メッセージへの以下のSetと共に応じなければなりません:
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) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | モード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . KeyID(80の八重奏)…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . トークン(64の八重奏)…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . クライアントIV(16の八重奏)…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
ここで、ModeはクライアントがこのOWAMP-コントロールセッションの間、使用するのを選ぶモードです。 また、それはこのOWAMP-コントロールセッションのコントロールの下で始められたすべてのOWAMP-テストセッションに使用されるでしょう。 Modeでは、最後の3ビット以内で1かゼロ・ビットを設定しなければなりません。 それが最後の3ビット以内で設定される1ビットであるなら、このビットはサーバが使用するのに同意したモードを示さなければなりません(すなわち、同じビットはサーバ挨拶におけるサーバによって設定されたに違いありません)。 Modeの最初の29ビットはゼロであるに違いありません。 サーバは最初の29ビットの値を無視しなければなりません。 Modeビットが全くクライアントによって設定されないなら、クライアントは、セッションを続行しないのを示します。 この場合、クライアントとサーバSHOULDはOWAMP-コントロールセッションに関連づけられたTCP接続を終えます。
Shalunov, et al. Standards Track [Page 8] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[8ページ]RFC4656
In unauthenticated mode, KeyID, Token, and Client-IV are unused. Otherwise, KeyID is a UTF-8 string, up to 80 octets in length (if the string is shorter, it is padded with zero octets), that tells the server which shared secret the client wishes to use to authenticate or encrypt, while Token is the concatenation of a 16-octet challenge, a 16-octet AES Session-key used for encryption, and a 32-octet HMAC- SHA1 Session-key used for authentication. The token itself is encrypted using the AES (Advanced Encryption Standard) [AES] in Cipher Block Chaining (CBC). Encryption MUST be performed using an Initialization Vector (IV) of zero and a key derived from the shared secret associated with KeyID. (Both the server and the client use the same mappings from KeyIDs to shared secrets. The server, being prepared to conduct sessions with more than one client, uses KeyIDs to choose the appropriate secret key; a client would typically have different secret keys for different servers. The situation is analogous to that with passwords.)
非認証されたモードで、KeyID、Token、およびClient-IVは未使用です。 さもなければ、KeyIDがUTF-8ストリングである、長さ(ストリングが、より脆いなら、それはどんな八重奏でも水増しされない)における80の八重奏まで、それはクライアントが使用したがっているどの共有秘密キーを認証したらよいか、または暗号化したらよいかをサーバに言います、Tokenは16八重奏の挑戦、暗号化に使用される、16八重奏のAES Session-キー、および認証に使用される32八重奏のHMAC- SHA1 Session-キーの連結ですが。 トークン自体は、Cipher Block Chaining(CBC)でAES(エー・イー・エス)[AES]を使用することで暗号化されています。 ゼロの初期設定Vector(IV)とKeyIDに関連している共有秘密キーから得られたキーを使用して、暗号化を実行しなければなりません。 (サーバとクライアントの両方がKeyIDsから共有秘密キーまで同じマッピングを使用します。 適切な秘密鍵を選ぶために1人以上のクライアントとのセッション、用途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 Session-キー、HMAC Session-キー、およびClient-IVはクライアントによって手当たりしだいに生成されます。 基本的な暗号[RFC4086]のセキュリティを下げることができないくらいのエントロピーでAES Session-キーとHMAC Session-キーを生成しなければなりません。 クライアントIVは、単に特有である必要があります(異なったセッションのために同じ秘密鍵を使用することですなわち、それを決して繰り返してはいけません; 厄介な状態の使用なしでClient-IVを生成することになっているずっと達成するのが簡単であるaがaが暗号で擬似乱数ソースを保証する使用を評価します: これが完了しているなら、同じ秘密鍵との2つの^64セッションが行われる前に最初の反復は起こりそうにはありません)。
Shalunov, et al. Standards Track [Page 9] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[9ページ]RFC4656
The server MUST respond with the following Server-Start message:
サーバは以下のServer-開始メッセージで反応しなければなりません:
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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の八重奏)| | | | +-+-+-+-+-+-+-+-+ | | 受け入れてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | サーバIV(16の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 開始時刻(タイムスタンプ)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ(8つの八重奏)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MBZ parts MUST be zero. The client MUST ignore their value. MBZ (MUST be zero) fields here and after have the same semantics: the party that sends the message MUST set the field so that all bits are equal to zero; the party that interprets the message MUST ignore the value. (This way, the field could be used for future extensions.)
MBZの部品はゼロであるに違いありません。 クライアントはそれらの値を無視しなければなりません。 MBZ(ゼロでなければならない)分野には、同じ意味論がここで後にあります: メッセージを送るパーティーが分野を設定しなければならないので、すべてのビットがゼロに合わせるために等しいです。 メッセージを解釈するパーティーは値を無視しなければなりません。 (このように、今後の拡大に分野を使用できるでしょう。)
Server-IV is generated randomly by the server. In unauthenticated mode, Server-IV is unused.
サーバIVはサーバで手当たりしだいに発生しています。非認証されたモードで、Server-IVは未使用です。
The Accept field indicates the server's willingness to continue communication. A zero value in the Accept field means that the server accepts the authentication and is willing to conduct further transactions. Non-zero values indicate that the server does not accept the authentication or, for some other reason, is not willing to conduct further transactions in this OWAMP-Control session. The full list of available Accept values is described in Section 3.3, "Values of the Accept Field".
Accept分野はコミュニケーションを続けるサーバの意欲を示します。 ゼロは、サーバが、認証を受け入れて、さらなるトランザクションを行っても構わないと思っているのをAccept分野手段で評価します。 非ゼロ値は、ある他の理由で、サーバが認証を受け入れないか、またはこのOWAMP-コントロールセッションのときにさらなるトランザクションを行うことを望んでいないのを示します。 利用可能なAccept値に関する完全リストがセクション3.3で説明される、「値、野原を受け入れてください、」
If a negative (non-zero) response is sent, the server MAY (and the client SHOULD) close the connection after this message.
否定的な(非ゼロの)応答を送るなら、サーバはこのメッセージの後に接続を終えるかもしれません(そして、クライアントSHOULD)。
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-
スタート時間はサーバの現在の具体化が作動し始めた時を表すタイムスタンプです。 (例えば、マルチユーザ汎用オペレーティングシステムで、サーバプロセスが始められた時であるかもしれません。) Start、Acceptが非ゼロであるなら
Shalunov, et al. Standards Track [Page 10] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[10ページ]RFC4656
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.)
設定そうがゼロであったならSHOULDを調節してください。 認証されて暗号化されたモードで、Start-時間はAcceptが非ゼロでないならセクション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で説明されます。 サーバSHOULDの同じ具体化は各セッションのときに同じ正確なStart-時間的価値を各クライアントに報告します。
The previous transactions constitute connection setup.
前のトランザクションは接続設定を構成します。
3.2. Integrity Protection (HMAC)
3.2. 保全保護(HMAC)
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は128ビットに先端を切られたHMAC-SHA1です。 したがって、すべてのHMAC分野が16の八重奏です。 HMACはキーを必要とします。 HMAC Session-キーはAES Session主要なOWAMP-コントロールの間、接続設定と共に伝えられます。 SHOULDをHMAC Session合わせてください。AES Session-キーの如何にかかわらず、引き出されてください(実装は両方のための無作為のビットがキーであると生成するのにもちろん同じメカニズムを使用するかもしれません)。 各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ブロックはストリームの残りと共に暗号化されます。 解読するとき、オーダーはもちろん逆にされます: 次に1つが1つを解読する1番目はHMACをチェックして、次に、1つはデータを使用しかけます。
The HMAC MUST be checked as early as possible to avoid using and propagating corrupt data.
使用するのを避けるためにできるだけ早くチェックされて、間違ったデータを伝播するHMAC MUST。
In open mode, the HMAC fields are unused and have the same semantics as MBZ fields.
オープン形式で、HMAC分野は、未使用であり、MBZ分野と同じ意味論を持っています。
3.3. Values of the Accept Field
3.3. 値、野原を受け入れてください。
Accept values are used throughout the OWAMP-Control protocol to communicate the server response to client requests. The full set of valid Accept field values are as follows:
OWAMP-Controlがクライアント要求へのサーバ応答を伝えるために議定書を作るのに使用される値を受け入れてください。 有効なAccept分野のフルセットが、評価する以下の通りです:
0 OK.
0 OK。
1 Failure, reason unspecified (catch-all).
1 理由不特定(キャッチすべて、)の失敗。
Shalunov, et al. Standards Track [Page 11] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[11ページ]RFC4656
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.
他のすべての値が予約されています。 メッセージ送信者はすべての非ゼロAccept値に1の値を使用するかもしれません。 正しいAcceptがそれであるなら評価するメッセージ送付者SHOULD使用は他の値を使用するでしょう。 メッセージ受信機は1としてのこれらの予約された値以外のAcceptのすべての値を解釈しなければなりません。 このように、他の値は今後の拡大に利用可能です。
3.4. OWAMP-Control Commands
3.4. OWAMP-制御コマンド
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-テストにおいて異なるだけである)で、さらなるすべてのコミュニケーションが、AES Session-キー(CBCモードを使用する)で暗号化されて、HMAC Session-キーで認証されます。 クライアントは、IVとしてClient-IVとのストリーム暗号化を使用することでそれがまさしく確立したOWAMPコントロール接続で送るすべてを暗号化します。 サーバは、IVとしてServer-IVを使用することで接続の側面を対応する、暗号化します。
The IVs themselves are transmitted in cleartext. Encryption starts with the block immediately following the block containing the IV. The two streams (one going from the client to the server and one going back) are encrypted independently, each with its own IV, but using the same key (the AES Session-key).
IVs自身はcleartextで伝えられます。 すぐにIVを含むブロックに従って、暗号化はブロックから始まります。 2つのストリーム(サーバと進行中のあるクライアントから後部へのある達する)が、それぞれそれ自身のIVと共に独自に暗号化されますが、同じキー(AES Session-キー)を使用しています。
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.)
以下のコマンドはクライアントに利用可能です: 要求セッション、スタートセッション、停止セッション、およびフェッチセッション。 コマンドStopセッションズはクライアントとサーバの両方に手があいています。(また、サーバはそれが受け取るコマンドに対応して他のメッセージを送ることができます。)
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.
それはアクティブな測定値を行っているとともにStop-セッション命令をクライアントがStart-セッション命令を送って、後送って、受け取るまで(不特定のオーダーで)言われています。 同様に、サーバはともにStop-セッション命令をStart-セッション命令を受け取って、後送って、受け取るまで(不特定のオーダーで)アクティブな測定値を行っていると言われています。
While conducting active measurements, the only command available is Stop-Sessions.
アクティブな測定値を行っている間、利用可能な唯一のコマンドがStop-セッションです。
These commands are described in detail below.
これらのコマンドは以下で詳細に説明されます。
Shalunov, et al. Standards Track [Page 12] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[12ページ]RFC4656
3.5. Creating Test Sessions
3.5. テストセッションを作成します。
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サーバへのより多くの問題ゼロRequest-セッションメッセージがそうするかもしれません。(サーバはAccept-セッションメッセージでそれぞれに反応しなければなりません)。 Accept-セッションメッセージは要求を拒否するかもしれません。
Shalunov, et al. Standards Track [Page 13] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[13ページ]RFC4656
The format of Request-Session message is as follows:
Request-セッションメッセージの形式は以下の通りです:
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-送付者| Conf-受信機| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | スケジュールスロットの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パケットの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者ポート| 受信機ポート| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 送付者Address(cont)かMBZ(12の八重奏)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 受信機アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 受信機Address(cont)かMBZ(12の八重奏)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SID(16の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さを水増しします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 開始時刻| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムアウト、(8つの八重奏)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pをタイプしている記述子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ(8つの八重奏)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC(16の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Shalunov, et al. Standards Track [Page 14] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[14ページ]RFC4656
This is immediately followed by one or more schedule slot descriptions (the number of schedule slots is specified in the "Number of Schedule Slots" field above):
1つ以上のスケジュールスロット記述がすぐに、これのあとに続きます(スケジュールスロットの数は上の「スケジュールスロットの数」分野で指定されます):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Type | |
+-+-+-+-+-+-+-+-+ MBZ (7 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Parameter (Timestamp) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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(7つの八重奏)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | スロットパラメタ(タイムスタンプ)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All these messages constitute one logical message: the Request- Session command.
これらのすべてのメッセージが1つの論理メッセージを構成します: Requestセッション命令。
Above, the first octet (1) indicates that this is the Request-Session command.
上で、最初の八重奏(1)は、これがRequest-セッション命令であることを示します。
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であるときに、八重奏はIPv4アドレスがSender AddressとReceiver Addressに保存した4八重奏に続きます。 これらの八重奏をクライアントはゼロに設定しなければならなくて、サーバで無視しなければなりません。現在重要な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にConf-送付者とConf-受信機を用意ができさせなければなりません。 サーバは1としてどんな非ゼロ値も解釈しなければなりません。 値が1であるなら、サーバが対応するエージェント(送付者か受信機)を構成するように頼まれています。 この場合、対応PortはSHOULDを評価します。サーバによって無視される、少なくとも1、1はConf-送付者とConf-受信機の、そうであるに違いありません。 (両方を設定できて、その場合、サーバがそれが構成できる2人のホストの間のセッションを実行するように頼まれています。)
Shalunov, et al. Standards Track [Page 15] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[15ページ]RFC4656
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).
以前言及されるSchedule Slotsの数は2ブロックの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).
Packetsの数はこの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.
Conf-送付者が用意ができていないなら、Sender PortはOWAMP-テストパケットが送られるUDPポートです。 Conf-受信機が設定されないなら、Receiver Portはパケットが送られるよう要求されている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.
Sender AddressとReceiver Address分野はそれぞれ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はセッション識別子です。 後のセッションのときにFetch-セッション命令に議論としてそれを使用できます。 Conf-受信機が0である場合にだけ重要です。 このように、SIDは受信側によっていつも生成されます。 SIDがどう発生しているかの情報に関してセクションの端を見てください。
Padding length is the number of octets to be appended to the normal OWAMP-Test packet (see more on padding in discussion of OWAMP-Test).
長さを水増しするのは、正常なOWAMP-テストパケット(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.
スタートTimeは始められる(以前でないときに、Start-セッション命令を発行します)セッションがことである時です。 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.
タイムアウト(または、損失敷居)は時間(タイムスタンプとして、言い表される)の間隔です。 それを送った秒後にTimeoutの間、それを受け取らないと、無くなると現在のRequest-セッション命令でセットアップされているテストセッションに属するパケットを考えるでしょう。
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をタイプしているDescriptorは(非常に大きい)のPをタイプしているスペースの部分集合だけをカバーしています。 Type-P Descriptorの最初の2ビットが00であるなら、その後の6ビットは送られたOWAMP-テストパケットの要求されたDifferentiated Services Codepoint(DSCP)値を指定します、[RFC2474]で定義されるように。 最初の2ビットのType-P記述子が01であるなら、その後の16ビットは要求されたPHB Identification Code(PHB ID)を指定します、[RFC2836]で定義されるように。
Therefore, the value of all zeros specifies the default best-effort service.
したがって、すべてのゼロの値はデフォルトのベストエフォート型サービスを指定します。
Shalunov, et al. Standards Track [Page 16] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[16ページ]RFC4656
If Conf-Sender is set, the Type-P Descriptor is to be used to configure the sender to send packets according to its value. If Conf-Sender is not set, the Type-P Descriptor is a declaration of how the sender will be configured.
Conf-送付者が用意ができているなら、Type-P Descriptorは、値に応じてパケットを送るために送付者を構成するのに使用されることになっています。 Conf-送付者が用意ができていないなら、Type-P Descriptorは送付者がどう構成されるかに関する宣言です。
If Conf-Sender is set and the server does not recognize the Type-P Descriptor, or it cannot or does not wish to set the corresponding attributes on OWAMP-Test packets, it SHOULD reject the session request. If Conf-Sender is not set, the server SHOULD accept or reject the session, paying no attention to the value of the Type-P Descriptor.
設定したくないか、Conf-送付者がそうならセットして、サーバはType-P Descriptorを認識しないことができませんか、OWAMP-テストパケットの対応する属性を設定したがっていなくて、セッションが要求するSHOULD廃棄物です。 Conf-送付者が用意ができていないなら、サーバSHOULDはセッションを受け入れるか、または拒絶します、Type-P Descriptorの値に関する注意を全く向けないで。
To each Request-Session message, an OWAMP server MUST respond with an Accept-Session message:
それぞれのRequest-セッションメッセージと、OWAMPサーバはAccept-セッションメッセージで反応しなければなりません:
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| ポート| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | SID(16の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MBZ(12の八重奏)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC(16の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
サーバはRequest-セッションメッセージを拒絶して、それは閉鎖ではなく、SHOULDです。TCP接続。 Request-セッションメッセージに否定応答を受けるなら、クライアントはそれを閉じるかもしれません。
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
応答におけるPortの意味は応答に請求した質問でConf送付者とConf-受信機の値に依存します。 両方がセットであったなら、Port分野は未使用です。 唯一のConf-送付者がそうであったなら、セットしてください、そして、PortはOWAMP-テストパケットを予想するポートです。 if
Shalunov, et al. Standards Track [Page 17] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[17ページ]RFC4656
only Conf-Receiver was set, Port is the port to which OWAMP-Test packets are sent.
Conf-受信機だけが設定されて、Portは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.
Conf-送付者が用意ができて、応答における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.
SIDs SHOULD、生成するマシンに属す4八重奏のIPv4IP番号、8八重奏のタイムスタンプ、および4八重奏の無作為の価値の連結で、組み立てられてください。 衝突の確率を減少させるために、何かそれらの1つがSHOULD IPv4アドレス(ループバックを除いた)が生成するマシンであるならすべてのコミュニケーションがIPv6ベースであってもSID世代に使用されましたか? それにIPv4アドレスが全くないなら、IPv6アドレスの最後の4つの八重奏が代わりに使用されるかもしれません。 SIDがいつも受信機によって選ばれていることに注意してください。本当に無作為の値が利用可能でないなら、SIDを予測できるようにしないのは重要です、SIDに関する知識がアクセスコントロールに使用されるかもしれないとき。
3.6. Send Schedules
3.6. スケジュールを送ってください。
The sender and the receiver both need to know the same send schedule. This way, when packets are lost, the receiver knows when they were supposed to be sent. It is desirable to compress common schedules and still to be able to use an arbitrary one for the test sessions. In many cases, the schedule will consist of repeated sequences of packets: this way, the sequence performs some test, and the test is repeated a number of times to gather statistics.
送付者と受信機は、ともにスケジュールを送るように同じように知る必要があります。 パケットが無くなるとき、このように、受信機は、いつそれらが送られるべきであったかを知っています。 一般的なスケジュールを圧縮して、テストセッションにまだ任意のものを使用できるのは望ましいです。 多くの場合、スケジュールはパケットの反復配列から成るでしょう: このように、系列は何らかのテストを実行します、そして、テストは、統計を集めるために幾度か繰り返されます。
To implement this, we have a schedule with a given number of slots. Each slot has a type and a parameter. Two types are supported: exponentially distributed pseudo-random quantity (denoted by a code of 0) and a fixed quantity (denoted by a code of 1). The parameter is expressed as a timestamp and specifies a time interval. For a type 0 slot (exponentially distributed pseudo-random quantity), this interval is the mean value (or 1/lambda if the distribution density function is expressed as lambda*exp(-lambda*x) for positive values of x). For a type 1 (fixed quantity) slot, the parameter is the delay itself. The sender starts with the beginning of the schedule and executes the instructions in the slots: for a slot of type 0, wait an exponentially distributed time with a mean of the specified parameter and then send a test packet (and proceed to the next slot); for a slot of type 1, wait the specified time and send a test packet (and proceed to the next slot). The schedule is circular: when there are no more slots, the sender returns to the first slot.
これを実装するために、私たちには、与えられた数のスロットがあるスケジュールがあります。 各スロットには、タイプとパラメタがあります。 2つのタイプがサポートされます: 指数関数的に分散している擬似ランダム量(0のコードで、指示される)と定量(1のコードで、指示されます)。 パラメタは、タイムスタンプとして言い表されて、時間間隔を指定します。 タイプ0スロット(指数関数的に分散している擬似ランダム量)に関して、この間隔が平均値である、(1/λが分配密度関数であるならλ*expとして表される、(-、x)の正の数のためのλ*x)。 タイプ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
送付者と受信機が、再現可能全体のスケジュールを実行できる必要がある、(したがって、パケットが無くなるなら、受信機がまだaを付けることができる、発信、それへのタイムスタンプ) 1が些細であるタイプのスロット
Shalunov, et al. Standards Track [Page 18] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[18ページ]RFC4656
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".
再現可能、実行します。 再現可能タイプ0のスロットを実行するために、私たちは、再現可能な方法で指数関数的に分散している量を擬似ランダムに生成することができる必要があります。 「指数関数的に分配された擬似乱数を計算し」て、後でセクション5でこれが優れる方法について議論します。
Using this mechanism, one can easily specify common testing scenarios. The following are some examples:
このメカニズムを使用して、1つは容易に一般的なテストシナリオを指定できます。 ↓これはいくつかの例です:
+ 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つのスロット、aゼロパラメタがある非ゼロパラメタとタイプ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-テストセッションの前に伝えられます。
3.7. Starting Test Sessions
3.7. テストセッションを始めます。
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クライアントはStart-セッションメッセージをサーバに送ることによって、要求されたテストセッションの実行を始めるかもしれません。
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC(16の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The server MUST respond with an Start-Ack message (which SHOULD be sent as quickly as possible). Start-Ack messages have the following format:
サーバがStart-Ackメッセージで反応しなければならない、(できるだけはやくどのSHOULDを送るか、) 始め-Ackメッセージには、以下の形式があります:
Shalunov, et al. Standards Track [Page 19] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[19ページ]RFC4656
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC(16の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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が非ゼロであるなら、Start-セッション要求は拒絶されました。 ゼロは、コマンドが受け入れられたことを意味します。 利用可能なAccept値に関する完全リストがセクション3.3で説明される、「値、野原を受け入れてください、」 サーバ、5月、およびクライアントSHOULDは拒絶の場合で接続を終えます。
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.
サーバSHOULDは応答を送る直後彼らの指定されたスタート時代直後すべてのOWAMP-テストの流れを始めます、どれがさらに遅れているかなら。 クライアントがSenderを表すなら、Server(Start-セッション命令を受け入れたなら)か彼らの指定されたスタート時代直後Start-Ack応答を見る直後クライアントSHOULDはOWAMP-テストの流れを始めます、どれがさらに遅れているかなら。 OWAMP-テスト送付者の振舞いのときに下の別々のセクションでさらに見てください。
3.8. Stop-Sessions
3.8. 停止セッション
The Stop-Sessions message may be issued by either the Control-Client or the Server. The format of this command is as follows:
Stop-セッションメッセージはControl-クライアントかServerのどちらかによって発行されるかもしれません。このコマンドの形式は以下の通りです:
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | 受け入れてください。| MBZ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッションの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ(8つの八重奏)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is immediately followed by zero or more session description records (the number of session description records is specified in
ゼロがあとに続いていて、すぐに、これがそうであるか、より多くのセッションが記述記録である、(セッション記述記録の数は指定されます。
Shalunov, et al. Standards Track [Page 20] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[20ページ]RFC4656
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のSeqno| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | スキップ範囲の数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
「スキップ範囲の数」に従った指定されるとしてのSkip Range記述が上でさばくゼロか以上がすぐに、これのあとに続きます。 スキップRangesは単に送られなかったさまざまなパケットを一緒に示す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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | まず最初に、Seqnoはスキップしました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最後に、Seqnoはスキップしました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
スキップRangesは整然としているに違いありません。 必要なら、ゼロでデータの最後の(ことによると完全で、ことによると不完全)のブロック(16の八重奏)を水増ししなければなりません。 これは、次のセッション記述記録がブロック境界を始めるのを確実にします。
Finally, a single block (16 octets) of HMAC is concatenated on the end to complete the Stop-Sessions message.
最終的に、HMACに関する単滑車(16の八重奏)は、Stop-セッションメッセージを完成するために終わりで連結されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC(16の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All these records comprise one logical message: the Stop-Sessions command.
これらのすべての記録が1つの論理メッセージを包括します: Stop-セッションは命令します。
Shalunov, et al. Standards Track [Page 21] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[21ページ]RFC4656
Above, the first octet (3) indicates that this is the Stop-Sessions command.
上で、最初の八重奏(3)は、これがStop-セッション命令であることを示します。
Non-zero Accept values indicate a failure of some sort. Zero values indicate normal (but possibly premature) completion. The full list of available Accept values is described in Section 3.3, "Values of the Accept Field".
非ゼロAccept値はある種の失敗を示します。 どんな値も正常で(ことによると時期尚早)の完成を示しません。 利用可能な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.
Acceptに非ゼロ値(何れの当事者からの)があったなら、無効の状態で考えられて、このセッションからのSIDとのFetch-セッションが異なったOWAMP-コントロールセッションの間、働いてもこのOWAMP-コントロールセッションSHOULDが生じさせたすべてのOWAMP-テストセッションの結果です。 Acceptが全く(いかなる理由でもOWAMP-コントロールの壊すのに使用されるTCP接続を含んでいる)伝えられなかったなら、このOWAMP-コントロールセッションで生じるすべてのOWAMP-テストセッションの結果は無効であると考えられるかもしれません。
Number of Sessions indicates the number of session description records that immediately follow the Stop-Sessions header.
セッションズの数はすぐにStop-セッションヘッダーに続くセッション記述記録の数を示します。
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.
セッションズの数が数を含まなければならない、以前にStop-セッション命令で終えられていないコントロール接続のローカル・サイドによって始められた状態でセッションを送ってください(すなわち、ControlクライアントはConf受信機が設定していたそれぞれの受け入れられたRequest-セッションを説明しなければなりません; Control-サーバはConf-送付者が用意ができていたそれぞれの受け入れられたRequest-セッションを説明しなければなりません)。 Stop-セッションメッセージがまさに説明しない、その側によって制御されていた状態でセッションを送ってください、そして、次に、閉じられて、それは病人と接続SHOULDであると考えられることになっていて、どんな結果も考えられた病人を得ました。
Each session description record represents one OWAMP-Test session.
それぞれのセッション記述記録は1つの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.
Skip Rangesの数は実際に送付の過程で起こった穴の数を示します。 これは実際に送付工程で決して送られなかったさまざまなパケットです。 例えば、aが発信するなら、セッションは最初の10のパケットを送るのにおいてあまりに遅く始められます、そして、これがスケジュールの唯一の穴である、そして、「スキップ範囲の数」は1でしょう。 ただ一つのSkip Range記述には、0と等しいFirst Seqno Skippedと9と等しいLast Seqno Skippedがあるでしょう。 これは「送付者の振舞い」セクションで、より詳しく説明されます。
Shalunov, et al. Standards Track [Page 22] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[22ページ]RFC4656
If the OWAMP-Control connection breaks when the Stop-Sessions command is sent, the receiver MAY not completely invalidate the session results. It MUST discard all record of packets that follow (in other words, that have greater sequence number than) the last packet that was actually received before any lost packet records. This will help differentiate between packet losses that occurred in the network and packets the sending process may have never sent.
Stop-セッション命令を送るとき、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コントロールStop-セッションメッセージを通して、終了している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-規制Stop-セッション命令を受け取り次第、OWAMP-テストセッションの受信機はどんなパケット記録も捨てなければなりません--無くなっているパケット記録を含んでいます--a(計算される)と共にそれを時間に送るのはTimeoutを引いた現在の時間と現在の時間の間低下します。 Timeoutがそれが行われるStop-セッション命令にかかる時間より長い場合、これは損失と写しの測定のために統計的な一貫性を確実にします。
To effect complete sessions, each side of the control connection SHOULD wait until all sessions are complete before sending the Stop- Sessions message. The completed time of each session is determined as Timeout after the scheduled time for the last sequence number. Endpoints MAY add a small increment to the computed completed time for send endpoints to ensure that the Stop-Sessions message reaches the receiver endpoint after Timeout.
終了しているセッションに作用するように、Stopセッションメッセージを送る前にすべてのセッションが終了するまで、コントロール接続SHOULDの各側面は待っています。 それぞれのセッションの完成した時間は最後の一連番号のための予定されている時の後にTimeoutとして決定しています。 計算へのわずかな増分が完成した5月が時間を言い足す終点は、Stop-セッションメッセージが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-テストを止めなければならないと命令する効果に、このコマンドを送る前にSession Packets Sent値を送る小川は発信しています。 そのパーティーSHOULDはそれがデータを有効にする受信されたStop-セッションメッセージから値を使用できるように受信機の流れを止める前に応答Stop-セッションメッセージを受け取るまで待っています。
Shalunov, et al. Standards Track [Page 23] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[23ページ]RFC4656
3.9. Fetch-Session
3.9. フェッチセッション
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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つの八重奏)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seqを始めてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 終わりのSeq| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SID(16の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC(16の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
始まってください。Seqは最初の要求されたパケットの一連番号です。 終わりのSeqは最後に要求されたパケットの一連番号です。 Begin Seqがすべてゼロであり、End Seqがすべてものであるなら、終了しているセッションは要求されていると言われます。
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).
終了しているセッションが要求されていて、セッションがまだ進行中である、または何らかの方法で終わったなら、通常とって来る要求を除いて、セッション結果を否定しなければなりません。 不完全なセッションが要求されるなら、すべてのパケットがあまりに遠くに受信されたので、要求された範囲SHOULDへの落下を返します。 不完全な要求がStart-セッションとStop-セッションの間でコマンドを全く発行できないので異なったOWAMP-コントロール接続(Control-クライアントとしての同じであるか異なったホストからの)のときに起こることができるだけであることに注意してください。
Shalunov, et al. Standards Track [Page 24] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[24ページ]RFC4656
The server MUST respond with a Fetch-Ack message. The format of this server response is as follows:
サーバはFetch-Ackメッセージで反応しなければなりません。 このサーバ応答の形式は以下の通りです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | Finished | MBZ (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Skip Ranges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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(2つの八重奏)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のSeqno| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | スキップ範囲の数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 記録の数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC(16の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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分野の非ゼロはコマンドの拒絶を意味します。 サーバはAcceptが非ゼロであるならすべての残っているフィールドにゼロを指定しなければなりません。 クライアントは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と等しいでしょう。 セッションが終わった場合にだけ、この情報は利用可能です。 Finishedがゼロであるなら、Next 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.
Skip Rangesの数は実際に送付の過程で起こった穴の数を示します。 セッションが終わった場合にだけ、この情報は利用可能です。 Finishedがゼロであるなら、Skip Rangesはサーバでゼロに用意ができなければなりません。
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.
Recordsの数は要求された範囲の中に下がるパケット記録の数です。 早まって終わったセッションのために、Request-セッション命令の再現ではこの数がPacketsのNumberより少ないかもしれませんか、またはそれは写しのために、よりすばらしいかもしれません。
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.
Acceptが非ゼロであったなら、これはFetchセッションメッセージへの応答を結論づけます。 そして、Acceptが0歳であったなら、サーバはすぐに、問題のOWAMP-テストセッションデータを送らなければなりません。
Shalunov, et al. Standards Track [Page 25] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[25ページ]RFC4656
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.
+ セッションを始めるのに使用されたRequest-セッション命令の再現。 それが変更されているので、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.
+ ゼロか以上がRange記述をサボります(指定されるとして)。 必要なら、Skip Range記述の最後の(ことによると完全で、ことによると不完全)のブロック(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:
スキップRange記述は単に送られなかったさまざまなパケットを一緒に示す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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | まず最初に、Seqnoはスキップしました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 最後に、Seqnoはスキップしました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
First Seqnoによって分類されるように整然とした状態でスキップRange記述を出すべきです。 どれかSkip Rangesが重なるか、または故障しているなら、セッションデータが閉じられて、病人と接続SHOULDであると考えられることであり、どんな結果も考えられた病人を得ました。
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つの八重奏を受ける、IPv6でタイムスタンプ誤り見積り、およびTime To Live(TTL)、またはHop Limitの1つの八重奏を受けてください:
Shalunov, et al. Standards Track [Page 26] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[26ページ]RFC4656
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 |
+-+-+-+-+-+-+-+-+
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番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 04| 送信エラー見積り| 誤り見積りを受けてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 08| タイムスタンプを送ってください。| 12| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 16| タイムスタンプを受け取ってください。| 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が推定で満たされたタイムスタンプを送る+が時間を送る、(計算される、発信、スケジュール)
+ 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).
+ 送信エラー見積りはMultiplier=1、Scale=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.)
パケットが損をしたと宣言することを使用される時計の誤りで決定するので、+ 標準は誤り見積りを受けます。 (それによって受け取られないなら、推定の後のTimeoutが同じくらい時間で、受信機の時計で同じくらい断固としていた状態で発信すると無くなった状態で宣言されます。)
+ A receive timestamp consisting of all zero bits.
+ Aはすべてのゼロ・ビットのタイムスタンプの成ることを受けます。
+ A TTL value of 255.
+ 255のTTL値。
4. OWAMP-Test
4. OWAMP-テスト
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をひきます。
Shalunov, et al. Standards Track [Page 27] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[27ページ]RFC4656
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-コントロールクライアント、OWAMP-制御サーバ、OWAMP-テスト送付者、およびOWAMP-テスト受信機は潜在的にすべて、異なったマシンであるかもしれません。 (典型的な場合では、私たちは、2台のマシンしかないと予想します。)
4.1. Sender Behavior
4.1. 送付者の振舞い
4.1.1. Packet Timings
4.1.1. パケットタイミング
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-テストセッションのときに、考えてください。 Start-セッション交換がいったん完全になると、送付者はパケットを送る準備ができ始めます。 標準の下では、OWAMPは事情を使用して、近い将来(1秒の何分の一遠くへ)、最初のパケットを送る時間があります。 送付者SHOULDはできるだけ彼らの予定されている時間の近くにパケットを以下の例外で送ります: 発信する予定されている時間が過去に、あって、Timeout時間以上によるプレゼントと切り離されるなら、送付者はパケットを送ってはいけません。 (本当に、そのようなものは受信機でとにかく損をしましたパケットが考えられるだろう。) 送付者はそれが送らないどのパケットの動向をおさえなければならないか。 それは、どんなパケットがテストの完成のときに送付者から受信機までStop-セッションメッセージにSkip Rangesをはめ込むことによって送られなかったかを受信機に言うのにこれを使用するでしょう。 また、セッションデータの一部が結果として生じている間、Fetch-クライアントにSkip Rangesを送ります。 Request-セッション命令で過去の時間を指定できなかったか、Start-セッション交換に不意に時間がかかることができなかったか、送付者が、定刻にOSの内部のスケジュール問題のためOWAMP-テストセッションに役立ち始めることができないなら、送付スケジュールのこれらの穴は起こることができます。 過去に、ありますが、Timeout値のSHOULDよりプレゼントから送った状態でできるだけはやく分離されないパケット。 標準のテスト率とタイムアウト値で、そのような炸裂における、パケットの数は限られています。 それにもかかわらず、ホストSHOULD NOTが故意にセッションの計画をするので、パケットのそのような炸裂は起こります。
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).
どんなスケジューリング遅れにかかわらず、実際に送られる各パケットはタイムスタンプ(パケットの)として出発についてリアルタイムでの可能な限り良い近似を持たなければなりません。
Shalunov, et al. Standards Track [Page 28] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[28ページ]RFC4656
4.1.2. OWAMP-Test Packet Format and Content
4.1.2. OWAMP-テストパケット・フォーマットと内容
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.
送付者はスケジュールがRequest-セッション命令で指定されているパケットの流れを受信機に送ります。 送付者SHOULDは255へのUDPパケットでIPv4(または、IPv6のHop Limit)にTTLをはめ込みます。 流れにおける、UDPパケットのボディーの形式は使用されるモードに依存します。
For unauthenticated mode:
非認証されたモードのために:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Packet Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 誤り見積り| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | . . . パケット詰め物…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Shalunov, et al. Standards Track [Page 29] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[29ページ]RFC4656
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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(12の八重奏)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 誤り見積り| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | MBZ(6つの八重奏)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC(16の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . パケット詰め物…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ビットはそれ以来経過している1秒の断片的な部分を表します。
So, Timestamp is represented as follows:
それで、Timestampは以下の通り表されます:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 秒の整数部| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 秒の断片的な一部分| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Shalunov, et al. Standards Track [Page 30] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[30ページ]RFC4656
The Error Estimate specifies the estimate of the error and synchronization. It has the following format:
Error Estimateは誤りと同期の見積りを指定します。 それには、以下の形式があります:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|Z| Scale | Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|Z| スケール| 乗数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
1番目は噛み付きました、S、SHOULD。タイムスタンプを発生させているパーティーが外部電源を使用することでUTCに連動する時計を持っているなら(例えば、ビットは示すそれが層を含んでいる外部電源と同期させたセットが0ソースであるのなどならそうするでしょうに)、設定されてください。 いいえ、時間ソースへの外部同期の概念、ビットSHOULD NOTあれば。設定されます。 次のビットはほかの場所にMBZ分野と同じ意味論を持っています: それを送付者によってゼロに設定されて、他の人皆は無視しなければなりません。 次の6ビット(Scale)は符号のない整数を形成します。 乗数はまた、符号のない整数です。 それらは以下の通り解釈されます: 誤り見積りはMultiplier*2^(-32)*2^Scale(秒の)と等しいです。 (記法明確化: 2^ScaleはScaleのパワーへの2歳です。) ゼロに乗数を設定してはいけません。 Multiplierがゼロであるなら、不正な状態で考えられて、捨てられたパケット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 Electronic Cookbook(ECB)モードを使用することでコード化されています。
Shalunov, et al. Standards Track [Page 31] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[31ページ]RFC4656
Similarly to each OWAMP-Control session, each OWAMP-Test session has two keys: an AES Session-key and an HMAC Session-key. However, there is a difference in how the keys are obtained: in the case of OWAMP- Control, the keys are generated by the client and communicated (as part of the Token) during connection setup as part of Set-Up-Response message; in the case of OWAMP-Test, described here, the keys are derived from the OWAMP-Control keys and the SID.
同様に、それぞれのOWAMP-テストセッションにはそれぞれのOWAMP-コントロールセッションまで、2個のキーがあります: AESセッションキーとHMACセッションキー。 しかしながら、どうキーを入手するか違いがあります: OWAMPコントロールの場合では、接続設定の間、キーは、応答メッセージへのSetの一部としてクライアントによって発生して、伝えられます(Tokenの一部として)。 ここで説明された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 Session-キーを入手します: OWAMP制御AES Session-キー(それが異なった推論モードで使用されるところの対応するOWAMP-コントロールセッションに使用される同じAES Session-キー)はコード化されています、AESを使用して、キーとしての16八重奏のセッション識別子(SID)で。 これは単滑車ECB暗号化です。 結果は特定のOWAMP-テストセッションのパケットをコード化する際に(そして、解読すること)使用するためにAES Session主要なOWAMP-テストです。 OWAMP-テストAES Session-キー、OWAMP-制御AES Session-キー、および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 Session-キーを入手します: OWAMP制御HMAC Session-キー(対応するOWAMP-コントロールセッションに使用される同じHMAC Session-キー)はコード化されています、AESを使用して、キーとしての16八重奏のセッション識別子(SID)で。 これはいつもIV=0で実行された2ブロックしているCBC暗号化です。 結果は特定のOWAMP-テストセッションのパケットを認証する際に使用するためにHMAC Session主要なOWAMP-テストです。 OWAMP-テストHMAC Session-キーとOWAMP-制御HMAC Session-キーのすべてが32の八重奏から成ることに注意してください、SIDは16の八重奏ですが。
ECB mode used for encrypting the first block of OWAMP-Test packets in authenticated mode does not involve any actual chaining; this way, lost, duplicated, or reordered packets do not cause problems with deciphering any packet in an OWAMP-Test session.
認証されたモードでOWAMP-テストパケットの最初のブロックをコード化するのに使用される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.
コード化されたモードで、最初の2つのブロック(32の八重奏)が、AES CBCモードを使用することでコード化されています。 認証されたモードのためのキーと同様に、使用するAES Session-キーを入手します。 それぞれのOWAMP-テストパケットは別々の流れとしてちょうど1つの推論操作でコード化されます。 推論が複数のパケットにかかっていないので、無くなっているか、コピーされたか、再命令されたパケットは問題を起こしません。CBC暗号化のための初期化ベクトルはゼロに合わせるために等しいすべてのビットがある値です。
Implementation note: Naturally, the key schedule for each OWAMP-Test session MAY be set up only once per session, not once per packet.
実現注意: 当然、それぞれのOWAMP-テストセッションのための主要なスケジュールは1パケットあたりの一度ではなく、1セッションに一度だけセットアップされるかもしれません。
Shalunov, et al. Standards Track [Page 32] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[32ページ]RFC4656
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.
中のパケットPaddingはSHOULDをOWAMPテストします。擬似ランダム(それは本書では言及されたいかなる他の擬似乱数の如何にかかわらず発生しなければならない)になってください。 しかしながら、実現は設定パラメータ、オプション、またはPacket Paddingをすべてのゼロから成らせる異なった手段を提供しなければなりません。
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.
パケットの間の経過時間はスロットスケジュール通りにRequest-セッションコマンド記述で言及されるように計算されます。 その時、私たちは再現可能なファッションで指数関数的に分配された擬似乱数を計算する問題を飛ばしました。 後で別々のセクションでそれについて議論します。
4.2. Receiver Behavior
4.2. 受信機の振舞い
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.
受信機は、送付者がいつパケットを送るかを知っています。 以下のパラメタは定義されます: タイムアウト(要求セッションからの)。 Timeout以上で遅れるパケットは、無くなると考えられて、(同じくらい「失われているのと同じくらい良い」。)です。 ネットワークによる損失の実際の保証が決してないことに注意してください: いつでも、まだ「無くなっている」パケットを届けているかもしれません。 IPv4のための正式仕様書は、パケットが決して届けられないのを必要としました。 作者の知識では、この要件は実際に決して実行されませんでした(もちろん、完全で普遍的な実現だけがパケットがTTL秒より長い間移動しないのを確実にするでしょう)。 事実上、IPv6では、この分野の名前は実際にHop Limitに変わりました。 さらに、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.
Timeoutの適正価値の選択は作成者ではなく、OWAMPプロトコルのユーザによって直面されていた問題です。 2分などの値は非常に安全です。 そんなにあるアプリケーションに注意してください。(対話的な「片道ピング」としてのそのようなものはそれより速くデータを得たがっているかもしれません。
As packets are received,
パケットが受け取られているので
+ timestamp the received packet;
+ タイムスタンプ、容認されたパケット。
Shalunov, et al. Standards Track [Page 33] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[33ページ]RFC4656
+ 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ヘッダーから時間、およびIPv4(または、IPv6のためのHop Limit)のための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.
Timeoutの中に受け取られなかったパケットは無くなると考えられます。 ゼロであるすべてのビットの時間的価値、および255のTTL(または、Hop Limit)は、彼らが、それらの真の一連番号で記録されて、時間を送るように推定したのを受けます。
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.
実現SHOULDはパケットのIPヘッダーからTTL/ホップLimit価値をとって来ます。 実現が実際の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.
実際に受け取られるパケットは到着順に記録されます。 無くなっているパケット記録が指摘として機能する、無くなっているパケットの倍を送ってください。 それら、SHOULD、受信機が損失に関して学ぶポイントにおいて、または、任意な後の点において置かれてください。 特にと、ある5月に、どん尻に無くなっているパケットに対応するすべての記録を置いてください。
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.
+はタイムスタンプを送ります。過去のTimeoutよりさらにか未来に、あります。
+ Send timestamp differs by more than Timeout from the time when the
packet should have been sent according to its sequence number.
+はタイムスタンプを送ります。Timeout以上で、一連番号に応じてパケットが送られるべきであった時と異なります。
+ In authenticated or encrypted mode, HMAC verification fails.
認証されるところの+かコード化されたモード、HMAC検証が失敗します。
Shalunov, et al. Standards Track [Page 34] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[34ページ]RFC4656
5. Computing Exponentially Distributed Pseudo-Random Numbers
5. 指数関数的に分配された擬似乱数を計算します。
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.Sibuya、およびJ.H.アーレンズ[ZIGG]が1970年代に発展させたジッグラト家族のものです。 まだ指数の変量を出力に生産していて、それは対数関数の賢明な噛み付いている操作による使用を取り替えます。
5.1. High-Level Description of the Algorithm
5.1. アルゴリズムのハイレベルの記述
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]=(ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!)、k<1<==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ビットの一定の無作為の2進の断片を発生させてください。
U = (.b0 b1 b2 ... b31) [note the binary point]
Uは(.b0 b1 b2…b31)と等しいです。[2進小数点に注意します]
Locate the first zero bit b_j and shift off the leading (j+1) bits,
setting U <- (.b_{j+1} ... b31)
U<を設定して、主な(j+1)ビットから最初のゼロ・ビットb_jとシフトの場所を見つけてください。(.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).
以下に注意してください。 ゼロが見つけられていないまれなケースでは、それが処方されて、アルゴリズムが戻るという(μ*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と等しいことに注意してください。)
Shalunov, et al. Standards Track [Page 35] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[35ページ]RFC4656
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。 [最小にします。] k>=2にそのようなものを最も最少に見つけてください。そのU<Q[k]。 k新しい一定の無作為の2進の断片U1を発生させてください…UkとセットV<分(U1、…、Uk)。
S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2.
S4。 [答えを提供してください。] X<μ*(j+V)*ln2を設定してください。
5.2. Data Types, Representation, and Arithmetic
5.2. データ型、表現、および演算
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:
本物が最初の32ビット後に入賞するのによる小数点に付番するとき、u_int64_t整数は解釈されます。 言い換えれば、概念的に、以下の地図は解釈をします:
u_int64_t u;
u_int64_t u。
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番号でいつものように添加の操作をします。 しかしながら、ハイレベルのアルゴリズムにおける、乗法の操作を取り替えるべきです。
Shalunov, et al. Standards Track [Page 36] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[36ページ]RFC4656
(u, v) |---> (u * v) >> 32.
(u、v)|--->(u*v)>>32。
Implementations MUST compute the product (u * v) exactly. For example, a fragment of unsigned 128-bit arithmetic can be implemented for this purpose (see the sample implementation in Appendix A).
実現はまさに、製品(u*v)を計算しなければなりません。 例えば、このために無記名の128ビットの演算の断片を実行できます(Appendix Aのサンプル実現を見てください)。
5.3. Uniform Random Quantities
5.3. 一定の無作為の量
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].
カウンタモードでAES暗号化を使用する32ビットの乱数(アルゴリズムSによるUなどの)の系列が当てにする入手のための手順。 アルゴリズムの正確な運用について説明するために、私たちはラインダールから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を欠如させてください。(無記名の炭は[16])に種を蒔きます。
+ A function that encrypts the 16-octet block inblock with the
specified key, returning a 16-octet encrypted block. Here,
keyInstance is an opaque type used to represent Rijndael keys:
+ 16八重奏のコード化されたブロックを返して、指定されたキーで16八重奏のブロック不ブロックをコード化する機能。 ここで、keyInstanceはラインダールキーを表すのに使用される分っているタイプです:
void BlockEncrypt(keyInstance key, unsigned char inblock[16]);
BlockEncryptを欠如させてください、(keyInstanceの主要で、無記名の炭の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では、ControlプロトコルからのSID(セッションID)は種子の役割を果たします。
U1. [Initialize Rijndael key] key <- KeyInit(seed) [Initialize an unsigned 16-octet (network byte order) counter] c <- 0
U1。 [ラインダールキーを初期化します] 主要な<KeyInit(種子)[無記名の16八重奏(ネットワークバイトオーダー)のカウンタを初期化します]c<0
U2. [Need more random bytes?] Set i <- c mod 4. If (i == 0) set s <- BlockEncrypt(key, c)
U2。 [より無作為のバイトを必要とします]? i<cモッズ風の4を設定してください。 (i=0)がs<BlockEncryptを設定するなら(キー、c)
U3. [Increment the counter as unsigned 16-octet quantity] c <- c + 1
U3。 [無記名の16八重奏の量としてカウンタを増加します] c<c+1
U4. [Do output] Output the i_th quartet of octets from s starting from high-order octets, converted to native byte order and represented as OWPNum64 value (as in 3.b).
U4。 i_を出力する、[出力されて、します]OWPNum64が評価するように(3.bのように)、高位八重奏から始めて、ネイティブのバイトオーダーに変換されて、表されたsからの八重奏の第カルテット。
U5. [Loop] Go to step U2.
U5。 [輪にします] U2を踏みに行ってください。
Shalunov, et al. Standards Track [Page 37] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[37ページ]RFC4656
6. Security Considerations
6. セキュリティ問題
6.1. Introduction
6.1. 序論
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.
認証されたモードの目標は1つに特定の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.
コード化されたモードの目標は全く異なっています: ネットワークの中央のパーティーが結果を作るのを困難にするには、「それらであるべきであるより良く」見えてください。 これが1であるなら特に本当である、クライアントとサーバは送付者か受信機のどちらかと一致していません。
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.
各メッセージの後にブロックのHMACがあるAES CBCモードを使用するOWAMP-コントロールの暗号化は、2つの目標を達成することを目指します: (i) それぞれのメッセージの認証を提供するために交換の秘密主義、および(ii)を提供するために。
6.2. Preventing Third-Party Denial of Service
6.2. 第三者サービス妨害を防ぎます。
OWAMP-Test sessions directed at an unsuspecting party could be used for denial of service (DoS) attacks. In unauthenticated mode, servers SHOULD limit receivers to hosts they control or to the OWAMP- Control client.
サービス(DoS)攻撃の否定に疑わないパーティーに向けられたOWAMP-テストセッションは使用できました。 非認証されたモードで、サーバSHOULDは受信機を彼らが監督するホスト、または、OWAMPコントロールクライアントに制限します。
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.
別の方法で構成されない場合、サーバのデフォルト働きはReceiver Address分野がコントロール接続が開始されたアドレスかサーバ(または、それが監督するホストのアドレス)のアドレスと等しくない要求を断つことでなければなりません。 コントロール接続における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-テストパケットを送るだけでよいです(すなわち、アドレススプーフィングは受入れられません)。
Shalunov, et al. Standards Track [Page 38] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[38ページ]RFC4656
6.3. Covert Information Channels
6.3. ひそかな情報通信路
OWAMP-Test sessions could be used as covert channels of information. Environments that are worried about covert channels should take this into consideration.
情報のひそかなチャンネルとしてOWAMP-テストセッションを使用できました。 ひそかなチャンネルを心配する環境はこれを考慮に入れるべきです。
6.4. Requirement to Include AES in Implementations
6.4. 実現にAESを含んでいるという要件
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 MUSTの実現であるのに注意してください。
6.5. Resource Use Limitations
6.5. リソースは制限を使用します。
An OWAMP server can consume resources of various kinds. The two most important kinds of resources are network capacity and memory (primary or secondary) for storing test results.
OWAMPサーバは様々な種類に関するリソースを消費できます。 最も重要な2種類のリソースは、試験の成績を格納するのにおける、(第一か二次)のネットワーク容量とメモリです。
Any implementation of OWAMP server MUST include technical mechanisms to limit the use of network capacity and memory. Mechanisms for managing the resources consumed by unauthenticated users and users authenticated with a KeyID and passphrase SHOULD be separate. The default configuration of an implementation MUST enable these mechanisms and set the resource use limits to conservatively low values.
OWAMPサーバのどんな実現も、ネットワーク容量とメモリの使用を制限するために技術的機構を含まなければなりません。 リソースを管理するためのメカニズムは非認証されることでユーザとユーザを消費しました。KeyIDとパスフレーズSHOULDと共に認証されて、別々であってください。 実現のデフォルト設定は、これらのメカニズムを可能にして、使用が保守的に低値に制限するリソースを設定しなければなりません。
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
リソース制限メカニズムを設計する1つの方法は以下の通りです: 各セッションをユーザ・クラスに配属してください。 ユーザ・クラスは「包含」関係で部分的に命令されます、いつも存在していて、いかなる他のクラスも含んでいる1つのクラス(「すべてのユーザ」)と共に。 ユーザ・クラスへのセッションの課題はセッション、KeyID、IPアドレスの範囲、時刻、および恐らく他の要素の認証の存在に基づくことができます。 各ユーザ・クラスに、ネットワーク容量(ユニットのビット/秒に指定される)の用法のための限界と試験の成績(ユニットの八重奏では、指定される)を保存するための記憶力があるでしょう。 リソース使用のための限界と共に、現在の使用はサーバによって追跡されるでしょう。セッションが特定のユーザ・クラスでユーザによって要求されているとき、このセッションに必要であるリソースは計算されます: 平均したネットワーク容量使用(送付スケジュールに基づいている)と最大のメモリ使用(各パケットが内部的に保存されるために必要とするパケットの数と八重奏の数に基づいて--外向的なセッションが少しのメモリ使用も必要としないことに注意してください)。 リソース使用が付番するこれらは当然のことのユーザの数が分類する現在のリソース使用に加えられます。 そのような追加が限界の外で与えられたユーザ・クラスにリソース使用を取るなら、セッションは拒絶されます。 リソースが取り戻されるとき、対応する測定は現在の使用から引き算されます。 セッションが終わるとすぐに、ネットワーク容量は取り戻されます。 データが取り戻されるとき、メモリは取り戻されます。
Shalunov, et al. Standards Track [Page 39] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[39ページ]RFC4656
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.
削除にされる。 非認証されたセッション、OWAMPテストセッションSHOULDによって消費されたメモリに関しては、セッションを開始したOWAMP-コントロール接続が閉じるようになった(優雅かそうでない)後に開墾されてください。 認証されたセッションのために、サービスを構成する管理者は正確な方針を決めることができるべきですが、OWAMP-テストセッションが終わった後に、実装されるかもしれない役に立つ方針メカニズムは、データが検索されるとき自動的にメモリを取り戻す能力とある構成可能な(ユーザ・クラスに基づいている)期間が経過した後にメモリを取り戻す能力です。
6.6. Use of Cryptographic Primitives in OWAMP
6.6. 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に、暗号のセキュリティー対策としてTransport Layer Security(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.
TCPベースのOWAMP-コントロールを保証するのに+ TLSを使用できましたが、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-コントロールにおけるさえ)を認証しません。 最も簡単な出口は、各メッセージにそっと歩きながら何らかの知られている書式を加えて、メッセージを使用する前に詰め物の形式が完全であることを確かめることになっているでしょう。 その結果、ソリューションは上告のいくつかを失うでしょう(「ただ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が望ましいと受け入れるつもりであってもさえ、使用可能なある今日がただありません。
Shalunov, et al. Standards Track [Page 40] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[40ページ]RFC4656
+ 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コードの関連部分に達するのを防ぐでしょう。 1つがもちろん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の展開経路は別々であるかもしれません。 9年間のIPsecを、アビリーンなどの高度なバックボーンネットワークの0.05%のトラフィックだけが次々と使用します(SSH使用は層4を超えた暗号化がある比較目的のための、2-4%でのものです、そして、HTTPS使用が0.2-0.6%であります)。 多くのできるだけ大きい異なったプラットホームのOWAMPを配布することができるのは望ましいです。
Shalunov, et al. Standards Track [Page 41] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[41ページ]RFC4656
+ 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モードによるブロック暗号に基づいている)を使用すると決めました。
6.7. Cryptographic Primitive Replacement
6.7. 暗号の原始の交換
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で使用される方法を新しい暗号の基関数に置き換えるか、またはプロトコルへの他のセキュリティ関連の変更を行うのが将来、必要になるかもしれません。 OWAMPは伸展性の明確なポイントを提供します: 応答メッセージへのSetのサーバ挨拶とMode応答におけるModes単語。 例えば、128ビットのブロックがある異なったブロック暗号とのAESの簡単な交換が必要であるなら、これは以下の通り達成されるかもしれません: サーバ挨拶のModes単語の予約された(MBZ)部分から2ビット取ってください。 これらのビットの1つを使用して、新しい暗号がある暗号化されたモードと示す別の1つが新しい暗号があるモードを認証したのを示してください。 (事実上、噛み付いている消費を2〜1まで抑えることができました、単一の1ビット以上がセットした状態でクライアントがモード選択を返すことができるなら: 人は新しい暗号がサポートされるか(サーバの場合で)、または選択されることを(クライアントの場合で)意味して、認証されて暗号化されたモードに既に割り当てられたビットを使用し続けるために1ビットを指定できました; この最適化は概念的に重要でないのですが、有効にビットを利用するのは実際には役に立つかもしれません。) そして、新しい暗号が交渉されるなら、すべてのその後の操作がAESの代わりに単にそれを使用します。 正常な変遷系列がこのような場合には使用されることに注意してください: 実装は、新しい暗号をサポートして、最初にたぶん好み始めて、次に、古い暗号(おそらく、もう安全であることは考えられない)のサポートを下げるでしょう。
Shalunov, et al. Standards Track [Page 42] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[42ページ]RFC4656
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.
必要性が、より大規模な変更(恐らくAESを256ビットのブロック暗号に取り替える)を行うために起こるなら、これは、より難しいだろう、レイアウトを変えるのをメッセージを要求するでしょう。 しかしながら、OWAMP伸展性のフレームワークの中でModes/モード単語を使用することでまだ変化を行うことができます。 新しいビット(上で説明された最適化が使用されているなら、シングルに噛み付いた)の意味論は原始的に暗号における変化と同様にメッセージレイアウトへの変化を含んでいるでしょう。
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).
独立している拡大にModes単語によるそれぞれのビットを使用できます。 様々なビットによって合図された拡大は直交しています。 例えば、AES-128からある他の暗号に変化するように1ビットを割り当てるかもしれなくて、プロトコル機能を加えるためにもう1ビットを割り当てるかもしれない、(あれほど、例えば、マルチキャストの上で測定するサポート)、しかし、主要な派生機能などを変えるために別のものを割り当てるかもしれません。 バージョンの進行は線形順序ではなく、むしろ部分的なオーダーです。 実装がこれらのどんな部分集合も実装することができる、特徴、(もちろん、特徴を実装するために義務的にすることができて、例えば、それらであるなら新しいより安全な暗号を必要とする、)
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-テストキーのための新しい主要な派生機能が必要でしょう。 意味論、そして、暗号SHOULDにおける変化では、将来、主要な派生機能(KDF)における変化の意味論に結ばれてください。 目的のために考えられるかもしれない1KDFが適切に大きさで分けられた出力がある擬似ランダム機能であるかもしれません(PRF)、256ビット(恐らくHMAC-SHA256、それがそうなら、安全なPRFはまだその時、考えた)などのように。(次に、HMACメッセージとしてHMACキーとSIDとして主要なOWAMP-コントロールセッションを使用することによって主要な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回のパーティーによってサポートされた中で最も弱いモードは使用されています。 これが暗号の原始の交換時点で問題が多いと考えられるなら、そのような攻撃(安全なコミュニケーションチャンネルがいったん確立されると恐らく再びモードを交換して、2セットのモード単語を比較して、合っていないなら接続を下げるのによる)を防ぐ測定に従って、体系は増大するかもしれません。
6.8. Long-term Manually Managed Keys
6.8. 長期の手動で管理されたキー
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,
OWAMP-コントロールは手動の管理がある長期のキーを使用します。 これらのキーは、駆け込むのが認証したそれぞれのOWAMPコントロールセッションか暗号化されたモードのために自動的にセッションキーを交渉するのに使用されます。 そしてこれらのキーの数がスケールが直線的であるサーバによって管理された、(。
Shalunov, et al. Standards Track [Page 43] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[43ページ]RFC4656
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].
必要がある行政上異なったユーザ(遺跡を表す恐らく特定の人間、役割、またはロボット)の数はこのサーバに接続します。事実上、等しい、)、同様に、各クライアントによって管理された異なった手動のキーの数は接続するクライアントが、必要がある異なったサーバの数です。 手動の長期のキーのこの使用は[BCP107]と共に対応します。
6.9. (Not) Using Time as Salt
6.9. (Not) 塩として時間を費やします。
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はよく連動している時計をもっているホストにおける走行ですが、また、時計が完全に未熟な状態でそれをホストに実行するのも可能です。 このようにして得られた遅れはもちろん直接使用可能ではありません。 しかしながら、単方向の損失や、再命令や、最小を引いた中央の遅れなどの混雑の手段や、多くの他のものなどのいくつかの測定基準が直接とすぐに、使用可能です(往復の測定で提供された情報を改良してください)。 さらに、遅れ情報さえ適切な後工程によって役に立つ場合があります。 本当に、1つは測定値のメッシュの結果が、より良い精度をもたらして、無料の時計と後工程を動かすと主張さえできます、異なったホストからのデータの相関関係が詳しい情報が後天的に利用可能であり、後工程のときに可能ですが、オンライン時計トレーニングで可能であるというわけではないときに。
Given this, time is not used as salt in key derivation.
これを考えて、時間は塩として主要な派生で費やされません。
6.10. The Use of AES-CBC and HMAC
6.10. AES-CBCとHMACの使用
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は秘密性と、そして、通報認証のために128ビットに先端を切られたHMAC-SHA1の上のAES-CBCを当てにします。 最初のブロックにおける符号表攻撃の防止に、無作為のIV選択は重要です(また、AESが、より短いブロックがある暗号より128ビットのブロック・サイズで符号表攻撃に抵抗力があることに注意されるべきです; 私たちはとにかく無作為の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 MUSTは確かめます。 メッセージを使用する前にこれがないかどうかチェックするのは重要です。 さもなければ、実存的な偽造は可能になります。 HMAC検証が失敗する完全なメッセージを捨てなければなりません(Fetch-セッション命令への応答などの長いメッセージのために数ブロックから潜在的に成る短いメッセージのための両方)。 そのようなメッセージがOWAMP-コントロールの一部であるなら、接続を下げなければなりません。
Since OWAMP messages can have different numbers of blocks, the existential forgery attack described in example 9.62 of [MENEZES]
缶が異なった数のブロック、例9.62で説明された実存的な偽造攻撃を持っているOWAMPメッセージ以来[メネゼス]
Shalunov, et al. Standards Track [Page 44] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[44ページ]RFC4656
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.
特別なケースはクライアントによって送られた最初(固定長)のメッセージです。 そこでは、トークンは128ビットの挑戦(サーバで、明確で伝えられる)、128ビットのAES Session-キー(AES-CBCと共にIV=0で暗号化されたクライアントによって手当たりしだいに生成される)、および認証に使用される256ビットのHMAC-SHA1 Session-キーの連結です。 IV=0以来、挑戦(1つの暗号ブロック)は秘密鍵で単に暗号化されます。 したがって、私たちは選ばれた平文攻撃へのAESの抵抗に依存します(攻撃者が挑戦を代入できたので)。 攻撃者が秘密鍵で暗号化したはずであるブロックの選ばれた平文の数がクライアントが開始したがっているセッションの数によって制限されることに注意されるべきです。 サーバの挑戦の暗号化を知っている攻撃者は、セッションキーの実存的な偽造を起こして、その結果、セッションを中断できます。 しかしながら、どんな攻撃者も、任意のファッションによるプロトコルメッセージを崩壊させることによって、セッションを中断できます。 したがって、どんな新しい脅威もここに作成されません。 それにもかかわらず、私たちは、サーバが二度同じ挑戦を決して発行しないのを必要とします。 (挑戦が手当たりしだいに生成されるなら、反復は起こるでしょう、平均的に、2つの^64セッションの後に; 1秒あたり100万のセッションのときに500世紀以上に、反復をなしで済ませるために参加する信じがたく忙しいサーバにさえ、これが十分であるので、私たちは、これが満足できると考えます。) トークンの第二部に関して、攻撃者は完全な状態で最初の部分を出ている間、クライアントのトークンの後半を変更することによって主要なセッションの実存的な偽造を起こすことができます。 しかしながら、すぐに(接続の承認か拒絶)が確かめないサーバの次のメッセージのHMACであるときに、この偽造はクライアントによって発見されるでしょう。
7. Acknowledgements
7. 承認
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、スティーブンヴァン書斎Berghe、エリック・ボイド、ロバート・コール、ジョーンCucchiara、スティーブン・ドネリー、スーザンEvett、サム・ハートマン、Kaynamヘダーヤト、ペトリHelenius、スコットHollenbeck、ラスHousley、喜田村Yasuichi、ダニエルH; 彼らのコメント、提案、レビュー、役立っている議論、およびプルーフ・リーディングのためのT.R.ロースン、ウィル・E.リーランド、ブルースA.Mah、アリソン・マンキン、アル・モートン、アッティラPasztor、ランディPresuhn、マシューRoughan、Andy Scherrer、ヘンクUijterwaal、およびサム・ウィーラー。
8. IANA Considerations
8. IANA問題
IANA has allocated a well-known TCP port number (861) for the OWAMP- Control part of the OWAMP protocol.
IANAはOWAMPプロトコルのOWAMPコントロール部分によく知られるTCPポートナンバー(861)を割り当てました。
Shalunov, et al. Standards Track [Page 45] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[45ページ]RFC4656
9. Internationalization Considerations
9. 国際化問題
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.
プロトコルは自然言語の少しの情報も運びません、OWAMP-コントロールにおける、KeyIDの可能な例外で。(コントロールはUTF-8でコード化されます)。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[AES] Advanced Encryption Standard (AES),
http://csrc.nist.gov/encryption/aes/
[AES]エー・イー・エス(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、「暗号化キー管理のためのガイドライン」BCP107、2005年6月のRFC4107。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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パフォーマンス測定基準のためのフレームワーク」RFC2330)は1998がそうするかもしれません。
[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分野)の定義」、RFC2474(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のためのA One道のDelay Metric、」、RFC2679、9月1999日
[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のためのA One道のPacket Loss Metric、」、RFC2680、9月1999日
[RFC2836] Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop
Behavior Identification Codes", RFC 2836, May 2000.
[RFC2836] 縁、S.、大工、B.、およびF.Le Faucheur、「ホップ振舞い識別コード」、RFC2836は2000がそうするかもしれません。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000.
[RFC2898]Kaliski、B.、「PKCS#5:」 パスワードベースの暗号仕様バージョン2インチ、RFC2898、2000年9月。
Shalunov, et al. Standards Track [Page 46] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[46ページ]RFC4656
10.2. Informative References
10.2. 有益な参照
[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.小林、「熱:」 パム2005、 http://www.springerlink.com/index/ W4GBD39YWC11GQTN.pdfの議事における「OWAMP対応することのハードウェアパケットTimestamper」
[BRIX] Brix Networks, http://www.brixnet.com/
[果物の糖度の単位]果物の糖度の単位ネットワーク、 http://www.brixnet.com/
[ZIGG] J. H. Ahrens, U. Dieter, "Computer methods for
sampling from the exponential and normal
distributions", Communications of ACM, volume 15,
issue 10, 873-882, 1972.
http://doi.acm.org/10.1145/355604.361593
[ZIGG]J.H.アーレンズ、U.Dieter、「指数の、そして、通常の配からの標本抽出のためのコンピュータ手法」(ACM、第15巻のCommunications)は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、Applied Cryptography、CRC PressのHandbookはアップデート、1997で増刷を改訂しました。
[KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd
edition, 1998.
[クヌース]D.クヌース、コンピュータProgramming、vol.2、3番目の版、1998年のArt。
[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
ラインダールの[RIJN]参照ANSI C Implementation、 http://www.esat.kuleuven.ac.be/~rijmen/ rijndael/rijndaelref.zip
[RIPE] RIPE NCC Test-Traffic Measurements home,
http://www.ripe.net/test-traffic/.
[RIPE]RIPE NCC Test-トラフィックMeasurementsホーム、 http://www.ripe.net/test-traffic/ 。
[SURVEYOR] Surveyor Home Page,
http://www.advanced.org/surveyor/.
[測量士]測量士ホームページ、 http://www.advanced.org/surveyor/ 。
[SURVEYOR-INET] S. Kalidindi and M. Zekauskas, "Surveyor: An
Infrastructure for Network Performance Measurements",
Proceedings of INET'99, June 1999.
http://www.isoc.org/inet99/proceedings/4h/4h_2.htm
[測量士-INET] S.KalidindiとM.Zekauskas、「測量士:」 「ネットワークパフォーマンス測定のためのインフラストラクチャ」、INET'99、6月1999の 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)」RFC1305、1992年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
Shalunov, et al. Standards Track [Page 47] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[47ページ]RFC4656
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、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.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC3546、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.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
Shalunov, et al. Standards Track [Page 48] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[48ページ]RFC4656
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.
/***例用法: 指数(1を意味する)の**無作為の量のストリームを生成してください(初期化の間にチェックする誤りを無視して)。 ** 1以外のいくつかの意地悪なμがある変量が望まれているなら、私たちが説明した演算の規則**に従って、このアルゴリズムの出力**にμを掛けることができます。
** Assume that a 16-octet 'seed' has been initialized ** (as the shared secret in OWAMP, for example) ** unsigned char seed[16];
** 16八重奏の'種子'が初期化している**(例えばOWAMPの共有秘密キーとして)**未署名の炭種子[16]であると仮定してください。
** OWPrand_context next;
** 次のOWPrand_関係。
** (initialize state) ** OWPrand_context_init(&next, seed);
** (状態を初期化します) ** OWPrand_文脈_イニット(次に、種を蒔いてください)。
** (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>
#<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
最初のkはそのようなものです。/*(K--1)、そのQ[k]>1--1/(2^32)。 */#はK12を定義します。
#define BIT31 0x80000000UL /* See if first bit in the lower
32 bits is zero. */
#define MASK32(n) ((n) & 0xFFFFFFFFUL)
#BIT31 0x80000000UL/*を定義してください。低級32ビットの最初のビットがゼロであるかどうか考えてください。 */#はMASK32(n)を定義します。((n)と0xFFFFFFFFUL)
#define EXP2POW32 0x100000000ULL
#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.*/
未署名の炭は*カウンタ(ネットワークバイトオーダー)*/keyInstanceが合わせる[16];/を打ち返します; カウンタを暗号化するために主要な/*。typedef struct OWPrand_文脈、*/未署名の炭のアウト[16]; 暗号化が妨げる/*、*/
Shalunov, et al. Standards Track [Page 49] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の一方向の標準化過程[49ページ]RFC4656
} OWPrand_context;
} OWPrand_文脈。
/*
** 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
};
/、***公式によると、アレイは計算されました: ** ** Q[k]=(ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!) ** ** アルゴリズムS.(以下の値は2^32で掛けられて、最も近い整数に一周した**です。)で、説明されます。 ** これらの正確な値を使用しなければならないので、異なった実現**は同じ系列を作成します。 */静的なu_int64_t Q[K]は/*プレースホルダ--したがって、0、1*/0xB17217F8、0xEEF193F7、0xFD271862、0xFF9D6DD0、0xFFF4CFD0、0xFFFEE819、0xFFFFE7FF、0xFFFFFE2B、0xFFFFFFE0、0xFFFFFFFE、0xFFFFFFFFからインデックスリスト始めを整列させるのと等しいです。
/* this element represents ln2 */ #define LN2 Q[1]
/、*この要素が*/#、が定義するln2を表す、LN2Q[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;
}
/***はu_int64_t番号に無記名の32ビットの整数を変換します。 *_/u int64_t OWPulong2num64、(u_int32_t a)リターン((u_int64_t)1<<32)*a。
/* ** Arithmetic functions on u_int64_t numbers. */
/***演算はu_int64_t番号で機能します。 */
/* ** Addition. */ u_int64_t OWPnum64_add(u_int64_t x, u_int64_t y)
/***添加。 *OWPnum64_が加える/u_int64_t(u_int64_t x、u_int64_t y)
Shalunov, et al. Standards Track [Page 50] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[50ページ]RFC4656
{
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];
/***乗法。 オーバーフローを許容します。 [クヌース]からのAlgorithm 4.3.1.M(p.268)の簡単な実現**。 *_/u int64_t OWPnum64_mul(u_int64_t x、u_int64_t y)、無記名の長いw[4]_(u_int64_t xdec[2]; u int64_t ydec[2])
int i, j;
u_int64_t k, t, ret;
int i、j。 u_int64_t k、tは浸水します。
xdec[0] = MASK32(x);
xdec[1] = MASK32(x>>32);
ydec[0] = MASK32(y);
ydec[1] = MASK32(y>>32);
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; j<4; j++)w[j]=0のために。
for (j = 0; j < 2; j++) {
k = 0;
for (i = 0; ; ) {
t = k + (xdec[i]*ydec[j]) + w[i + j];
w[i + j] = t%EXP2POW32;
k = t/EXP2POW32;
if (++i < 2)
continue;
else {
w[j + 2] = k;
break;
}
}
}
(j=0; j<2; j++)のために(i=0)のためのk=0、tはk+と等しいです。
ret = w[2];
ret <<= 32;
return w[1] + ret;
}
=w[2]を浸水させてください。 <<=32を浸水させてください。 +が浸水させるw[1]を返してください。 }
/*
/*
Shalunov, et al. Standards Track [Page 51] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[51ページ]RFC4656
** 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_文脈_イニット(OWPrand_文脈*次の、そして、無記名の炭*種子)を欠如させてください、int i。
/* Initialize the key */
rijndaelKeyInit(next->key, seed);
/*は主要な*/rijndaelKeyInit(次の>のキー、種子)を初期化します。
/* Initialize the counter with zeros */
memset(next->out, 0, 16);
for (i = 0; i < 16; i++)
next->counter[i] = 0UL;
}
/*がゼロ*/memsetでカウンタを初期設定する、(次の>のアウト、0、16)。 (i=0; i<16; i++)次の>に関しては、カウンタ[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;
/***は、32ビットの一定の無作為の値(u_int64_tの**それほどかなりでない半分では、救われる)を発生して、返します。 この機能道具**はアルゴリズムUnifのU2-U4を踏みます。 *_/u int64_t OWPunif_rand64(OWPrand_文脈*次)、int j; u_int8_t*buf; u_int64_tは=0を浸水させます。
/* step U2 */
u_int8_t i = next->counter[15] & (u_int8_t)3;
if (!i)
rijndaelEncrypt(next->key, next->counter, next->out);
/*ステップU2*/u_int8_t i=次の>カウンタ[15]と(u_int8_t)3。 (i)rijndaelEncrypt(次の>のキー、外の次の>の次の>のカウンタ)であるなら。
/* 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;
/*ステップU3。 AESカウンタモードのためにネットワークバイトオーダーにおける16八重奏の単一数量としてnext.counterを増加してください。 *(j=15 ; j>=0(j))のための/、(+ + 次の>のカウンタ[j])中断。
/* Step U4. Do output. The last 4 bytes of ret now contain
/*ステップU4。 出力します。 ベスト4バイト、浸水、現在、含みます。
Shalunov, et al. Standards Track [Page 52] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[52ページ]RFC4656
the random integer in network byte order */
buf = &next->out[4*i];
for (j=0; j<4; j++) {
ret <<= 8;
ret += *buf++;
}
return ret;
}
ネットワークバイトオーダー*/bufにおける無作為の整数が等しい、次の>のアウト、[4*i]。 (j=0; j<4; j++)に関して<<=8を浸水させてください; + =*buf++を浸水させてください;。リターンは浸水します。 }
/*
** 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;
/***を発生させる、指数、平均1で、逸脱してください。 *_/u int64_t OWPexp_rand64(OWPrand_文脈*次)、k; 無記名の長いi、u_int32_t j=0(u_int64_t U、V、J、tmp)
/* Step S1. Get U and shift */
U = OWPunif_rand64(next);
/*ステップS1。 Uとシフト*/U=OWPunif_rand64(次の)を手に入れてください。
while ((U & BIT31) && (j < 32)) { /* Shift until first 0. */
U <<= 1;
j++;
}
/* Remove the 0 itself. */
U <<= 1;
(U&BIT31)である、(j<32)) /*は. */u<<=1を最初に、0時まで移行させます; j++、/*は0自体を取り除きます。 */U<<=1。
U = MASK32(U); /* Keep only the fractional part. */
J = OWPulong2num64(j);
UはMASK32(U)と等しいです。 /*は断片的な部分だけを保ちます。 */JはOWPulong2num64(j)と等しいです。
/* Step S2. Immediate acceptance? */
if (U < LN2) /* return (j*ln2 + U) */
return OWPnum64_add(OWPnum64_mul(J, LN2), U);
/*ステップS2。 即座の承認? */は(U<LN2)/*リターン(j*ln2+U)*/リターンOWPnum64_であるなら(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;
}
/*ステップS3。 最小にします。 *(k=2; k<K; k++)のための/、(U<Q[k])は壊れます。 VはOWPunif_rand64と等しいです(次の)。 (i=2; i<=k; i++)のためにtmp=OWPunif_rand64(次の)(tmp<V)Vがtmpと等しいなら
/* Step S4. Return (j+V)*ln2 */
/*ステップS4。 リターン(j+V)*ln2*/
Shalunov, et al. Standards Track [Page 53] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[53ページ]RFC4656
return OWPnum64_mul(OWPnum64_add(J, V), LN2);
}
リターンOWPnum64_mul(LN2、OWPnum64_は(J、V)を加えます)。 }
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.
同じ入力と異なった実現で発生するテストスケジュールが同じであることは、重要です。 重要な部分は指数関数的に分配された擬似ランダムの世代が逸脱するということです。 相互運用性について確かめる際に作成者を支援するために、いくつかのテストベクトルを提供します。 それぞれ4つにおいて、16進数、100万指数関数的に分散している64ビットが逸脱するので表されたSIDの与えられた128ビットの値は上で説明されるように発生します。 発生するとき、それらは互いにすべて加えられます。 すべての100万の合計は逸脱します。各SIDのための16進数として、与えます。 実現はちょうどこれらの16進数を生産しなければなりません。 これらの数の変換の検証で秒の遅れの値に支援するために、近似値を与えます(λが=1であると仮定して)。 遅れが以下に与えられたものの近くにある秒に評価する実現SHOULD生産物。
SID = 0x2872979303ab47eeac028dab3829dab2
SUM[1000000] = 0x000f4479bd317381 (1000569.739036 seconds)
SIDは0x2872979303ab47eeac028dab3829dab2合計[1000000]=0x000f4479bd317381と等しいです。(1000569.739036秒)
SID = 0x0102030405060708090a0b0c0d0e0f00
SUM[1000000] = 0x000f433686466a62 (1000246.524512 seconds)
SIDは0x0102030405060708090a0b0c0d0e0f00合計[1000000]=0x000f433686466a62と等しいです。(1000246.524512秒)
SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef
SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds)
SIDは0xdeadbeefdeadbeefdeadbeefdeadbeef合計[1000000]=0x000f416c8884d2d3と等しいです。(999788.533277秒)
SID = 0xfeed0feed1feed2feed3feed4feed5ab
SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds)
SIDは0xfeed0feed1feed2feed3feed4feed5ab合計[1000000]=0x000f3f0b4b416ec8と等しいです。(999179.293967秒)
Shalunov, et al. Standards Track [Page 54] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[54ページ]RFC4656
Authors' Addresses
作者のアドレス
Stanislav Shalunov Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104
アナーバー、Suite300MI スタニスラフShalunov Internet2 1000Oakbrookドライブ、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
アナーバー、Suite300MI ベンジャミンタイテルバウムInternet2 1000Oakbrookドライブ、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
ウィスコンシン-マディソン・マディソン、ウィスコンシン 53706人のAnatolyカープコンピューターサイエンシズ部の大学
EMail: akarp@cs.wisc.edu
メール: akarp@cs.wisc.edu
Jeff W. Boote Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104
アナーバー、Suite300MI ジェフW.Boote Internet2 1000Oakbrookドライブ、48104
EMail: boote@internet2.edu
メール: boote@internet2.edu
Matthew J. Zekauskas Internet2 1000 Oakbrook Drive, Suite 300 Ann Arbor, MI 48104
アナーバー、Suite300MI マシューJ.Zekauskas Internet2 1000Oakbrookドライブ、48104
EMail: matt@internet2.edu
メール: matt@internet2.edu
Shalunov, et al. Standards Track [Page 55] RFC 4656 One-way Active Measurement Protocol September 2006
Shalunov、他 アクティブな測定プロトコル2006年9月の片道の標準化過程[55ページ]RFC4656
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Shalunov, et al. Standards Track [Page 56]
Shalunov、他 標準化過程[56ページ]
一覧
スポンサーリンク
