RFC5357 日本語訳
5357 A Two-Way Active Measurement Protocol (TWAMP). K. Hedayat, R.Krzanowski, A. Morton, K. Yum, J. Babiarz. October 2008. (Format: TXT=61960 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. Hedayat
Request for Comments: 5357 Brix Networks
Category: Standards Track R. Krzanowski
Verizon
A. Morton
AT&T Labs
K. Yum
Juniper Networks
J. Babiarz
Nortel Networks
October 2008
コメントを求めるワーキンググループK.ヘダーヤトの要求をネットワークでつないでください: 5357年の果物の糖度の単位はカテゴリをネットワークでつなぎます: Babiarzノーテルが2008年10月にネットワークでつなぐ標準化過程R.KrzanowskiベライゾンA.モートンAT&T研究室K.おいしい杜松ネットワークJ.
A Two-Way Active Measurement Protocol (TWAMP)
両用アクティブな測定プロトコル(TWAMP)
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances.
RFC4656で指定されたOne-道のActive Measurementプロトコル(OWAMP)はネットワークデバイスの間で一方向測定基準を測定するのに一般的なプロトコルを提供します。 2つのネットワーク要素の間の両方の方向に一方向測定基準を測定するのに2方向にOWAMPを使用できます。 しかしながら、それは往復の、または、両用の測定値に対応しません。 このメモは両用の、または、往復の測定能力を加えるOWAMPに基づくTwo-道のActive Measurementプロトコル(TWAMP)を指定します。 通常、TWAMP測定アーキテクチャは特定の役割で2人のホストから成ります、そして、これはいくつかのプロトコル簡素化を考慮します、それをいくつかの事情における魅力的な代替手段にして。
Hedayat, et al. Standards Track [Page 1] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[1ページ]RFC5357ツーウェイ
Table of Contents
目次
1. Introduction ....................................................2
1.1. Relationship of Test and Control Protocols .................3
1.2. Logical Model ..............................................3
1.3. Pronunciation Guide ........................................4
2. Protocol Overview ...............................................5
3. TWAMP-Control ...................................................6
3.1. Connection Setup ...........................................6
3.2. Integrity Protection .......................................7
3.3. Values of the Accept Field .................................7
3.4. TWAMP-Control Commands .....................................7
3.5. Creating Test Sessions .....................................8
3.6. Send Schedules ............................................10
3.7. Starting Test Sessions ....................................10
3.8. Stop-Sessions .............................................10
3.9. Fetch-Session .............................................12
4. TWAMP-Test .....................................................12
4.1. Sender Behavior ...........................................12
4.1.1. Packet Timings .....................................12
4.1.2. Packet Format and Content ..........................12
4.2. Reflector Behavior ........................................13
4.2.1. TWAMP-Test Packet Format and Content ...............14
5. Implementers' Guide ............................................20
6. Security Considerations ........................................20
7. Acknowledgements ...............................................21
8. IANA Considerations ............................................21
8.1. Registry Specification ....................................22
8.2. Registry Management .......................................22
8.3. Experimental Numbers ......................................22
8.4. Initial Registry Contents .................................22
9. Internationalization Considerations ............................22
Appendix I - TWAMP Light (Informative) ............................23
Normative References ..............................................24
Informative References ............................................24
1. 序論…2 1.1. テストと制御プロトコルの関係…3 1.2. 論理的なモデル…3 1.3. 発音ガイド…4 2. 概要について議定書の中で述べてください…5 3. TWAMP-コントロール…6 3.1. 接続セットアップ…6 3.2. 保全保護…7 3.3. 値、野原を受け入れてください…7 3.4. TWAMP-コントロールは命令します…7 3.5. テストセッションを作成します…8 3.6. スケジュールを送ってください…10 3.7. テストセッションを始めます…10 3.8. 停止セッション…10 3.9. フェッチセッション…12 4. TWAMP-テスト…12 4.1. 送付者の振舞い…12 4.1.1. パケットタイミング…12 4.1.2. パケット・フォーマットと内容…12 4.2. 反射鏡の振舞い…13 4.2.1. パケット・フォーマットと内容をTWAMPテストしてください…14 5. Implementersのガイド…20 6. セキュリティ問題…20 7. 承認…21 8. IANA問題…21 8.1. 登録仕様…22 8.2. 登録管理…22 8.3. 実験数…22 8.4. 登録コンテンツに頭文字をつけてください…22 9. 国際化問題…22 付録I--TWAMPは火が付きます(有益な)…23 標準の参照…24 有益な参照…24
1. Introduction
1. 序論
The Internet Engineering Task Force (IETF) has completed a Proposed Standard for the round-trip delay [RFC2681] metric. The IETF has also completed a protocol for the control and collection of one-way measurements, the One-way Active Measurement Protocol (OWAMP) [RFC4656]. However, OWAMP does not accommodate round-trip or two-way measurements.
インターネット・エンジニアリング・タスク・フォース(IETF)は往復の遅れ[RFC2681]のためにメートル法でProposed Standardを完成しました。 また、IETFは一方向測定値One-道のActive Measurementプロトコル(OWAMP)[RFC4656]のコントロールと収集のためにプロトコルを完成しました。 しかしながら、OWAMPは往復の、または、両用の測定値に対応しません。
Two-way measurements are common in IP networks, primarily because synchronization between local and remote clocks is unnecessary for round-trip delay, and measurement support at the remote end may be
両用測定値はIPネットワークで一般的です、往復の遅れには、主として地方の、そして、リモートな時計の間の同期が不要であるのでリモートエンドにおける測定サポートはそうです。
Hedayat, et al. Standards Track [Page 2] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[2ページ]RFC5357ツーウェイ
limited to a simple echo function. However, the most common facility for round-trip measurements is the ICMP Echo Request/Reply (used by the ping tool), and issues with this method are documented in Section 2.6 of [RFC2681]. This memo specifies the Two-Way Active Measurement Protocol, or TWAMP. TWAMP uses the methodology and architecture of OWAMP [RFC4656] to define an open protocol for measurement of two-way or round-trip metrics (henceforth in this document the term two-way also signifies round-trip), in addition to the one-way metrics of OWAMP. TWAMP employs time stamps applied at the echo destination (reflector) to enable greater accuracy (processing delays can be accounted for). The TWAMP measurement architecture is usually comprised of only two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative to OWAMP in some circumstances.
簡単なエコー機能に制限されています。 しかしながら、往復の測定値のための最も一般的な施設はICMP Echo Request/回答(ピングツールで、使用される)です、そして、このメソッドの問題は[RFC2681]のセクション2.6に記録されます。 このメモはTwo-道のActive Measurementプロトコル、またはTWAMPを指定します。 TWAMPが両用の、または、往復の測定基準の測定のためにオープン・プロトコルを定義するのにOWAMP[RFC4656]の方法論とアーキテクチャを使用する、(また、今後は本書ではツーウェイという用語が意味する、往復、)、OWAMPの一方向測定基準に加えて。 TWAMPは、より大きい精度を可能にするのにエコーの目的地(反射鏡)で適用されたタイムスタンプを使います(処理遅れを説明できます)。 通常、TWAMP測定アーキテクチャは特定の役割で2人のホストだけから成ります、そして、これはいくつかのプロトコル簡素化を考慮します、いくつかの事情でそれをOWAMPへの魅力的な代替手段にして。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.1. Relationship of Test and Control Protocols
1.1. テストと制御プロトコルの関係
Similar to OWAMP [RFC4656], TWAMP consists of two inter-related protocols: TWAMP-Control and TWAMP-Test. The relationship of these protocols is as defined in Section 1.1 of OWAMP [RFC4656]. TWAMP- Control is used to initiate, start, and stop test sessions, whereas TWAMP-Test is used to exchange test packets between two TWAMP entities.
OWAMP[RFC4656]と同様であることで、TWAMPは2つの相互関連するプロトコルから成ります: TWAMP-コントロールとTWAMP-テスト。 これらのプロトコルの関係がOWAMP[RFC4656]のセクション1.1で定義されるようにあります。 TWAMPコントロールは開始、始め、および停止テストセッションまで使用されますが、TWAMP-テストは、2つのTWAMP実体の間でテストパケットを交換するのに使用されます。
1.2. Logical Model
1.2. 論理的なモデル
The role and definition of the logical entities are as defined in Section 1.2 of OWAMP [RFC4656] with the following exceptions:
論理的な実体の役割と定義が以下の例外でOWAMPのセクション1.2[RFC4656]で定義されるようにあります:
- The Session-Receiver is called the Session-Reflector in the TWAMP
architecture. The Session-Reflector has the capability to create
and send a measurement packet when it receives a measurement
packet. Unlike the Session-Receiver, the Session-Reflector does
not collect any packet information.
- Session-受信機はTWAMPアーキテクチャでSession-反射鏡と呼ばれます。 Session-反射鏡には、それが測定パケットを受けるとき、測定パケットを作成して、送る能力があります。 Session-受信機と異なって、Session-反射鏡は少しのパケット情報も集めません。
- The Server is an end system that manages one or more TWAMP
sessions, and is capable of configuring per-session state in the
endpoints. However, a Server associated with a Session-Reflector
would not have the capability to return the results of a test
session, and this is a difference from OWAMP.
- Serverは1つ以上のTWAMPセッションを管理するエンドシステムであり、終点の1セッションあたりの状態を構成できます。 しかしながら、Session-反射鏡に関連しているServerには、テストセッションの結果を返す能力がないでしょう、そして、これはOWAMPからの違いです。
Hedayat, et al. Standards Track [Page 3] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[3ページ]RFC5357ツーウェイ
- The Fetch-Client entity does not exist in the TWAMP architecture,
as the Session-Reflector does not collect any packet information
to be fetched. Consequently, there is no need for the Fetch-
Client.
- Fetch-クライアント実体はTWAMPアーキテクチャで存在していません、Session-反射鏡がとって来られる少しのパケット情報も集めないとき。 その結果、Fetchクライアントの必要は全くありません。
An example of possible relationship scenarios between these roles is presented below. In this example, different logical roles are played on different hosts. Unlabeled links in the figure are unspecified by this document and may be proprietary protocols.
これらの役割の間の可能な関係シナリオに関する例は以下に提示されます。 この例では、異なった論理的な役割は異なったホストの上で果たされます。 図のラベルされていないリンクは、このドキュメントで不特定であり、固有のプロトコルであるかもしれません。
+----------------+ +-------------------+
| Session-Sender |<-TWAMP-Test-->| Session-Reflector |
+----------------+ +-------------------+
^ ^
| |
| |
| |
| +----------------+<----------------+
| | Server |
| +----------------+
| ^
| |
| TWAMP-Control
| |
v v
+----------------+
| Control-Client |
+----------------+
+----------------+ +-------------------+ | セッション送付者| <、-TWAMP-テスト-->| セッション反射鏡| +----------------+ +-------------------+ ^ ^ | | | | | | | +----------------+ <。----------------+ | | サーバ| | +----------------+ | ^ | | | TWAMP-コントロール| | v対+----------------+ | コントロールクライアント| +----------------+
As in OWAMP [RFC4656], different logical roles can be played by the same host. For example, in the figure above, there could actually be two hosts: one playing the roles of Control-Client and Session- Sender, and the other playing the roles of Server and Session- Reflector. This example is shown below.
OWAMP[RFC4656]のように、同じホストは異なった論理的な役割を果たすことができます。 例えば、図には、2人のホストが実際に上に、いるかもしれません: Control-クライアントとSession送付者の役割を果たす1つ、およびServerとSession反射鏡の役割を果たす他。 この例は以下に示されます。
+-----------------+ +-------------------+
| Control-Client |<--TWAMP-Control-->| Server |
| | | |
| Session-Sender |<--TWAMP-Test----->| Session-Reflector |
+-----------------+ +-------------------+
+-----------------+ +-------------------+ | コントロールクライアント| <--TWAMP-コントロール-->| サーバ| | | | | | セッション送付者| <--TWAMP-テスト----->| セッション反射鏡| +-----------------+ +-------------------+
1.3. Pronunciation Guide
1.3. 発音ガイド
The acronym OWAMP is usually pronounced in two syllables, Oh-wamp.
通常、頭文字語OWAMPが2つの音節で発音される、おお、-wamp。
The acronym TWAMP is also pronounced in two syllables, Tee-wamp.
Tee-wamp、また、頭文字語TWAMPは2つの音節で発音されます。
Hedayat, et al. Standards Track [Page 4] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[4ページ]RFC5357ツーウェイ
2. Protocol Overview
2. プロトコル概要
The Two-Way Active Measurement Protocol is an open protocol for measurement of two-way metrics. It is based on OWAMP [RFC4656] and adheres to OWAMP's overall architecture and design. The TWAMP- Control and TWAMP-Test protocols accomplish their testing tasks as outlined below:
Two-道のActive Measurementプロトコルは両用測定基準の測定のためのオープン・プロトコルです。 それは、OWAMP[RFC4656]に基づいていて、OWAMPの総合的なアーキテクチャとデザインを固く守ります。 TWAMPコントロールとTWAMP-テストプロトコルは以下に概説されているようにそれらのテストタスクを達成します:
- The Control-Client initiates a TCP connection on TWAMP's well-
known port, and the Server (its role now established) responds
with its Greeting message, indicating the security/integrity
mode(s) it is willing to support.
- Control-クライアントはTWAMPのよく知られているポートの上でTCP接続を開始します、そして、Server(現在確立されている役割)はGreetingメッセージで応じます、それがサポートしても構わないと思っているセキュリティ/保全モードを示して。
- The Control-Client responds with the chosen mode of communication
and information supporting integrity protection and encryption, if
the mode requires them. The Server responds to accept the mode
and give its start time. This completes the control-connection
setup.
- コミュニケーションと情報の選ばれたモードが、保全が保護と暗号化であるとサポートしていて、Control-クライアントは応じます、モードがそれらを必要とするなら。 Serverは、モードを受け入れて、開始時刻を与えるために応じます。 これはコントロール接続設定を終了します。
- The Control-Client requests (and describes) a test session with a
unique TWAMP-Control message. The Server responds with its
acceptance and supporting information. More than one test session
may be requested with additional messages.
- Control-クライアントが要求する、(説明、)、ユニークなTWAMP-コントロールメッセージとのテストセッション。 Serverは承認と情報をサポートするのに応じます。 1つ以上のテストセッションが追加メッセージで要求されているかもしれません。
- The Control-Client initiates all requested testing with a Start-
Sessions message, and the Server acknowledges.
- すべてがStartセッションメッセージでテストしながら要求して、Serverが承認するControl-クライアント開始。
- The Session-Sender and the Session-Reflector exchange test packets
according to the TWAMP-Test protocol for each active session.
- TWAMP-テストに従ったSession-送付者とSession-反射鏡交換テストパケットはそれぞれの活発なセッションの間、議定書を作ります。
- When appropriate, the Control-Client sends a message to stop all
test sessions.
- 適切であるときに、Control-クライアントはすべてのテストセッションに止まるメッセージを送ります。
There are two recognized extension mechanisms in the TWAMP Protocol.
TWAMPプロトコルには2つの認識された拡張機能があります。
1) The Modes field is used to establish the communication options
during TWAMP-Control Connection Setup.
1) Modes分野は、TWAMP-コントロールConnection Setupの間、コミュニケーションオプションを証明するのに使用されます。
2) The TWAMP-Control Command Number is another intended extension
mechanism, allowing additional commands to be defined in the
future.
2) TWAMP-コントロールCommand Numberは将来定義されるべき追加コマンドを許容する別の意図している拡張機能です。
The TWAMP-Control protocol resolves different capability levels between the Control-Client and Server.
TWAMP-制御プロトコルはControl-クライアントとServerの間の異なった能力レベルを決議します。
All multi-octet quantities defined in this document are represented as unsigned integers in network byte order, unless specified otherwise.
別の方法で指定されない場合、本書では定義されたすべてのマルチ八重奏量がネットワークバイトオーダーにおける符号のない整数として表されます。
Hedayat, et al. Standards Track [Page 5] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[5ページ]RFC5357ツーウェイ
Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set to zero by senders and MUST be ignored by receivers.
このメモ中では、MBZ(必須Be Zero)であるとマークされたビットを、送付者がゼロに設定しなければならなくて、受信機で無視しなければなりません。
3. TWAMP-Control
3. TWAMP-コントロール
TWAMP-Control is a derivative of the OWAMP-Control for two-way measurements. All TWAMP-Control messages are similar in format and follow similar guidelines to those defined in Section 3 of OWAMP [RFC4656] with the exceptions outlined in the following sections. One such exception is the Fetch-Session command, which is not used in TWAMP.
TWAMP-コントロールは両用測定値のためのOWAMP-コントロールの派生物です。 すべてのTWAMP-コントロールメッセージが、形式において同様であり、例外が以下のセクションで概説されている状態でOWAMP[RFC4656]のセクション3で定義されたものに同様のガイドラインに従います。 そのような例外の1つはFetch-セッション命令です。(その命令はTWAMPで使用されません)。
3.1. Connection Setup
3.1. 接続設定
Connection establishment of TWAMP follows the same procedure defined in Section 3.1 of OWAMP [RFC4656]. The Modes field is a recognized extension mechanism in TWAMP, and the current mode values are identical to those used in OWAMP. The only exception is the well- known port number for TWAMP-Control. A Client opens a TCP connection to the Server on well-known port 862. The host that initiates the TCP connection takes the roles of Control-Client and (in the two-host implementation) the Session-Sender. The host that acknowledges the TCP connection accepts the roles of Server and (in the two-host implementation) the Session-Reflector.
TWAMPのコネクション確立はOWAMP[RFC4656]のセクション3.1で定義された同じ手順に従います。 Modes分野はTWAMPの認識された拡張機能です、そして、現在の最頻値はOWAMPで使用されるものと同じです。 唯一の例外がTWAMP-コントロールのためのよく知られているポートナンバーです。 Clientはウェルノウンポート862のServerにTCP接続を開きます。 TCP接続を開始するホストはControl-クライアントと(2ホスト導入における)Session-送付者の役割を果たします。 TCP接続を承諾するホストはServerと(2ホスト導入における)Session-反射鏡の役割を受け入れます。
The Control-Client MAY set a desired code point in the Diffserv Code Point (DSCP) field in the IP header for ALL packets of a specific control connection. The Server SHOULD use the DSCP of the Control- Client's TCP SYN in ALL subsequent packets on that connection (avoiding any ambiguity in case of re-marking).
Control-クライアントは特定のコントロール接続のすべてのパケットのためにIPヘッダーのDiffserv Code Point(DSCP)分野に必要なコード・ポイントをはめ込むかもしれません。 Server SHOULDはその接続でのすべてのその後のパケットでControlクライアントのTCP SYNのDSCPを使用します(異状の場合にどんなあいまいさも避けて)。
The possibility exists for Control-Client failure after TWAMP- Control connection establishment, or the path between the Control- Client and Server may fail while a connection is in progress. The Server MAY discontinue any established control connection when no packet associated with that connection has been received within SERVWAIT seconds. The Server SHALL suspend monitoring control connection activity after receiving a Start-Sessions command, and SHALL resume after receiving a Stop-Sessions command (IF the SERVWAIT option is supported). Note that the REFWAIT timeout (described below) covers failures during test sessions, and if REFWAIT expires on ALL test sessions initiated by a TWAMP-Control connection, then the SERVWAIT monitoring SHALL resume (as though a Stop-Sessions command had been received). An implementation that supports the SERVWAIT timeout SHOULD also implement the REFWAIT timeout. The default value of SERVWAIT SHALL be 900 seconds, and this waiting time MAY be configurable. This timeout allows the Server to free up resources in case of failure.
Control-クライアント失敗によって、TWAMPがコネクション確立を制御した後に、可能性が存在しているか、または接続が進行している間、ControlクライアントとServerの間の経路は失敗するかもしれません。 SERVWAIT秒以内にその接続に関連しているどんなパケットも受け取っていないとき、Serverはどんな確立したコントロール接続も中止するかもしれません。 Start-セッション命令を受け取った後にServer SHALLはモニターしているコントロール接続活動を中断させます、そして、Stop-セッション命令を受け取った後に、SHALLは再開します(SERVWAITオプションがサポートされるなら)。 REFWAITタイムアウト(以下で、説明される)がテストセッションの間失敗をカバーすることに注意してください。そうすれば、REFWAITがTWAMP-コントロール接続によって開始されたすべてのテストセッションのときに期限が切れるなら、SERVWAITのモニターしているSHALLは再開します(まるでStop-セッション命令を受け取ったかのように)。 またSHOULDが実装するSERVWAITタイムアウトにREFWAITタイムアウトをサポートする実装。 デフォルト値、SERVWAIT SHALLでは900秒になってください、そして、この待ち時間は構成可能であってもよいです。 このタイムアウトで、Serverは失敗の場合にリソースを開けることができます。
Hedayat, et al. Standards Track [Page 6] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[6ページ]RFC5357ツーウェイ
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 shared secret is a passphrase. To maximize passphrase interoperability, the passphrase character set MUST be encoded using Appendix B of [RFC5198] (the ASCII Network Virtual Terminal Definition). It MUST not contain newlines (any combination of Carriage-Return (CR) and/or Line-Feed (LF) characters), and control characters SHOULD be avoided.
ServerとClientの両方がKeyIDsから共有秘密キーまで同じマッピングを使用します。 適切な秘密鍵を選ぶために1Clientとのセッション、用途KeyIDsを行うように準備されるServer。 Clientには、異なったServersのための異なった秘密鍵が通常あるでしょう。 共有秘密キーはパスフレーズです。 パスフレーズ相互運用性を最大にするために、[RFC5198](ASCII Network Virtual Terminal Definition)のAppendix Bを使用して、パスフレーズ文字集合をコード化しなければなりません。 それはニューライン(Carriage-リターン(CR)、そして/または、ラインフィード(LF)キャラクタのどんな組み合わせ)、および制御文字SHOULDを含んではいけません。避けられます。
3.2. Integrity Protection
3.2. 保全保護
Integrity protection of TWAMP follows the same procedure defined in Section 3.2 of OWAMP [RFC4656]. As in OWAMP, each HMAC (Hashed Message Authentication Code) sent covers everything sent in a given direction between the previous HMAC (but not including it) and the start of the new HMAC. This way, once encryption is set up, each bit of the TWAMP-Control connection is authenticated by an HMAC exactly once.
TWAMPの保全保護はOWAMP[RFC4656]のセクション3.2で定義された同じ手順に従います。 OWAMPのように、各HMAC(メッセージ立証コードを論じ尽くす)は前のHMAC(それを含んでいませんが)と新しいHMACの始まりの間の与えられた方向に送られたすべてをカバーに送りました。 このように、暗号化がいったんセットアップされると、TWAMP-コントロール接続の各ビットはまさにHMACによって一度認証されます。
Note that the Server-Start message (sent by a Server during the initial control-connection exchanges) does not terminate with an HMAC field. Therefore, the HMAC in the first Accept-Session message also covers the Server-Start message and includes the Start-Time field in the HMAC calculation.
Server-開始メッセージ(Serverで、初期のコントロール接続交換の間、発信する)がHMAC分野で終わらないことに注意してください。 したがって、最初のAccept-セッションメッセージのHMACはまた、Server-開始メッセージをカバーしていて、HMAC計算にStart-時間分野を含んでいます。
Also, in authenticated and encrypted modes, the HMAC in TWAMP-Control packets is encrypted.
また、認証されて暗号化されたモードで、TWAMP-コントロールパケットのHMACも暗号化されています。
3.3. Values of the Accept Field
3.3. 値、野原を受け入れてください。
Accept values used in TWAMP are the same as the values defined in Section 3.3 of OWAMP [RFC4656].
受け入れてください。TWAMPで使用される値は値がOWAMPのセクション3.3で[RFC4656]を定義したのと同じです。
3.4. TWAMP-Control Commands
3.4. TWAMP-制御コマンド
TWAMP-Control commands conform to the rules defined in Section 3.4 of OWAMP [RFC4656].
TWAMP-制御コマンドはOWAMP[RFC4656]のセクション3.4で定義された規則に従います。
The following commands are available for the Control-Client: Request-TW-Session, Start-Sessions, and Stop-Sessions. The Server can send specific messages in response to the commands it receives (as described in the sections that follow).
以下のコマンドはControl-クライアントに利用可能です: 要求TWセッション、スタートセッション、および停止セッション。 Serverはそれが受け取るコマンドに対応して特定のメッセージを送ることができます(従うセクションで説明されるように)。
Note that the OWAMP Request-Session command is replaced by the TWAMP Request-TW-Session command, and the Fetch-Session command does not appear in TWAMP.
OWAMP Request-セッション命令をTWAMP Request-TW-セッション命令に取り替えて、Fetch-セッション命令がTWAMPに現れないことに注意してください。
Hedayat, et al. Standards Track [Page 7] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[7ページ]RFC5357ツーウェイ
3.5. Creating Test Sessions
3.5. テストセッションを作成します。
Test session creation follows the same procedure as defined in Section 3.5 of OWAMP [RFC4656]. The Request-TW-Session command is based on the OWAMP Request-Session command, and uses the message format as described in Section 3.5 of OWAMP, but without the Schedule Slot Descriptions field(s) and uses only one HMAC. The description of the Request-TW-Session format follows.
テストセッション作成はOWAMP[RFC4656]のセクション3.5で定義されるのと同じ手順に従います。 Request-TW-セッション命令は、OWAMP Request-セッション命令に基づいていて、OWAMPのセクション3.5で説明されますが、Schedule Slot記述分野なしでメッセージ・フォーマットを使用して、1HMACだけを使用します。 Request-TW-セッション形式の記述は続きます。
In TWAMP, the first octet is referred to as the Command Number, and the Command Number is a recognized extension mechanism. Readers are encouraged to consult the TWAMP-Control Command Number registry to determine if there have been additional values assigned.
TWAMPでは、最初の八重奏はCommand Numberと呼ばれます、そして、Command Numberは認識された拡張機能です。 読者が割り当てられた加算値があったかどうか決定するためにTWAMP-コントロールCommand Number登録に相談するよう奨励されます。
The Command Number value of 5 indicates a Request-TW-Session command, and the Server MUST interpret this command as a request for a two-way test session using the TWAMP-Test protocol.
5のCommand Number値はRequest-TW-セッション命令を示します、そして、TWAMP-テストプロトコルを使用して、Serverは両用テストセッションを求める要求としてこのコマンドを解釈しなければなりません。
If a TWAMP Server receives an unexpected Command Number, it MUST respond with the Accept field set to 3 (meaning "Some aspect of request is not supported") in the Accept-Session message. Command Numbers that are Forbidden (and possibly numbers that are Reserved) are unexpected.
TWAMP Serverが予期していなかったCommand Numberを受けるなら、それはAccept-セッションメッセージでAccept分野セットで3まで応じなければなりません(「要求の何らかの局面はサポートされません」と意味します)。 Forbidden(そして、ことによるとReservedである数)が予期していないということである民数記を命令してください。
In OWAMP, the Conf-Sender field is set to 1 when the Request-Session message describes a task where the Server will configure a one-way test packet sender. Likewise, the Conf-Receiver field is set to 1 when the message describes the configuration for a Session-Receiver. In TWAMP, both endpoints send and receive test packets, with the Session-Sender first sending and then receiving test packets, complimented by the Session-Reflector first receiving and then sending.
OWAMPでは、Request-セッションメッセージがServerが一方向テストパケット送付者を構成するタスクについて説明すると、Conf-送付者分野は1に設定されます。 同様に、メッセージがSession-Receiverのために構成について説明すると、Conf-あて先欄は1に設定されます。両方の終点は、TWAMPでは、テストパケットを送って、受けます、最初に、テストパケットを送って、次に、受けて、最初に、受信がSession-反射鏡によって賞賛されて、次に、発信が賞賛されるSession-送付者で。
Both the Conf-Sender field and Conf-Receiver field MUST be set to 0 since the Session-Reflector will both receive and send packets, and the roles are established according to which host initiates the TCP connection for control. The Server MUST interpret any non-zero value as an improperly formatted command, and MUST respond with the Accept field set to 3 (meaning "Some aspect of request is not supported") in the Accept-Session message.
Session-反射鏡がともにパケットを受けて、送るので、Conf-送付者分野とConf-あて先欄の両方を0に設定しなければなりません、そして、どのホストがコントロールのためのTCP接続を開始するかに従って、役割は確立されます。 Serverは不適切にフォーマットされたコマンドとしてどんな非ゼロ値も解釈しなければならなくて、Accept-セッションメッセージでAccept分野セットで3まで応じなければなりません(「要求の何らかの局面はサポートされません」と意味します)。
The Session-Reflector in TWAMP does not process incoming test packets for performance metrics and consequently does not need to know the number of incoming packets and their timing schedule. Consequently the Number of Scheduled Slots and Number of Packets MUST be set to 0.
TWAMPのSession-反射鏡は、性能測定基準のための入って来るテストパケットを処理しないで、その結果、入って来るパケットの数とそれらのタイミングスケジュールを知る必要はありません。 その結果、Scheduled SlotsのNumberとPacketsのNumberは0に用意ができなければなりません。
The Sender Port is the UDP port from which TWAMP-Test packets will be sent and the port to which TWAMP-Test packets will be sent by the
Sender PortはTWAMP-テストパケットが送られるUDPポートとTWAMP-テストパケットによって発信されるポートです。
Hedayat, et al. Standards Track [Page 8] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[8ページ]RFC5357ツーウェイ
Session-Reflector (the Session-Sender will use the same UDP port to send and receive packets). The Receiver Port is the desired UDP port to which TWAMP-Test packets will be sent by the Session-Sender (the port where the Session-Reflector is asked to receive test packets). The Receiver Port is also the UDP port from which TWAMP-Test packets will be sent by the Session-Reflector (the Session-Reflector will use the same UDP port to send and receive packets).
セッション反射鏡(Session-送付者はパケットを送って、受けるのに同じUDPポートを使用するでしょう)。 Receiver PortはTWAMP-テストパケットがSession-送付者(Session-反射鏡がテストパケットを受けるように頼まれるポート)によって送られる必要なUDPポートです。 また、Receiver PortはTWAMP-テストパケットがSession-反射鏡によって送られるUDPポート(Session-反射鏡はパケットを送って、受けるのに同じUDPポートを使用する)です。
The Sender Address and Receiver Address fields contain, respectively, the sender and receiver addresses of the endpoints of the Internet path over which a TWAMP-Test session is requested. They MAY be set to 0, in which case the IP addresses used for the Control-Client to Server TWAMP-Control message exchange MUST be used in the test packets.
Sender AddressとReceiver Address分野はそれぞれTWAMP-テストセッションが要求されているインターネット経路の終点の送付者と受信機アドレスを含んでいます。 それらは0に設定されるかもしれません、その場合、テストパケットでControl-クライアントにServer TWAMP-コントロール交換処理に使用されるIPアドレスを使用しなければなりません。
The Session Identifier (SID) is as defined in OWAMP [RFC4656]. Since the SID is always generated by the receiving side, the Server determines the SID, and the SID in the Request-TW-Session message MUST be set to 0.
Session Identifier(SID)がOWAMP[RFC4656]で定義されるようにあります。 SIDがいつも受信側によって生成されるので、ServerはSIDを決定します、そして、Request-TW-セッションメッセージのSIDは0に用意ができなければなりません。
The Start Time is as defined in OWAMP [RFC4656].
Start TimeがOWAMP[RFC4656]で定義されるようにあります。
The Timeout is interpreted differently from the definition in OWAMP [RFC4656]. In TWAMP, Timeout is the interval that the Session- Reflector MUST wait after receiving a Stop-Sessions message. In case there are test packets still in transit, the Session-Reflector MUST reflect them if they arrive within the Timeout interval following the reception of the Stop-Sessions message. The Session-Reflector MUST NOT reflect packets that are received beyond the timeout.
TimeoutはOWAMP[RFC4656]との定義と異なって解釈されます。 TWAMPでは、TimeoutはStop-セッションメッセージを受け取った後にSession反射鏡が待たなければならない間隔です。 まだトランジットにはテストパケットがあるといけないので、Stop-セッションメッセージのレセプションに続いて、Timeout間隔中に到着するなら、Session-反射鏡はそれらを反映しなければなりません。 Session-反射鏡はタイムアウトに受け取られるパケットを反映してはいけません。
Type-P descriptor is as defined in OWAMP [RFC4656]. The only capability of this field is to set the Differentiated Services Code Point (DSCP) as defined in [RFC2474]. The same value of DSCP MUST be used in test packets reflected by the Session-Reflector.
Pをタイプしている記述子がOWAMP[RFC4656]で定義されるようにあります。 この分野の唯一の能力は[RFC2474]で定義されるようにDifferentiated Services Code Point(DSCP)を設定することです。 同じ値、DSCP MUSTでは、Session-反射鏡によって反映されたテストパケットで使用されてください。
Since there are no Schedule Slot Descriptions, the Request-TW-Session message is completed by MBZ (Must Be Zero) and HMAC fields. This completes one logical message, referred to as the Request-TW-Session command.
Schedule Slot記述が全くないので、Request-TW-セッションメッセージはMBZ(必須Be Zero)とHMAC分野で完成します。 これはRequest-TW-セッション命令と呼ばれた1つの論理メッセージを完成します。
The Session-Reflector MUST respond to each Request-TW-Session command with an Accept-Session message as defined in OWAMP [RFC4656]. When the Accept field = 0, the Port field confirms (repeats) the port to which TWAMP-Test packets are sent by the Session-Sender toward the Session-Reflector. In other words, the Port field indicates the port number where the Session-Reflector expects to receive packets from the Session-Sender.
Session-反射鏡は、各Request-TW-セッションのときにOWAMP[RFC4656]で定義されるようにAccept-セッションメッセージで命令するために反応しなければなりません。 Acceptが=0をさばくとき、Port分野はTWAMP-テストパケットがSession-送付者によって送られるポートをSession-反射鏡に向かって確認します(繰り返します)。 言い換えれば、Session-反射鏡が、Session-送付者からパケットを受けると予想するところでPort分野はポートナンバーを示します。
Hedayat, et al. Standards Track [Page 9] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[9ページ]RFC5357ツーウェイ
When the requested Receiver Port is not available (e.g., port in use), the Server at the Session-Reflector MAY suggest an alternate and available port for this session in the Port field. The Session- Sender either accepts the alternate port, or composes a new Session- Request message with suitable parameters. Otherwise, the Server at the Control-Client uses the Accept field to convey other forms of session rejection or failure and MUST NOT suggest an alternate port; in this case, the Port field MUST be set to zero.
要求されたReceiver Portが利用可能でないときに(例えば、使用中のポート)、Session-反射鏡のServerはこのセッションのためにPort分野で代替の利用可能なポートを勧めるかもしれません。 Session送付者は、代替のポートを受け入れるか、または適当なパラメタで新しいSession要求メッセージを構成します。 さもなければ、Control-クライアントのServerは他のフォームのセッション拒絶か失敗を伝えるのにAccept分野を使用して、代替のポートを勧めてはいけません。 この場合、Port分野をゼロに設定しなければなりません。
3.6. Send Schedules
3.6. スケジュールを送ってください。
The send schedule for test packets defined in Section 3.6 of OWAMP [RFC4656] is not used in TWAMP. The Control-Client and Session- Sender MAY autonomously decide the send schedule. The Session- Reflector SHOULD return each test packet to the Session-Sender as quickly as possible.
パケットがOWAMP[RFC4656]のセクション3.6で定義したテストがTWAMPで使用されないので、スケジュールを送ってください。 Control-クライアントとSession送付者が自主的に決めるかもしれない、スケジュールを送ってください。 Session反射鏡SHOULDはできるだけはやくそれぞれのテストパケットをSession-送付者に返します。
3.7. Starting Test Sessions
3.7. テストセッションを始めます。
The procedure and guidelines for starting test sessions is the same as defined in Section 3.7 of OWAMP [RFC4656].
テストセッションを始めるための手順とガイドラインはOWAMP[RFC4656]のセクション3.7で定義されるのと同じです。
3.8. Stop-Sessions
3.8. 停止セッション
The procedure and guidelines for stopping test sessions is similar to that defined in Section 3.8 of OWAMP [RFC4656]. The Stop-Sessions command can only be issued by the Control-Client. The message MUST NOT contain any session description records or skip ranges. The message is terminated with a single block HMAC to complete the Stop- Sessions command. Since the TWAMP Stop-Sessions command does not convey SIDs, it applies to all sessions previously requested and started with a Start-Sessions command.
停止テストセッションのための手順とガイドラインはOWAMP[RFC4656]のセクション3.8で定義されたそれと同様です。 Control-クライアントはStop-セッション命令を発行できるだけです。 メッセージは、どんなセッション記述記録も含んではいけませんし、また範囲をスキップしてはいけません。 メッセージは、Stopセッション命令を完成するために独身のブロックHMACと共に終えられます。 TWAMP Stop-セッション命令がSIDsを運ばないので、それはセッションが以前にStart-セッション命令から要求して、始めたすべてに適用されます。
Hedayat, et al. Standards Track [Page 10] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[10ページ]RFC5357ツーウェイ
Thus, the TWAMP Stop-Sessions command is constructed as follows:
したがって、TWAMP Stop-セッション命令は以下の通り構成されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | Accept | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sessions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 受け入れてください。| MBZ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セッションの数| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ(8つの八重奏)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC(16の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Above, the Command Number in the first octet (3) indicates that this is the Stop-Sessions command.
上で、最初の八重奏(3)におけるCommand Numberは、これが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 of [RFC4656], "Values of the Accept Field".
非ゼロAccept値はある種の失敗を示します。 どんな値も正常で(ことによると時期尚早)の完成を示しません。 利用可能なAccept値に関する完全リストが[RFC4656]のセクション3.3で説明される、「値、野原を受け入れてください、」
If Accept has a non-zero value, results of all TWAMP-Test sessions spawned by this TWAMP-Control session SHOULD be considered invalid. If the Accept-Session message was not transmitted at all (for whatever reason, including failure of the TCP connection used for TWAMP-Control), the results of all TWAMP-Test sessions spawned by this TWAMP-Control session MAY be considered invalid.
Acceptに非ゼロ値があるなら、無効の状態で考えられて、すべてのTWAMP-テストセッションの結果はこのTWAMP-コントロールセッションSHOULDで量産されました。 Accept-セッションメッセージが全く(いかなる理由でもTWAMP-コントロールに使用されるTCP接続の失敗を含んでいる)送られなかったなら、このTWAMP-コントロールセッションで生じるすべてのTWAMP-テストセッションの結果は無効であると考えられるかもしれません。
Number of Sessions indicates the number of sessions that the Control-Client intends to stop.
セッションズの数はControl-クライアントが止めるつもりであるセッションの数を示します。
Number of Sessions MUST contain the number of send sessions started by the Control-Client that have not been previously terminated by a Stop-Sessions command (i.e., the Control-Client MUST account for each accepted Request-Session). If the Stop-Sessions message does not account for exactly the number of sessions in progress, then it is to be considered invalid, the TWAMP-Control connection SHOULD be closed, and any results obtained considered invalid.
セッションズの数が数を含まなければならない、以前にStop-セッションズによって終えられていないControl-クライアントによって始められたセッションにコマンドを送ってください(すなわち、Control-クライアントはそれぞれの受け入れられたRequest-セッションを説明しなければなりません)。 Stop-セッションメッセージがちょうど進行中のセッションの数を説明しないなら、閉じられて、それは病人、TWAMP-コントロール接続SHOULDであると考えられることになっていました、そして、どんな結果も考えられた病人を得ました。
Upon receipt of a TWAMP-Control Stop-Sessions command, the Session- Reflector MUST discard any TWAMP-Test packets that arrive at the current time plus the Timeout (in the Request-TW-Session command).
TWAMP-規制Stop-セッション命令を受け取り次第、Session反射鏡は現在の時間とTimeout(Request-TW-セッション命令における)に達するどんなTWAMP-テストパケットも捨てなければなりません。
Hedayat, et al. Standards Track [Page 11] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[11ページ]RFC5357ツーウェイ
3.9. Fetch-Session
3.9. フェッチセッション
One purpose of TWAMP is measurement of two-way metrics. Two-way measurement methods do not require packet-level data to be collected by the Session-Reflector (such as sequence number, timestamp, and Time to Live (TTL)) because this data is communicated in the "reflected" test packets. As such, the protocol does not require the retrieval of packet-level data from the Server and the OWAMP Fetch- Session command is not used in TWAMP.
TWAMPの1つの目的は両用測定基準の測定です。 このデータが「反射した」テストパケットで伝えられるので、両用測定方法は、Session-反射鏡(一連番号や、タイムスタンプや、Live(TTL)へのTimeなどの)によってパケット・レベルデータが集められるのを必要としません。 そういうものとして、プロトコルはServerからのパケット・レベルデータの検索を必要としません、そして、OWAMP Fetchセッション命令はTWAMPで使用されません。
4. TWAMP-Test
4. TWAMP-テスト
The TWAMP-Test protocol is similar to the OWAMP-test protocol [RFC4656] with the exception that the Session-Reflector transmits test packets to the Session-Sender in response to each test packet it receives. TWAMP defines two different test packet formats, one for packets transmitted by the Session-Sender and one for packets transmitted by the Session-Reflector. As with OWAMP-test protocol [RFC4656], there are three modes: unauthenticated, authenticated, and encrypted.
TWAMP-テストプロトコルはそれが受けるそれぞれのテストパケットに対応したSession-送付者へのOWAMP-テストプロトコルとSession-反射鏡が伝える例外について同様[RFC4656]のテストパケットです。 TWAMPは2つの異なったテストパケット・フォーマット(Session-送付者ともの時までに伝えられたパケットのためのもの)を定義します。 OWAMP-テストプロトコル[RFC4656]のように、3つのモードがあります: 非認証されて、認証されて、コード化されます。
4.1. Sender Behavior
4.1. 送付者の振舞い
The sender behavior is determined by the configuration of the Session-Sender and is not defined in this standard. Further, the Session-Reflector does not need to know the Session-Sender behavior to the degree of detail as needed in OWAMP [RFC4656]. Additionally, the Session-Sender collects and records the necessary information provided from the packets transmitted by the Session-Reflector for measuring two-way metrics. The information recording based on the packet(s) received by the Session-Sender is implementation dependent.
送付者の振舞いは、Session-送付者の構成で決定して、この規格で定義されません。 さらに、Session-反射鏡は必要に応じてOWAMP[RFC4656]でSession-送付者の振舞いを詳細の度合いに知る必要はありません。 さらに、Session-送付者は、測定の両用測定基準のためにSession-反射鏡によって伝えられたパケットから提供された必要事項を、集めて、記録します。 Session-送付者によって受け取られたパケットに基づく情報録音は実現に依存しています。
4.1.1. Packet Timings
4.1.1. パケットタイミング
Since the send schedule is not communicated to the Session-Reflector, there is no need for a standardized computation of packet timing.
以来、パケットタイミングの標準化された計算の必要性を全くSession-反射鏡に伝えられないで、あるスケジュールに送らないでください。
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).
どんなスケジューリング遅れにかかわらず、実際に送られる各パケットはタイムスタンプ(パケットの)として出発についてリアルタイムでの可能な限り良い近似を持たなければなりません。
4.1.2. Packet Format and Content
4.1.2. パケット・フォーマットと内容
The Session-Sender packet format and content follow the same procedure and guidelines as defined in Section 4.1.2 of OWAMP [RFC4656] (with the exception of the reference to the send schedule).
Session-送付者パケット・フォーマットと内容が.2セクション4.1OWAMP[RFC4656]で定義されるように同じ手順とガイドラインに従う、(参照、発信、スケジュール)
Hedayat, et al. Standards Track [Page 12] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[12ページ]RFC5357ツーウェイ
Note that the Reflector test packet formats are larger than the Sender's formats. The Session-Sender MAY append sufficient Packet Padding to allow the same IP packet payload lengths to be used in each direction of transmission (this is usually desirable). To compensate for the Reflector's larger test packet format, the Sender appends at least 27 octets of padding in unauthenticated mode, and at least 56 octets in authenticated and encrypted modes.
Reflectorテストパケット・フォーマットがSenderの形式より大きいことに注意してください。 Session-送付者は同じIPパケットペイロード長がトランスミッションの各方向に使用されるのを許容できるくらいのPacket Paddingを追加するかもしれません(通常、これは望ましいです)。 Reflectorの、より大きいテストパケット・フォーマットを補うために、Senderは非認証されたモードでそっと歩く少なくとも27の八重奏、および認証されてコード化されたモードにおける少なくとも56の八重奏を追加します。
4.2. Reflector Behavior
4.2. 反射鏡の振舞い
TWAMP requires the Session-Reflector to transmit a packet to the Session-Sender in response to each packet it receives.
TWAMPは、それが受ける各パケットに対応してSession-送付者にパケットを伝えるためにSession-反射鏡を必要とします。
As packets are received, the Session-Reflector will do the following:
パケットが受け取られているので、Session-反射鏡は以下をするでしょう:
- Timestamp the received packet. Each packet that is actually
received MUST have the best possible approximation of its real
time of arrival entered as its Received Timestamp (in the packet).
- タイムスタンプ、容認されたパケット。 実際に受け取られる各パケットで、Received Timestamp(パケットの)として到着についてリアルタイムでの可能な限り良い近似に入らなければなりません。
- In authenticated or encrypted mode, decrypt the appropriate
sections of the packet body (first block (16 octets) for
authenticated, 96 octets for encrypted), and then check integrity
of sections covered by the HMAC.
- 認証されたかコード化されたモードで、パケットボディーの相当区を解読してください、(認証されて、最初に(16の八重奏)を妨げる、96の八重奏、コード化、)、そして、HMACでカバーされたセクションのチェック保全。
- Copy the packet sequence number into the corresponding reflected
packet to the Session-Sender.
- Session-送付者への対応する反射したパケットにパケット一連番号をコピーしてください。
- Extract the Sender TTL value from the TTL/Hop Limit value of
received packets. Session-Reflector implementations SHOULD fetch
the TTL/Hop Limit value from the IP header of the packet,
replacing the value of 255 set by the Session-Sender. 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 set the Sender TTL value as 255.
- 容認されたパケットのTTL/ホップLimit価値からSender TTL値を抽出してください。 セッション反射鏡実現SHOULDはパケットのIPヘッダーからTTL/ホップLimit価値をとって来ます、255セットの値をSession-送付者に取り替えて。 実現が実際のTTL値をとって来ないなら(そうしない唯一の十分な理由は到着パケットのTTL分野にアクセスできないことです)、それは255としてSender TTL値を設定しなければなりません。
- In authenticated and encrypted modes, the HMAC MUST be calculated
first, then the appropriate portion of the packet body is
encrypted.
- 認証されてコード化されたモードで、HMAC MUSTが最初に計算されて、そして、パケットボディーの適切な部分はコード化されています。
- Transmit a test packet to the Session-Sender in response to every
received packet. The response MUST be generated as immediately as
possible. The format and content of the test packet is defined in
Section 4.2.1. Prior to the transmission of the test packet, the
Session-Reflector MUST enter the best possible approximation of
its actual sending time as its Timestamp (in the packet). This
permits the determination of the elapsed time between the
reception of the packet and its transmission.
- あらゆる容認されたパケットに対応してSession-送付者にテストパケットを伝えてください。 応答はできるだけすぐに、発生しなければなりません。 テストパケットの書式と内容はセクション4.2.1で定義されます。 テストパケットのトランスミッションの前に、Session-反射鏡はTimestamp(パケットの)として実際の送付時間の可能な限り良い近似に入らなければなりません。 これはパケットのレセプションとそのトランスミッションの間で経過時間の決断を可能にします。
Hedayat, et al. Standards Track [Page 13] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[13ページ]RFC5357ツーウェイ
- Packets not received within the Timeout (following the Stop-
Sessions command) MUST be ignored by the Reflector. The Session-
Reflector MUST NOT generate a test packet to the Session-Sender
for packets that are ignored.
- ReflectorはTimeout(Stopセッション命令に従う)の中に受け取られなかったパケットを無視しなければなりません。 Session反射鏡は無視されるパケットのためにSession-送付者にテストパケットを発生させてはいけません。
The possibility exists for Session-Sender failure during a session, or the path between the Session-Sender and Session-Reflector may fail while a test session is in progress. The Session-Reflector MAY discontinue any session that has been started when no packet associated with that session has been received for REFWAIT seconds. The default value of REFWAIT SHALL be 900 seconds, and this waiting time MAY be configurable. This timeout allows a Session-Reflector to free up resources in case of failure.
可能性がSession-送付者失敗によってセッションの間、存在しているか、またはテストセッションが進行している間、Session-送付者とSession-反射鏡の間の経路は失敗するかもしれません。 REFWAIT秒の間、そのセッションに関連しているどんなパケットも受け取っていない始められたどんなセッションもSession-反射鏡は中止されるかもしれません。 デフォルト値、REFWAIT SHALLでは900秒になってください、そして、この待ち時間は構成可能であってもよいです。 このタイムアウトで、Session-反射鏡は失敗の場合にリソースを開けることができます。
4.2.1. TWAMP-Test Packet Format and Content
4.2.1. TWAMP-テストパケット・フォーマットと内容
The Session-Reflector MUST transmit a packet to the Session-Sender in response to each packet received. The Session-Reflector SHOULD transmit the packets as immediately as possible. The Session- Reflector SHOULD set the TTL in IPv4 (or Hop Limit in IPv6) in the UDP packet to 255.
Session-反射鏡は受け取られた各パケットに対応してSession-送付者にパケットを伝えなければなりません。 Session-反射鏡SHOULDはできるだけすぐに、パケットを伝えます。 Session反射鏡SHOULDは255へのUDPパケットでIPv4(または、IPv6のHop Limit)にTTLをはめ込みます。
The test packet will have the necessary information for calculating two-way metrics by the Session-Sender. The format of the test packet depends on the mode being used. The two formats are presented below.
テストパケットには、計算の両用測定基準のための必要事項がSession-送付者であるでしょう。 テストパケットの形式は使用されるモードに依存します。 2つの形式が以下に提示されます。
Hedayat, et al. Standards Track [Page 14] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[14ページ]RFC5357ツーウェイ
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 | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Error Estimate | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender TTL | | +-+-+-+-+-+-+-+-+ + | | . . . 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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプを受け取ってください。| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者タイムスタンプ| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者誤り見積り| MBZ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者TTL| | +-+-+-+-+-+-+-+-+ + | | . . . パケット詰め物…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hedayat, et al. Standards Track [Page 15] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[15ページ]RFC5357ツーウェイ
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ (8 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ (12 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Error Estimate | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MBZ (6 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender TTL | | +-+-+-+-+-+-+-+-+ + | | | | | 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(12の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 誤り見積り| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MBZ(6つの八重奏)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプを受け取ってください。| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ(8つの八重奏)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ(12の八重奏)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者タイムスタンプ| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者誤り見積り| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MBZ(6つの八重奏)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者TTL| | +-+-+-+-+-+-+-+-+ + | | | | | MBZ(15の八重奏)| +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | HMAC(16の八重奏)| | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
Hedayat, et al. Standards Track [Page 16] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[16ページ]RFC5357ツーウェイ
| | . . . Packet Padding . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | . . . パケット詰め物…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that all timestamps have the same format as OWAMP [RFC4656] as follows:
すべてのタイムスタンプでOWAMP[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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 秒の整数部| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 秒の断片的な一部分| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number is the sequence number of the test packet according to its transmit order. It starts with zero and is incremented by one for each subsequent packet. The Sequence Number generated by the Session-Reflector is independent from the sequence number of the arriving packets.
系列Numberがテストパケットの一連番号である、それ、オーダーを伝えてください。 それは、ゼロから始まって、それぞれのその後のパケットあたり1つ増加されます。 Session-反射鏡で発生するSequence Numberは到着パケットの一連番号から独立しています。
Timestamp and Error Estimate are the Session-Reflector's transmit timestamp and error estimate for the reflected test packet, respectively. The format of all timestamp and error estimate fields follow the definition and formats defined by OWAMP, Section 4.1.2 in [RFC4656].
タイムスタンプとError Estimateによる反射鏡のSessionものが反射したテストパケットのためにそれぞれタイムスタンプと誤り見積りを伝えるということです。 すべてのタイムスタンプと分野が定義に続くという誤り見積りの書式とOWAMP、[RFC4656]のセクション4.1.2によって定義された書式。
Sender Timestamp and Sender Error Estimate are exact copies of the timestamp and error estimate from the Session-Sender test packet that corresponds to this test packet.
送付者TimestampとSender Error Estimateはこのテストパケットに対応するSession-送付者テストパケットからのタイムスタンプと誤り見積りの正確なコピーです。
Sender TTL is 255 when transmitted by the Session-Sender. Sender TTL is set to the Time To Live (or Hop Count) value of the received packet from the IP packet header when transmitted by the Session- Reflector.
Session-送付者によって伝えられると、送付者TTLは255歳です。 Session反射鏡によって伝えられると、送付者TTLはIPパケットのヘッダーからの容認されたパケットのTime To Live(または、Hop Count)値に用意ができています。
Receive Timestamp is the time the test packet was received by the reflector. The difference between Timestamp and Receive Timestamp is the amount of time the packet was in transition in the Session- Reflector. The Error Estimate associated with the Timestamp field also applies to the Receive Timestamp.
受信してください。反射鏡でテストパケットを受け取った時代にTimestampはそうです。 TimestampとReceive Timestampの違いはパケットが変遷Session反射鏡で中であった時間です。 また、Timestamp分野に関連しているError EstimateはReceive Timestampに適用します。
Sender Sequence Number is a copy of the Sequence Number of the packet transmitted by the Session-Sender that caused the Session-Reflector to generate and send this test packet.
送付者Sequence NumberはSession-反射鏡がこのテストパケットを発生して、送ることを引き起こしたSession-送付者によって伝えられたコピーのパケットのSequence Numberです。
Hedayat, et al. Standards Track [Page 17] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[17ページ]RFC5357ツーウェイ
The HMAC field in TWAMP-Test packets covers the same fields as the Advanced Encryption Standard (AES) encryption. Thus, in authenticated mode, HMAC covers the first block (16 octets); in encrypted mode, HMAC covers the first six blocks (96 octets). In TWAMP-Test, the HMAC field MUST NOT be encrypted.
TWAMP-テストパケットのHMAC分野はエー・イー・エス(AES)暗号化と同じ分野をカバーしています。 したがって、認証されたモードで、HMACは最初のブロック(16の八重奏)をカバーしています。 コード化されたモードで、HMACは最初の6ブロック(96の八重奏)をカバーしています。 TWAMP-テストで、HMAC分野をコード化してはいけません。
Packet Padding in TWAMP-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. Packet Padding MUST NOT be covered by the HMAC and MUST NOT be encrypted.
中のパケットPaddingはSHOULDをTWAMPテストします。擬似ランダム(それは本書では言及されたいかなる他の擬似乱数の如何にかかわらず発生しなければならない)になってください。 しかしながら、実現は設定パラメータ、オプション、またはPacket Paddingをすべてのゼロから成らせる異なった手段を提供しなければなりません。 パケットPaddingをHMACで覆っていてはいけなくて、コード化してはいけません。
The minimum data segment length of TWAMP-Test packets in unauthenticated mode is 41 octets, and 104 octets in both authenticated mode and encrypted modes.
非認証されたモードによる最小のデータ・セグメントの長さのTWAMP-テストパケットが41の八重奏であり、両方の104の八重奏が、モードを認証して、モードをコード化しました。
Note that the Session-Reflector Test packet formats are larger than the Sender's formats. The Session-Reflector SHOULD reduce the length of the Sender's Packet Padding to achieve equal IP packet payload lengths in each direction of transmission, when sufficient padding is present. The Session-Reflector MAY re-use the Sender's Packet Padding (since the requirements for padding generation are the same for each), and in this case the Session-Reflector SHOULD truncate the padding such that the highest-number octets are discarded.
Session-反射鏡Testパケット・フォーマットがSenderの形式より大きいことに注意してください。 Session-反射鏡SHOULDは等しいIPパケットペイロード長をトランスミッションの各方向に達成するためにSenderのPacket Paddingの長さを減少させます、十分な詰め物が存在しているとき。 Session-反射鏡はSenderのPacket Paddingを再使用するかもしれません、そして、(それぞれに、世代を水増しするための要件が同じであるので)この場合、Session-反射鏡SHOULDは最多数八重奏が捨てられるように、詰め物に先端を切らせます。
In unauthenticated mode, encryption or authentication MUST NOT be applied.
非認証されたモードで、暗号化か認証を適用してはいけません。
The TWAMP-Test packet layout is identical in authenticated and encrypted modes. The encryption operation for a Session-Sender packet follows the same rules of Session-Sender packets as defined in OWAMP section 4.1.2 of [RFC4656].
TWAMP-テストパケットレイアウトは認証されてコード化されたモードが同じです。 Session-送付者パケットのための暗号化操作は.2OWAMP部4.1の[RFC4656]で定義されるようにSession-送付者パケットの同じ規則に従います。
The main difference between authenticated mode and encrypted mode is the portion of the test packets that are covered by HMAC and encrypted. Authenticated mode permits the timestamp to be fetched after a portion of the packet is encrypted, but in encrypted mode all the sequence numbers and timestamps are fetched before encryption to provide maximum data-integrity protection.
認証されたモードとコード化されたモードの主な違いはHMACで覆われて、コード化されるテストパケットの一部です。 パケットの部分がコード化されていた後に認証されたモードは、タイムスタンプがとって来られることを許可しますが、コード化されたモードで、すべての一連番号とタイムスタンプが、暗号化の前に最大のデータ保全保護を提供するためにとって来られます。
In authenticated mode, only the sequence number in the first block is encrypted, and the subsequent timestamps and sequence numbers are sent in clear text. Sending the timestamp in clear text allows one to reduce the time between when a timestamp is obtained by a Session-Reflector and when that packet is sent out. This potentially improves the timestamp accuracy, because the sequence number can be encrypted before the timestamp is fetched.
認証されたモードで、最初のブロックの一連番号だけがコード化しています、そして、クリアテキストでその後のタイムスタンプと一連番号を送ります。 クリアテキストのタイムスタンプを送るのに、1つはタイムスタンプがSession-反射鏡によって得られる時、そのパケットを出す時時間を短縮できます。 これは、タイムスタンプがとって来られる前に一連番号をコード化できるので、潜在的にタイムスタンプ精度を改良します。
Hedayat, et al. Standards Track [Page 18] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[18ページ]RFC5357ツーウェイ
In encrypted mode, the reflector MUST fetch the timestamps, generate the HMAC, and encrypt the packet, then send it.
コード化されたモードで、反射鏡は、タイムスタンプをとって来て、HMACを発生させて、パケットをコード化して、次に、それを送らなければなりません。
Obtaining the keys and encryption methods follows the same procedure as OWAMP as described below. Each TWAMP-Test session has two keys, an AES Session-key and an HMAC Session-key, and the keys are derived from the TWAMP-Control keys and the SID.
キーと暗号化方法を入手すると、以下で説明されるOWAMPと同じ手順は従われます。 それぞれのTWAMP-テストセッションには2個のキー、AES Session-キー、およびHMAC Session-キーがあります、そして、TWAMP-コントロールキーとSIDからキーを得ます。
The TWAMP-Test AES Session-key is obtained as follows: the TWAMP- Control AES Session-key (the same AES Session-key as used for the corresponding TWAMP-Control session) is encrypted with the 16-octet session identifier (SID) as the key, using a single-block AES-ECB encryption. The result is the TWAMP-Test AES Session-key to be used in encrypting (and decrypting) the packets of the particular TWAMP- Test session. Note that the TWAMP-Test AES Session-key, TWAMP- Control AES Session-key, and the SID are all comprised of 16 octets.
以下の通りTWAMP-テストAES Session-キーを入手します: TWAMP制御AES Session-キー(対応するTWAMP-コントロールセッションに使用される同じAES Session-キー)はキーとして16八重奏のセッション識別子(SID)でコード化されます、単滑車AES-ECB暗号化を使用して。 結果は特定のTWAMPテストセッションのパケットをコード化する際に(そして、解読すること)使用されているためにAES Session主要なTWAMP-テストです。 TWAMP-テストAES Session-キー、TWAMP制御AES Session-キー、およびSIDが16の八重奏からすべて成ることに注意してください。
The TWAMP-Test HMAC Session-key is obtained as follows: the TWAMP- Control HMAC Session-key (the same HMAC Session-key as used for the corresponding TWAMP-Control session) is encrypted using AES-CBC (Cipher Block Chaining) with the 16-octet session identifier (SID) as the key. This is a two-block CBC encryption that is always performed with IV=0. Note that the TWAMP-Test HMAC Session-key and TWAMP- Control HMAC Session-key are comprised of 32 octets, while the SID is 16 octets.
以下の通りTWAMP-テストHMAC Session-キーを入手します: TWAMP制御HMAC Session-キー(対応するTWAMP-コントロールセッションに使用される同じHMAC Session-キー)は、キーとして16八重奏のセッション識別子(SID)があるAES-CBC(暗号Block Chaining)を使用することでコード化されています。 これはいつもIV=0で実行される2ブロックしているCBC暗号化です。 TWAMP-テストHMAC Session-キーとTWAMP制御HMAC Session-キーが32の八重奏から成ることに注意してください、SIDは16の八重奏ですが。
In authenticated mode, the first block (16 octets) of each TWAMP-Test packet is encrypted using the AES Electronic Codebook (ECB) mode. This mode does not involve any chaining, and lost, duplicated, or reordered packets do not cause problems with deciphering any packet in a TWAMP-Test session.
認証されたモードで、それぞれのTWAMP-テストパケットの最初のブロック(16の八重奏)は、AES Electronic Codebook(ECB)モードを使用することでコード化されています。 このモードは少しの推論も伴いません、そして、無くなっているか、コピーされたか、再命令されたパケットはTWAMP-テストセッションのときにどんなパケットも解読するのに問題を起こしません。
In encrypted mode, the first six blocks (96 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 TWAMP-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.
コード化されたモードで、最初の6つのブロック(96の八重奏)が、AES-CBCモードを使用することでコード化されています。 認証されたモードのためのキーと同様に、使用するAES Session-キーを入手します。 それぞれのTWAMP-テストパケットは別々の流れとしてちょうど1つの推論操作でコード化されます。 推論が複数のパケットにかかっていないので、無くなっているか、コピーされたか、再命令されたパケットは問題を起こしません。CBC暗号化のための初期化ベクトルはゼロに合わせるために等しいすべてのビットがある値です。
Implementation Note: Naturally, the key schedule for each TWAMP-Test session MUST be set up at most once per session, not once per packet.
実現注意: 当然、それぞれのTWAMP-テストセッションのための主要なスケジュールを1パケットあたりの一度ではなく、高々1セッションに一度セットアップしなければなりません。
Hedayat, et al. Standards Track [Page 19] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[19ページ]RFC5357ツーウェイ
5. Implementers' Guide
5. Implementersのガイド
This section serves as guidance to implementers of TWAMP. The example architecture presented here is not a requirement. Similar to OWAMP [RFC4656], TWAMP is designed with enough flexibility to allow different architectures that suit multiple system requirements.
このセクションは指導としてTWAMPのimplementersに機能します。 ここに提示された例の構造は要件ではありません。 OWAMP[RFC4656]と同様であることで、TWAMPは複数のシステム要求に合う異なった構造を許容できるくらい柔軟性で設計されています。
In this example, the roles of Control-Client and Session-Sender are implemented in one host referred to as the controller, and the roles of Server and Session-Reflector are implemented in another host referred to as the responder.
この例では、Control-クライアントとSession-送付者の役割はコントローラに差し向けられた1人のホストで実行されます、そして、ServerとSession-反射鏡の役割は応答者に差し向けられた別のホストで実行されます。
controller responder
+-----------------+ +-------------------+
| Control-Client |<--TWAMP-Control-->| Server |
| | | |
| Session-Sender |<--TWAMP-Test----->| Session-Reflector |
+-----------------+ +-------------------+
コントローラ応答者+-----------------+ +-------------------+ | コントロールクライアント| <--TWAMP-コントロール-->| サーバ| | | | | | セッション送付者| <--TWAMP-テスト----->| セッション反射鏡| +-----------------+ +-------------------+
This example provides an architecture that supports the full TWAMP standard. The controller establishes the test session with the responder through the TWAMP-Control protocol. After the session is established, the controller transmits test packets to the responder. The responder follows the Session-Reflector behavior of TWAMP as described in Section 4.2.
この例は完全なTWAMP規格を支持する構造を提供します。 コントローラはTWAMP-制御プロトコルを通して応答者とのテストセッションを確立します。 セッションが確立された後に、コントローラはテストパケットを応答者に伝えます。 応答者はセクション4.2で説明されるようにTWAMPのSession-反射鏡動きの後をつけます。
Appendix I provides an example for purely informational purposes. It suggests an incremental path to adopting TWAMP, by implementing the TWAMP-Test protocol first.
私が純粋に情報の目的のための例を供給する付録。 それは最初にTWAMP-テストプロトコルを実行することによってTWAMPを採用するのに増加の経路を示します。
6. Security Considerations
6. セキュリティ問題
Fundamentally, TWAMP and OWAMP use the same protocol for establishment of Control and Test procedures. The main difference between TWAMP and OWAMP is the Session-Reflector behavior in TWAMP vs. the Session-Receiver behavior in OWAMP. This difference in behavior does not introduce any known security vulnerabilities that are not already addressed by the security features of OWAMP. The entire security considerations of OWAMP [RFC4656] applies to TWAMP.
基本的に、TWAMPとOWAMPはControlとTest手順の確立に同じプロトコルを使用します。 TWAMPとOWAMPの主な違いは振舞い対OWAMPのTWAMPのSession-反射鏡のSession-受信機の振舞いです。 振舞いのこの違いはOWAMPのセキュリティ機能によって既に記述されない少しの知られているセキュリティの脆弱性も導入しません。 OWAMP[RFC4656]の全体のセキュリティ問題はTWAMPに適用されます。
The Server-Greeting message (defined in OWAMP, Section 3.1 of [RFC4656]) includes a Count field to specify the iteration counter used in PKCS #5 to generate keys from shared secrets. OWAMP recommends a lower limit of 1024 iterations, but no upper limit. The Count field provides an opportunity for a denial-of-service (DOS) attack because it is 32 bits long. If an attacking system set the maximum value in Count (2**32), then the system under attack would stall for a significant period of time while it attempts to generate
Server-あいさつメッセージ(OWAMP、[RFC4656]のセクション3.1では、定義される)は、共有秘密キーからキーを発生させるのにPKCS#5に使用される繰り返しカウンタを指定するためにCount分野を含んでいます。 繰り返しを推薦しますが、OWAMPは1024年の下限にどんな上限も推薦しません。 それが長さ32ビットであるので、Count分野はサービスの否定(DOS)攻撃に機会を与えます。 攻撃システムがCount(2**32)の値、攻撃しているシステムが重要な期間の間に失速させるそれである間、その時が発生するのを試みる最大を設定したなら
Hedayat, et al. Standards Track [Page 20] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[20ページ]RFC5357ツーウェイ
keys. Therefore, TWAMP-compliant systems SHOULD have a configuration control to limit the maximum Count value. The default maximum Count value SHOULD be 32768. As suggested in OWAMP, this value MAY be increased when greater computing power becomes common. If a Control-Client receives a Server-Greeting message with Count greater that its maximum configured value, it SHOULD close the control connection.
キー。 したがって、TWAMP対応することのシステムSHOULDには、最大のCount値を制限する構成管理があります。 デフォルト最大のCountはSHOULDを評価します。32768になってください。 より大きいコンピューティングパワーが一般的になるとき、OWAMPに示されて、この値が増加するかもしれないのに従って。 Countが、よりすばらしい状態でControl-クライアントがServer-あいさつメッセージを受け取るなら、最大が値を構成して、それがSHOULDであることはコントロール接続を終えます。
7. Acknowledgements
7. 承認
We would like to thank Nagarjuna Venna, Sharee McNab, Nick Kinraid, Stanislav Shalunov, Matt Zekauskas, Walt Steverson, Jeff Boote, Murtaza Chiba, and Kevin Earnst for their comments, suggestions, reviews, helpful discussion, and proof-reading. Lars Eggert, Sam Hartman, and Tim Polk contributed very useful AD-level reviews, and the authors thank them for their contributions to the memo.
彼らのコメント、提案、レビュー、役立っている議論、およびプルーフ・リーディングについてNagarjuna Venna、Shareeマクナブ、ニックKinraid、スタニスラフShalunov、マットZekauskas、ウォルトSteverson、ジェフBoote、Murtaza千葉、およびケビンEarnstに感謝申し上げます。 ラース・エッゲルト、サム・ハートマン、およびティム・ポークは非常に役に立つADレベルレビューを寄付しました、そして、作者はメモへの彼らの貢献について彼らに感謝します。
8. IANA Considerations
8. IANA問題
IANA has allocated a well-known TCP port number (861) for the OWAMP- Control part of the OWAMP [RFC4656] protocol.
IANAはOWAMP[RFC4656]プロトコルのOWAMPコントロール部分に周知のTCPポートナンバー(861)を割り当てました。
... owamp-control 861/tcp OWAMP-Control owamp-control 861/udp OWAMP-Control # [RFC4656]
…owamp-コントロール861/tcp OWAMP-コントロールowamp-コントロール861/udp OWAMP-コントロール#[RFC4656]
IANA has also allocated a well-known TCP/UDP port number for the TWAMP-Control protocol.
また、IANAはTWAMP-制御プロトコルのために周知のTCP/UDPポートナンバーを割り当てました。
...
twamp-control 862/tcp Two-way Active Measurement Protocol
(TWAMP) Control
twamp-control 862/udp Two-way Active Measurement Protocol
(TWAMP) Control
# [RFC5357]
# 863-872 Unassigned
… twamp-規制862/tcp Two-道のActive Measurementプロトコル(TWAMP)はtwamp-規制862/udp Two-道のActive Measurementプロトコル(TWAMP)コントロール#[RFC5357]#863-872Unassignedを制御します。
Since TWAMP adds an additional Control command beyond the OWAMP- Control specification and describes behavior when this control command is used, IANA has created a registry for the TWAMP Command Number field. The field is not explicitly named in [RFC4656] but is called out for each command. This field is a recognized extension mechanism for TWAMP.
TWAMPがOWAMPコントロール仕様を超えて追加Controlコマンドを加えて、この制御コマンドが使用されているとき振舞いについて説明するので、IANAはTWAMP Command Number分野に登録を作成しました。 分野は、[RFC4656]で明らかに命名されませんが、各コマンドのために呼び出されます。 この分野はTWAMPのための認識された拡大メカニズムです。
Hedayat, et al. Standards Track [Page 21] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[21ページ]RFC5357ツーウェイ
8.1. Registry Specification
8.1. 登録仕様
IANA has created a TWAMP-Control Command Number registry. TWAMP- Control commands are specified by the first octet in OWAMP-Control messages as shown in Section 3.5 of [RFC4656], and modified by this document. Thus, this registry may contain sixteen possible values.
IANAはTWAMP-コントロールCommand Number登録を作成しました。 TWAMP制御コマンドは[RFC4656]のセクション3.5に示されて、このドキュメントによって変更されるようにOWAMP-コントロールメッセージにおける最初の八重奏で指定されます。 したがって、この登録は16の可能な値を含むかもしれません。
8.2. Registry Management
8.2. 登録管理
Because the registry may only contain sixteen values, and because OWAMP and TWAMP are IETF protocols, this registry must only be updated by "IETF Consensus" as specified in [RFC5226] -- an RFC documenting the use that is approved by the IESG. We expect that new values will be assigned as monotonically increasing integers in the range [0-15], unless there is a good reason to do otherwise.
登録が16の値しか含まないかもしれなくて、OWAMPとTWAMPがIETFプロトコルであるので、[RFC5226]の指定されるとしての「IETFコンセンサス」はこの登録をアップデートするだけでよいです--IESGによって承認される使用を記録するRFC。 私たちは、新しい値が別の方法でするもっともな理由がない場合範囲[0-15]で整数を単調に増加させるとして割り当てられると予想します。
8.3. Experimental Numbers
8.3. 実験数
[RFC3692] recommends allocating an appropriate number of values for experimentation and testing. It is not clear to the authors exactly how many numbers might be useful in this space, or if it would be useful that they were easily distinguishable or at the "high end" of the number range. Two might be useful, say one for session control, and one for session fetch. On the other hand, a single number would allow for unlimited extension, because the format of the rest of the message could be tailored, with allocation of other numbers done once usefulness has been proven. Thus, this document allocates one number (6) as designated for experimentation and testing.
[RFC3692]は、実験のために適切な数の値を割り当てて、テストすることを勧めます。 作者にとって、ちょうどいくつの数がこのスペースで役に立つかもしれないか、そして、または容易に区別可能であったか、または数の「上位」のときに及ぶのが役に立つかどうかは、明確ではありません。 セッション制御のためのもの、およびセッションフェッチのための人は、2が役に立つかもしれないと言います。 他方では、1つの数が無制限な拡大を考慮するでしょう、メッセージの残りの形式が合わせることができたので、有用性がいったん立証されると行われた他の数の配分で。 したがって、このドキュメントは実験のために指定されて、テストするとして1つの数(6)を割り当てます。
8.4. Initial Registry Contents
8.4. 初期の登録コンテンツ
TWAMP-Control Command Number Registry
TWAMP-制御コマンド数の登録
Value Description Semantics Definition 0 Reserved 1 Forbidden 2 Start-Sessions RFC 4656, Section 3.7 3 Stop-Sessions RFC 4656, Section 3.8 4 Reserved 5 Request-TW-Session this document, Section 3.5 6 Experimentation undefined, see Section 8.3.
記述Semantics Definition0Reserved1Forbidden2Start-セッションRFC4656、セクション3.7 3Stop-セッションRFC4656を評価してください、このセクション3.5 6Experimentation未定義のドキュメントがセクション8.3を見るセクション3.8 4Reserved5Request-TW-セッション。
9. Internationalization Considerations
9. 国際化問題
The protocol does not carry any information in a natural language, with the possible exception of the KeyID in TWAMP-Control, which is encoded in UTF-8 [RFC3629, RFC5198].
プロトコルは自然言語の少しの情報も運びません、TWAMP-コントロールにおける、KeyIDの可能な例外で。(コントロールはUTF-8[RFC3629、RFC5198]でコード化されます)。
Hedayat, et al. Standards Track [Page 22] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[22ページ]RFC5357ツーウェイ
Appendix I - TWAMP Light (Informative)
付録I--TWAMP光(有益)です。
In this example, the roles of Control-Client, Server, and Session- Sender are implemented in one host referred to as the controller, and the role of Session-Reflector is implemented in another host referred to as the responder.
この例では、Control-クライアント、Server、およびSession送付者の役割はコントローラに差し向けられた1人のホストで実行されます、そして、Session-反射鏡の役割は応答者に差し向けられた別のホストで実行されます。
controller responder
+-----------------+ +-------------------+
| Server |<----------------->| |
| Control-Client | | Session-Reflector |
| Session-Sender |<--TWAMP-Test----->| |
+-----------------+ +-------------------+
コントローラ応答者+-----------------+ +-------------------+ | サーバ| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| コントロールクライアント| | セッション反射鏡| | セッション送付者| <--TWAMP-テスト----->|、| +-----------------+ +-------------------+
This example provides a simple architecture for responders where their role will be to simply act as light test points in the network. The controller establishes the test session with the Server through non-standard means. After the session is established, the controller transmits test packets to the responder. The responder follows the Session-Reflector behavior of TWAMP as described in section 4.2 with the following exceptions.
この例は応答者のための単に軽く行動する彼らの役割がことである簡単な構造にネットワークにおけるテスト・ポイントを提供します。 コントローラは標準的でない手段でServerとのテストセッションを確立します。 セッションが確立された後に、コントローラはテストパケットを応答者に伝えます。 応答者は以下の例外があるセクション4.2で説明されるようにTWAMPのSession-反射鏡動きの後をつけます。
In the case of TWAMP Light, the Session-Reflector does not necessarily have knowledge of the session state. IF the Session- Reflector does not have knowledge of the session state, THEN the Session-Reflector MUST copy the Sequence Number of the received packet to the Sequence Number field of the reflected packet. The controller receives the reflected test packets and collects two-way metrics. This architecture allows for collection of two-way metrics.
TWAMP Lightの場合では、Session-反射鏡は必ずセッション状態に関する知識を持っているというわけではありません。 Session反射鏡にセッション状態に関する知識がないなら、THEN Session-反射鏡は反射したパケットのSequence Number分野に容認されたパケットのSequence Numberをコピーしなければなりません。 コントローラは、反射したテストパケットを受けて、両用測定基準を集めます。 この構造は両用測定基準の収集を考慮します。
This example eliminates the need for the TWAMP-Control protocol, and assumes that the Session-Reflector is configured and communicates its configuration with the Server through non-standard means. The Session-Reflector simply reflects the incoming packets back to the controller while copying the necessary information and generating sequence number and timestamp values per Section 4.2.1. TWAMP Light introduces some additional security considerations. The non-standard means to control the responder and establish test sessions SHOULD offer the features listed below.
この例は、標準的でない手段でTWAMP-制御プロトコルの必要性を排除して、Session-反射鏡が構成されていると仮定して、Serverと構成を伝えます。 Session-反射鏡は必要事項をコピーして、セクション4.2.1単位で一連番号とタイムスタンプ値を発生させている間、単に入って来るパケットをコントローラに映し出します。 TWAMP Lightはいくつかの追加担保問題を紹介します。 応答者を監督して、テストセッションSHOULDを確立する標準的でない手段は以下にリストアップされた特徴を提供します。
The non-standard responder control protocol SHOULD have an authenticated mode of operation. The responder SHOULD be configurable to accept only authenticated control sessions.
標準的でない応答者コントロールプロトコルSHOULDには、認証された運転モードがあります。 応答者SHOULD、認証されたコントロールセッションだけを受け入れるのにおいて、構成可能であってください。
The non-standard responder control protocol SHOULD have a means to activate the authenticated and encrypted modes of the TWAMP-Test protocol.
標準的でない応答者コントロールプロトコルSHOULDには、TWAMP-テストプロトコルの認証されてコード化されたモードを活性化する手段があります。
Hedayat, et al. Standards Track [Page 23] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[23ページ]RFC5357ツーウェイ
When the TWAMP Light test sessions operate in authenticated or encrypted mode, the Session-Reflector MUST have some mechanism for generating keys (because the TWAMP-Control protocol normally plays a role in this process, but is not present here). The specification of the key generation mechanism is beyond the scope of this memo.
TWAMP Lightテストセッションが認証されたかコード化されたモードで作動すると、Session-反射鏡にはキーを発生させるための何らかのメカニズムがなければならない、(TWAMP-制御プロトコルが通常この過程における役割を果たしますが、ここに存在していない、) キー生成メカニズムの仕様はこのメモの範囲を超えています。
Normative References
引用規格
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol (OWAMP)",
RFC 4656, September 2006.
[RFC4656] Shalunov、S.、タイテルバウム、B.、カープ、A.、Boote、J.、およびM.Zekauskas、「A One-道のアクティブな測定プロトコル(OWAMP)」、RFC4656 2006年9月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999.
1999年9月の[RFC2681]AlmesとG.とKalidindi、S.とM.Zekauskas、「IPPMにおける、メートル法の往復の遅れ」RFC2681。
[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月。
[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月)。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
2008.
[RFC5226] Narten、T.、およびH.Alvestrand(「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC5226)は2008がそうするかもしれません。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変化形式」STD63、RFC3629、11月2003日
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, March 2008.
[RFC5198] KlensinとJ.とM.Padlipsky、「ネットワーク置き換えのためのユニコード形式」、RFC5198、2008年3月。
Informative References
有益な参照
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten、T.、「役に立つと考えられた実験的でテストしている数を割り当てます」、BCP82、RFC3692、2004年1月。
Hedayat, et al. Standards Track [Page 24] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[24ページ]RFC5357ツーウェイ
Authors' Addresses
作者のアドレス
Kaynam Hedayat Brix Networks 285 Mill Road Chelmsford, MA 01824 USA EMail: khedayat@brixnet.com URI: http://www.brixnet.com/
Kaynamヘダーヤト果物の糖度の単位ネットワーク285はRoadチェルムズフォード(MA)01824米国メールを製粉します: khedayat@brixnet.com ユリ: http://www.brixnet.com/
Roman M. Krzanowski, Ph.D. Verizon 500 Westchester Ave. White Plains, NY USA EMail: roman.krzanowski@verizon.com URI: http://www.verizon.com/
ローマM.Krzanowski、博士号ベライゾン500ウェスチェスターAve。 ニューヨークホワイトプレーンズ(米国)はメールされます: roman.krzanowski@verizon.com ユリ: http://www.verizon.com/
Al Morton AT&T Labs Room D3 - 3C06 200 Laurel Ave. South Middletown, NJ 07748 USA Phone +1 732 420 1571 EMail: acmorton@att.com URI: http://home.comcast.net/~acmacm/
アルモートンAT&T研究室Room D3--3C06 200ローレルAve。 南ミドルタウン、ニュージャージー 米国電話+1 732 420 1571がメールする07748: acmorton@att.com ユリ: http://home.comcast.net/~acmacm/
Kiho Yum Juniper Networks 1194 Mathilda Ave. Sunnyvale, CA USA EMail: kyum@juniper.net URI: http://www.juniper.com/
Kihoのおいしい杜松は1194マチルダAveをネットワークでつなぎます。 カリフォルニアサニーベル(米国)はメールされます: kyum@juniper.net ユリ: http://www.juniper.com/
Jozef Z. Babiarz Nortel Networks 3500 Carling Avenue Ottawa, Ont K2H 8E9 Canada Email: babiarz@nortel.com URI: http://www.nortel.com/
ユゼフZ.Babiarzノーテルは3500年のOnt K2H8の9Eの縦梁Avenueオタワ(カナダ)メールをネットワークでつなぎます: babiarz@nortel.com ユリ: http://www.nortel.com/
Hedayat, et al. Standards Track [Page 25] RFC 5357 Two-Way Active Measurement Protocol October 2008
ヘダーヤト、他 測定プロトコル2008年10月にアクティブな標準化過程[25ページ]RFC5357ツーウェイ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を記述してください。
Hedayat, et al. Standards Track [Page 26]
ヘダーヤト、他 標準化過程[26ページ]
一覧
スポンサーリンク
