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
A Two-Way Active Measurement Protocol (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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
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.
RFC 4656で指定されたワンウェイアクティブな測定プロトコル（OWAMP）は、ネットワークデバイス間の一方向の指標を測定するための共通のプロトコルを提供します。 OWAMPは、2つのネットワーク要素間の両方向に一方向の指標を測定するために双方向に用いることができます。しかし、それは往復または双方向の測定に対応していません。このメモは、双方向または往復の測定機能を追加OWAMP、に基づいて、2ウェイアクティブ測定プロトコル（TWAMP）を指定します。 TWAMP測定アーキテクチャは、通常、特定の役割を持つ2つのホストで構成され、これはそれをいくつかの状況で魅力的な代替を行う、いくつかのプロトコルの単純化を可能にします。
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
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（Internet Engineering Task Force）はメトリックの往復遅延[RFC2681]のためのProposed Standardが完了しました。 IETFはまた、一方向測定の制御および収集するためのプロトコル、ワンウェイアクティブな測定プロトコル（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 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.
双方向の測定値は、ローカルとリモートクロックとの間の同期は、単純なエコー機能に限定することができる遠隔端における往復遅延、および測定をサポートするため不要である主な理由は、IPネットワークで一般的です。しかし、往復の測定のための最も一般的な機能は、（Pingツールによって使用される）、ICMPエコー要求/応答である、この方法の問題は、[RFC2681]のセクション2.6に記載されています。このメモは双方向アクティブ測定プロトコル、またはTWAMPを指定します。 TWAMPは、一次元に加えて、（今後この文書に用語双方向も往復を意味する）、双方向又は往復メトリクスを測定するためのオープンプロトコルを定義するために[RFC4656] OWAMPの方法およびアーキテクチャを使用します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", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
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.
TWAMP - コントロールとTWAMPテスト：OWAMP [RFC4656]と同様、TWAMPは、2つの相互関連するプロトコルから構成されています。これらのプロトコルの関係としてOWAMP [RFC4656]のセクション1.1で定義されています。 TWAMP - 制御はTWAMPテストは、2つのTWAMPエンティティ間テストパケットを交換するために使用されるのに対し、開始、起動、テストセッションを停止するために使用されます。
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.
- セッションレシーバはTWAMPアーキテクチャでセッションリフレクターと呼ばれています。セッションリフレクターは、計測パケットを受信したときに計測パケットを作成して送信する機能を持っています。セッション・レシーバとは異なり、セッション・リフレクターは、任意のパケット情報を収集することはありません。
- 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セッションを管理し、エンドシステムであり、エンドポイントでセッションごとの状態を設定することができます。しかし、セッション・リフレクターに関連したサーバーは、テストセッションの結果を返す機能を持っていないだろうが、これはOWAMPとの違いです。
- 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.
- フェッチクライアントエンティティがTWAMPアーキテクチャに存在しない場合、セッションリフレクタとしてフェッチする任意のパケット情報を収集しません。その結果、取得クライアントのための必要はありません。
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 |
+----------------+
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]のように、異なる論理的役割は、同じホストによって再生することができます。サーバーとのセッション・リフレクターの役割を果たしコントロールクライアントとセッション・送信者の役割を果たし1、およびその他：例えば、上の図では、実際には二つのホストがある可能性があります。この例を以下に示します。
+-----------------+ +-------------------+
| Control-Client |<--TWAMP-Control-->| Server |
| | | |
| Session-Sender |<--TWAMP-Test----->| Session-Reflector |
+-----------------+ +-------------------+
The acronym OWAMP is usually pronounced in two syllables, Oh-wamp.
頭字語OWAMPは、通常は2つの音節、OH-WAMPで発音されます。
The acronym TWAMP is also pronounced in two syllables, Tee-wamp.
頭字語TWAMPは、2つの音節、ティーWAMPで発音されます。
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:
双方向アクティブ測定プロトコルは、双方向のメトリックを測定するためのオープンなプロトコルです。それはOWAMP [RFC4656]に基づいており、OWAMPの全体的なアーキテクチャと設計に準拠しています。以下に概説するようにTWAMP-Controlと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.
- コントロールクライアントはTWAMPのよく知られたポート上のTCP接続を開始し、サーバーが（その役割は今確立）サポートしていく所存ですセキュリティ/整合性モード（複数可）を示し、そのグリーティングメッセージで応答します。
- 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.
- コントロールクライアントモードがそれらを必要とする場合、完全性保護と暗号化を支援するコミュニケーションと情報の選択されたモードで応答します。サーバーは、モードを受け入れ、その開始時間を与えるために応答します。これは、制御接続のセットアップを完了します。
- 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.
- コントロールクライアントの要求（と説明）ユニークなTWAMP - コントロールメッセージでテストセッション。サーバーは、その受け入れと支援情報で応答します。複数のテストセッションが追加メッセージを要求することができます。
- The Control-Client initiates all requested testing with a Start-Sessions message, and the Server acknowledges.
- コントロールクライアントがスタート - セッションメッセージで要求されたすべてのテストを開始し、サーバーが認識しています。
- The Session-Sender and the Session-Reflector exchange test packets according to the TWAMP-Test protocol for each active session.
- セッションSenderと各アクティブセッションのTWAMPテストプロトコルに従ってセッションリフレクター交換テストパケット。
- When appropriate, the Control-Client sends a message to stop all test sessions.
- 適切な場合、コントロールクライアントは、すべてのテストセッションを停止するようにメッセージを送信します。
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）モードフィールドがTWAMP制御接続のセットアップ中に、通信オプションを確立するために使用されます。
2) The TWAMP-Control Command Number is another intended extension mechanism, allowing additional commands to be defined in the future.
2）TWAMP - 制御コマンドの数は、追加のコマンドが将来定義されることを可能にする、別の意図された拡張機構です。
The TWAMP-Control protocol resolves different capability levels between the Control-Client and Server.
TWAMP制御プロトコルは、制御クライアントとサーバの間の異なる能力レベルを解決します。
All multi-octet quantities defined in this document are represented as unsigned integers in network byte order, unless specified otherwise.
特に断らない限り、本文書で定義されているすべてのマルチオクテットの量は、ネットワークバイト順に符号なし整数として表現されます。
Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set to zero by senders and MUST be ignored by receivers.
このメモを通じて、ビットは、MBZ（ゼロでなければならない）送信者によってゼロに設定しなければならなくて、受信機で無視しなければなりませんをマーク。
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で定義されたものと同様のガイドラインに従います。そのような例外はTWAMPで使用されていないフェッチセッションのコマンド、です。
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で定義された同一の手順に従います。モードフィールドはTWAMPに認識拡張機構である、と現在のモード値はOWAMPに使用されるものと同一です。唯一の例外はTWAMP - コントロールのためのよく知られたポート番号です。クライアントは、TCP接続が（2台ホスト実装で）セッション送信者をコントロールクライアントとの役割を取る開始well-knownポート862ホスト上のサーバへのTCP接続を開きます。 TCPコネクションを認めるホストは、サーバーと（2台ホスト実装で）セッションリフレクターの役割を受け入れます。
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).
コントロールクライアントが特定の制御接続のすべてのパケットのIPヘッダ内のDiffservのコードポイント（DSCP）フィールド内の所望のコードポイントを設定してもよいです。サーバーは、（再マーキングした場合のいずれかの曖昧さを回避する）、その接続上のすべての後続パケットでコントロールクライアントの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.
可能性はTWAMP制御接続確立後にコントロールクライアントの障害のために存在する、または接続の進行中に、コントロール・クライアントとサーバの間のパスが失敗する可能性があります。サーバーは、その接続に関連付けられたパケットがSERVWAIT秒以内に受信されていない任意の確立制御接続を中止することがあります。サーバーは、[スタート] - セッションのコマンドを受信した後、監視制御接続の活動を中止しなければならない、と（SERVWAITオプションがサポートされている場合）ストップ・セッションのコマンドを受信した後に再開するものとします。 REFWAITタイムアウト（後述）は、テストセッション中に障害を覆い、REFWAITはTWAMP制御接続によって開始されたすべての試験セッションで満了した場合（ストップセッションコマンドが受信されたかのように）、次いでSERVWAIT監視が再開SHALLことに留意されたいです。 SERVWAITタイムアウトをサポートする実装もREFWAITタイムアウトを実装する必要があります。 SERVWAITのデフォルト値は900秒であるものとし、この待機時間が設定可能であってもよいです。このタイムアウトは、サーバーが故障した場合にリソースを解放することができます。
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.
サーバーとクライアントの両方がKeyIDsから共有秘密に同じマッピングを使用します。 Serverは、複数のクライアントとのセッションを実施する用意があること、適切な秘密鍵を選択するKeyIDsを使用しています。クライアントは通常、別のサーバーごとに異なる秘密鍵を持っているでしょう。共有秘密鍵はパスフレーズです。パスフレーズの相互運用性を最大化するために、パスフレーズの文字セットは、[RFC5198]（ASCIIネットワーク仮想端末の定義）の付録Bを使用してエンコードする必要があります。これは、改行（キャリッジリターン（CR）、および/またはラインフィード（LF）文字の任意の組み合わせ）を含んではならない、と制御文字は避けるべきです。
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.
（初期制御接続の交換中にサーバーによって送信された）サーバー-StartメッセージがHMACフィールドで終了しないことに注意してください。従って、第1のAccept-セッションメッセージでHMACはまた、サーバー開始メッセージをカバーし、HMAC計算でスタート-Timeフィールドが含まれています。
Also, in authenticated and encrypted modes, the HMAC in TWAMP-Control packets is encrypted.
また、認証および暗号化モードでは、TWAMP - 制御パケットでHMACは暗号化されています。
Accept values used in TWAMP are the same as the values defined in Section 3.3 of OWAMP [RFC4656].
TWAMPに使用受け入れる値はOWAMP [RFC4656]のセクション3.3で定義された値と同じです。
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).
リクエスト-TW-セッション、開始・セッション、およびストップ・セッション：次のコマンドは、Control-クライアントのために利用可能です。サーバーは、受信したコマンド（次のセクションで説明したように）に応じて、特定のメッセージを送ることができます。
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リクエスト-sessionコマンドはTWAMPのRequest-TW-sessionコマンドに置き換えられていることに注意してください、とフェッチ-sessionコマンドはTWAMPには表示されません。
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で定義されるように、試験セッションの作成は、同じ手順に従います。リクエスト-TW-sessionコマンドはOWAMPリクエストセッションコマンドに基づいて、及びOWAMPのセクション3.5に記載されているようにメッセージフォーマットを使用するが、スケジュールスロット説明フィールド（単数または複数）がなく、唯一のHMACを使用しています。リクエスト-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では、最初のオクテットは、コマンド番号と呼ばれ、コマンド番号は、認識拡張メカニズムです。読者は、割り当てられた付加価値があったかどうかを判断するためにTWAMP - 制御コマンド番号レジストリに相談することをお勧めします。
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のコマンドの数値は、Request-TW-sessionコマンドを示し、サーバはTWAMPテストプロトコルを使用して双方向のテストセッションのための要求として、このコマンドを解釈しなければなりません。
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サーバが予期しないコマンド番号を受信した場合、それは受け入れ-セッションをメッセージに（「要求のいくつかの側面がサポートされていない」という意味）3に設定acceptフィールドで応じなければなりません。 （おそらくと予約されている番号）コマンド禁止されている数字は予想外です。
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では、コンファレンス-Senderフィールドが1に設定されています。メッセージは、セッションレシーバのための構成を説明するとき同様に、コンファレンス・レシーバフィールドが1に設定されています。 TWAMPでは、両方のエンドポイントは、送信とセッションSenderが最初に送信した後、最初に受信した後、送信セッション反射器によって補完テストパケットを受信して、テストパケットを受信します。
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.
ホストは、制御のためのTCP接続を開始するに係るカンファレンス-Senderフィールドとカンファレンスレシーバフィールドの両方は、両方の受信パケットを送信するセッション反射ので0に設定しなければなりません、そして役割が確立されています。サーバーが正しくフォーマットされたコマンドとしてゼロ以外の値を解釈しなければならない、とのAccept-セッションのメッセージで（「要求のいくつかの側面がサポートされていない」という意味）3に設定acceptフィールドで応じなければなりません。
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でのセッション・リフレクターは、着信パケットの数とそのタイミングスケジュールを知る必要はありません。その結果、パフォーマンスメトリックの着信テストパケットを処理していません。結果的にスケジュールスロットおよびパケット数の数は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
送信元ポートはTWAMP - テストパケットが送信され、ポートがどのTWAMP - テストパケットはで送信されますし、そこからUDPポートです
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).
セッションリフレクター（セッション-Senderがパケットを送受信するために、同じUDPポートを使用します）。受信ポートはTWAMP - テストパケットがセッションセンダ（セッションリフレクタがテストパケットを受信するように要求されるポート）によって送信されることが望まUDPポートです。受信ポートはTWAMPテストパケットがセッション反射鏡（セッション反射器がパケットを送受信するために同じUDPポートを使用する）によって送信されるから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.
送信者アドレス及び受信機アドレスフィールドは、それぞれ、TWAMP - テストセッションが要求される上に、インターネットパスのエンドポイントの送信者と受信者のアドレスを含みます。彼らは、サーバーTWAMP制御メッセージ交換にコントロールクライアントに使用するIPアドレスがテストパケットで使用する必要があり、その場合には、0に設定されるかもしれません。
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.
OWAMP [RFC4656]で定義されるように、セッション識別子（SID）があります。 SIDは、常に受信側によって生成されるので、サーバーはSIDを決定し、要求-TW-セッションメッセージにSIDを0に設定しなければなりません。
The Start Time is as defined in OWAMP [RFC4656].
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.
タイムアウトはOWAMP [RFC4656]で定義から異なって解釈されます。 TWAMPでは、タイムアウトは、セッションリフレクターはストップ・セッションのメッセージを受信した後に待機しなければならないことを間隔です。場合は輸送中、まだテストパケットがあり、彼らはストップ・セッションのメッセージの受信、次のタイムアウト期間内に到着した場合、セッションリフレクターは、それらを反映しなければなりません。セッションリフレクターはタイムアウトを超えて受信されたパケットを反映してはなりません。
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.
OWAMP [RFC4656]で定義されるように、タイプPの記述です。このフィールドの唯一の機能は、[RFC2474]で定義されるように差別化サービスコードポイント（DSCP）を設定することです。 DSCPの同じ値がセッション反射鏡で反射されたテストパケットで使用されなければなりません。
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.
何のスケジュールスロットの説明がないので、リクエスト-TW-セッションメッセージはMBZ（ゼロでなければならない）とHMAC分野によって完成されます。これは、Request-TW-sessionコマンドと呼ばれる一つの論理メッセージを、完了します。
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.
OWAMP [RFC4656]で定義されるようセッション反射は受け入れセッションのメッセージで各要求-TW-sessionコマンドに応答しなければなりません。場合フィールド= 0、TWAMP - テストパケットがセッション反射鏡に向かってセッション送信者によって送信されたポート先のポートフィールドを確認する（リピート）を受け入れます。つまり、[ポート]フィールドには、セッションリフレクターはセッション送信元からのパケットを受信することを期待するポート番号を示します。
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.
要求されたレシーバーポートが利用できない場合（例えば、ポート使用中）、セッションリフレクターのサーバーは、Portフィールドに、このセッションのために代替し、利用可能なポートを示唆しています。セッションセンダ代替ポートを受け入れる、または適切なパラメータを使用して新しいセッション要求メッセージを構成するいずれか。それ以外の場合は、コントロール・クライアントのサーバーは、セッションの拒否または失敗の他の形態を伝えるために受け入れるフィールドを使用し、代替ポートを示唆していなければなりません。この場合には、ポートフィールドはゼロに設定しなければなりません。
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に使用されていません。コントロールクライアントとセッション-送信者が自律的に送信スケジュールを決定してもよいです。セッションリフレクターは、可能な限り迅速にセッション-Senderに各テストパケットを返すべきです。
The procedure and guidelines for starting test sessions is the same as defined in Section 3.7 of OWAMP [RFC4656].
テストセッションを開始するための手順およびガイドラインはOWAMP [RFC4656]のセクション3.7で定義されたものと同じです。
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で定義されたものと同様です。ストップ・セッションコマンドは、コントロール・クライアントによって発行することができます。メッセージには、任意のセッション記述レコードを含むまたは範囲をスキップしてはなりません。メッセージが停止-sessionsコマンドを完了するために、単一のブロックHMACで終了します。 TWAMPストップセッションコマンドは、SIDを伝えていないので、それはすべてのセッションに適用される以前に要求し、Start-sessionsコマンドで開始。
Thus, the TWAMP Stop-Sessions command is constructed as follows:
次のようにこのように、TWAMPストップ・セッションのコマンドが構築されます。
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Above, the Command Number in the first octet (3) indicates that this is the Stop-Sessions command.
上記、最初のオクテットのコマンド番号（3）は、これがストップ-sessionsコマンドであることを示しています。
Non-zero Accept values indicate a failure of some sort. Zero values indicate normal (but possibly premature) completion. The full list of available Accept values is described in Section 3.3 of [RFC4656], "Values of the Accept Field".
非ゼロ値は、いくつかの並べ替えの失敗を示し受け入れます。ゼロ値は、正常な（しかしおそらく早期）完了したことを示します。使用可能な受け入れ値の完全なリストは、「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.
受け入れはゼロ以外の値を持っている場合は、このTWAMP - コントロールセッションによって生成されたすべてのTWAMP - テストセッションの結果は無効とみなされるべきです。受け入れ、セッションメッセージが（何らかの理由で、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.
セッション数が以前に停止-sessionsコマンドによって終了されていないコントロール、クライアントによって開始された送信セッションの数を含まなければならない（すなわち、コントロールクライアントは、各受け入れ要求 - セッションを考慮しなければなりません）。ストップ・セッションのメッセージが進行中のセッションの正確数を考慮していない場合、それは無効とみなされるべきであり、、TWAMP - コントロール接続をクローズする必要があり、かつ任意の結果が無効と見なさ得。
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 - コントロールストップセッションコマンドを受信すると、セッション反射鏡は、現在の時刻プラス（要求-TW-sessionコマンドで）タイムアウトに到達する任意TWAMPテストパケットを廃棄しなければなりません。
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つの目的は、双方向のメトリックの測定値です。双方向の測定方法は、このデータは、テストパケットを「反映」で伝達されるので、セッション反射鏡（例えば、シーケンス番号、タイムスタンプ、および生存時間（TTL）など）によって収集されるように、パケットレベルのデータを必要としません。このように、プロトコルは、サーバからのパケットレベルデータの検索を必要とせず、OWAMPフェッチセッションコマンドは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テストプロトコルは、セッション反射体は、それが受信した各テストパケットに応答して、セッションSenderにテストパケットを送信することを除いて、OWAMPテストプロトコル[RFC4656]と同様です。 TWAMPは、二つの異なるテストパケットフォーマット、セッション送信者及びセッション反射器によって送信されたパケットのための1つによって送信されたパケットのための1つを定義します。非認証、認証、および暗号化：OWAMPテストプロトコル[RFC4656]と同様に、3つのモードがあります。
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.
送信者の行動は、セッション送信者の構成によって決定され、この標準で定義されていません。さらに、セッション・リフレクターはOWAMP [RFC4656]で必要に応じて詳細度にセッション送信者の行動を知る必要はありません。また、セッション送信者は、双方向のメトリックを測定するためのセッション反射器によって送信されたパケットから提供される必要な情報を収集し、記録します。セッション送信者によって受信されたパケット（単数または複数）に基づいて、記録情報は実装依存です。
Since the send schedule is not communicated to the Session-Reflector, there is no need for a standardized computation of packet timing.
送信スケジュールはセッション反射鏡に伝達されないので、パケットタイミングの標準化された計算の必要はありません。
Regardless of any scheduling delays, each packet that is actually sent MUST have the best possible approximation of its real time of departure as its timestamp (in the packet).
かかわらず、任意のスケジュール遅延の、実際に送信される各パケットは、（パケットで）そのタイムスタンプとして出発そのリアルタイムの最良の近似値を持たなければなりません。
The 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).
（送信スケジュールを参照の例外を除いて）OWAMP [RFC4656]のセクション4.1.2で定義されるようセッションセンダパケットフォーマット及びコンテンツは、同じ手順およびガイドラインに従います。
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.
リフレクターテストパケットフォーマットは、送信者の形式よりも大きくなっていることに注意してください。セッションSenderは（これは通常望ましい）同じIPパケットのペイロード長が送信の各方向に使用されることを可能にするのに十分なパケットのパディングを追加してもよい（MAY）。反射の大きいテストパケットフォーマットを補償するために、送信者が認証されていないモードにおけるパディングの少なくとも27オクテット、および認証および暗号化モードで少なくとも56個のオクテットを追加します。
TWAMP requires the Session-Reflector to transmit a packet to the Session-Sender in response to each packet it receives.
TWAMPは、受信した各パケットに応じて、セッションSenderにパケットを送信するには、Session-リフレクターが必要です。
As packets are received, the Session-Reflector will do the following:
パケットが受信されると、セッション・リフレクターは、次の手順を実行します。
- 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).
- 受信したパケットをタイムスタンプ。実際に受信された各パケットは、到着のそのリアルタイムの最良の近似は、（パケットで）その受信タイムスタンプとして入力しておく必要があります。
- 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.
- 認証または暗号化モードでは、パケットボディ（暗号化のための認証、96オクテットのための最初のブロック（16オクテット））の適切なセクションを復号化し、次にHMACによって覆わセクションの整合性をチェックします。
- Copy the packet sequence number into the corresponding reflected packet to the Session-Sender.
- セッション送信者に対応する反射パケットにパケットシーケンス番号をコピーします。
- 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 /ホップ制限値からセンダTTL値を抽出します。セッションリフレクタ実装は、セッション送信者によって設定された255の値を置き換え、パケットのIPヘッダのTTL /ホップ制限値をフェッチすべきです。実装は、実際のTTL値を（そうするだけではなく、正当な理由が到着したパケットのTTLフィールドにアクセスすることができないことである）フェッチしていない場合、それは255として送信者のTTL値を設定しなければなりません。
- In authenticated and encrypted modes, the HMAC MUST be calculated first, then the appropriate portion of the packet body is encrypted.
- 認証と暗号化されたモードで、HMACは、パケット本体の適切な部分が暗号化されて、最初に計算しなければなりません。
- 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.
- すべての受信したパケットに応答して、セッションSenderにテストパケットを送信します。応答は、できるだけすぐに生成されなければなりません。試験パケットのフォーマット及びコンテンツはセクション4.2.1で定義されています。試験パケットの送信に先立って、セッションリフレクタは、（パケットで）タイムスタンプとしての実際の送信時間の最良の可能な近似値を入力する必要があります。これは、パケットの受信と送信の間の経過時間の決定を可能にします。
- 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.
- （ストップセッションコマンド以下）のタイムアウト内に受信されないパケットはリフレクターによって無視されなければなりません。セッションリフレクターは無視されたパケットのセッション-Senderにテストパケットを生成してはなりません。
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.
可能性は、セッション中にセッションセンダ障害のために存在する、またはテストセッションの進行中にセッションSenderとセッション反射鏡との間のパスが失敗する可能性があります。セッションリフレクターは、そのセッションに関連付けられたパケットがREFWAIT秒間受信していないときに開始されたすべてのセッションを中止することがあります。 REFWAITのデフォルト値は900秒であるものとし、この待機時間が設定可能であってもよいです。このタイムアウトは、セッションリフレクターは、障害が発生した場合のリソースを解放することができます。
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.
セッション反射は、受信した各パケットに応答して、セッション送信者にパケットを送信しなければなりません。セッションリフレクターは、できるだけすぐにパケットを送信する必要があります。セッションリフレクタ255にUDPパケットに（IPv6では又はホップ限界）IPv4の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.
テストパケットは、セッション送信者によって双方向のメトリックを計算するために必要な情報を持っています。試験パケットのフォーマットは、使用されるモードに依存します。二つのフォーマットは以下の通りです。
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
. .
. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
シーケンス番号は、その送信順序に従ってテストパケットのシーケンス番号です。それは、ゼロで始まり、後続の各パケットに対して1ずつインクリメントされます。セッションリフレクターによって生成されたシーケンス番号は、到着するパケットのシーケンス番号から独立しています。
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].
タイムスタンプとエラー推定は、それぞれの反射テストパケットのためのセッションリフレクターの送信タイムスタンプとエラー推定されています。すべてのタイムスタンプとエラー推定フィールドのフォーマットは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.
送信者のタイムスタンプとSender誤差推定値は、この試験パケットに対応して、セッション・送信者のテストパケットからのタイムスタンプとの誤差の推定値の正確なコピーです。
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.
セッション送信者が送信した際に送信者TTLは255です。セッション反射器によって送信された場合、送信者TTLは生存時間（またはホップ数）に設定されたIPパケットのヘッダから受信したパケットの値です。
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.
受信タイムスタンプがテストパケットをリフレクタにより受信した時刻です。タイムスタンプとタイムスタンプを受け取るとの違いは、パケットがセッションリフレクターで推移していた時間の量です。タイムスタンプフィールドに関連付けられた誤差推定はまた、受信タイムスタンプに適用されます。
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.
送信者シーケンス番号は、セッションリフレクターは、このテストパケットを生成して送信するために生じたセッションの送信者が送信したパケットのシーケンス番号のコピーです。
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フィールドは、Advanced Encryption Standard（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.
TWAMPテストのパケットパディングは、擬似ランダム（これは、独立して、本書に記載された任意の他の擬似乱数を生成しなければならない）であるべきです。しかし、実装は、設定パラメータ、オプション、またはパケットのパディングがすべてゼロで構成させる別の手段を提供しなければなりません。パケットパディングは、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.
セッション・反射テストパケットフォーマットは、送信者の形式よりも大きくなっていることに注意してください。十分なパディングが存在する場合にセッション反射鏡は、伝送の各方向に同じIPパケットペイロードの長さを達成するために、送信側のパケット・パディングの長さを減少させるはずです。 （パディング生成のための要件は、それぞれについて同じであるため）セッション反射鏡は、送信者のパケットのパディングを再使用してもよく、この場合にはセッション反射鏡は、最高数のオクテットが破棄されるようにパディングを切り捨てるべきです。
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テストパケットレイアウトは認証および暗号化モードで同一です。 [RFC4656]のOWAMPのセクション4.1.2で定義されているセッションセンダパケットの暗号化操作は、セッション送信元パケットの同じ規則に従います。
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はタイムスタンプがセッションリフレクターによって得られた場合、そのパケットが送信されるまでの時間を短縮することができます。タイムスタンプがフェッチされる前に、シーケンス番号は暗号化することができますので、これは潜在的に、タイムスタンプの精度を向上させることができます。
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テストセッションは、二つの鍵、AESセッションキー及びHMACセッションキーを有し、キーは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セッション鍵が得られる：（対応するTWAMP制御セッションのために使用したのと同じAESセッションキー）TWAMP - コントロールAESセッションキーを16オクテットのセッション識別子（SID）を使用して暗号化されキーとして、シングルブロックAES-ECB暗号化を使用しました。結果は、特定のTWAMP - テストセッションのパケットを暗号化（および復号化）で使用するTWAMPテストAESセッション鍵です。 TWAMP - テストAESセッションキー、TWAMP - コントロールAESセッションキー、および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セッション鍵（対応TWAMP制御セッションのために使用したのと同じHMACセッション鍵）を、AES-CBC（暗号ブロック連鎖）を使用して暗号化されている以下の通りTWAMPテストHMACセッション鍵を取得しますキーとして16オクテットのセッション識別子（SID）。これは、常にIV = 0で実行された2ブロックCBC暗号化です。 SIDは16オクテットであるながらTWAMPテストHMACセッション鍵とTWAMP - コントロールHMACセッションキーは、32個のオクテットで構成されていることに留意されたいです。
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電子コードブック（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セッションキーは、認証モードのためのキーと同じようにして得られています。各TWAMPテストパケットが一つだけ連鎖操作で、別々のストリームとして暗号化されています。 、紛失、重複、または並べ替えパケットが問題を起こさないように、連鎖は複数のパケットにまたがっていません。 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回設定する必要があります。
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の実装への指針として機能します。ここに示した例のアーキテクチャは必須ではありません。 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.
この例では、制御クライアントとセッション送信者の役割は、一つのホストに実装されているコントローラと呼ばれ、サーバとセッションリフレクタの役割は別のホストに実装されているレスポンダと呼びます。
controller responder
+-----------------+ +-------------------+
| Control-Client |<--TWAMP-Control-->| Server |
| | | |
| Session-Sender |<--TWAMP-Test----->| Session-Reflector |
+-----------------+ +-------------------+
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のセッションリフレクターの動作に従います。
Appendix I provides an example for purely informational purposes. It suggests an incremental path to adopting TWAMP, by implementing the TWAMP-Test protocol first.
付録Iは、純粋に情報提供の目的のために例を提供します。それは最初TWAMPテストプロトコルを実装することにより、TWAMPを採用するインクリメンタル経路を示唆しています。
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コントロールおよび試験手順の確立のために同じプロトコルを使用します。 TWAMPとOWAMPの主な違いは、OWAMPでのセッションレシーバ行動対TWAMPでセッションリフレクター動作です。この動作の違いは、すでに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 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.
（OWAMP、[RFC4656]のセクション3.1で定義された）サーバー挨拶メッセージは、共有秘密の鍵を生成するために、PKCS＃5で使用される反復カウンタを指定するカウント・フィールドを含みます。 OWAMPは、1024回の反復の下限が、無し上限をお勧めします。それは32ビット長であるため、Countフィールドは、サービス拒否（DoS）攻撃の機会を提供します。攻撃システムは、数（2 ** 32）の最大値を設定した場合、それは鍵を生成しようとしながら、次いで、攻撃対象のシステムは、かなりの時間のために停止になります。したがって、TWAMP準拠システムは、最大カウント値を制限するために、構成制御を有するべきです。 OWAMPで示唆したように、デフォルトの最大カウント値が32768であるべきで大きなコンピューティングパワーが共通になったときに、この値を増加させることができます。管理クライアントは、その最大値が設定されていることを大きなカウントを有するサーバグリーティングメッセージを受信した場合、制御接続を閉じる必要があります。
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.
我々は彼らのコメント、提案、レビュー、有益な議論、およびプルーフリーディングのために龍樹Venna、SHAREEマクナブ、ニックKinraid、スタニスラフ・シャルノブ、マット・Zekauskas、ウォルトSteverson、ジェフBOOTE、Murtaza千葉、そしてケビンEarnstに感謝したいと思います。ラースEggertの、サム・ハートマン、およびティムポークは非常に便利AD-レベルのレビューを拠出し、著者はメモへの貢献に感謝します。
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の双方向アクティブ測定プロトコル（TWAMP）コントロールTWAMP - コントロール862 / UDP双方向アクティブ測定プロトコル（TWAMP）コントロールナンバー[RFC5357]＃863から872まで割り当てられていません
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 - コントロールの仕様を超えて追加の制御コマンドを追加し、この制御コマンドを使用したときの動作を説明しているので、IANAはTWAMPコマンド番号フィールドのレジストリを作成しました。フィールドが明示的に[RFC4656]で指定されていないが、各コマンドのために呼ばれています。このフィールドはTWAMPのための認識拡張メカニズムです。
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 - 制御コマンド番号のレジストリを作成しました。 [RFC4656]のセクション3.5に示されており、この文書によって修正さTWAMP制御コマンドはOWAMP制御メッセージの最初のオクテットで指定されています。したがって、このレジストリは、16個の可能な値が含まれる場合があります。
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]の新しい値が範囲内で単調に増加する整数として割り当てられることを期待しています。
[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]実験及び試験のための値の適切な数を割り当てることをお勧めします。このスペースで有用であるかもしれない正確にどのように多くの数の作者に明確ではない、または彼らが容易に識別または番号の範囲の「ハイエンド」であったことが有用であろう場合。二つは役に立つかもしれない、セッション制御のための1、およびセッションのための1つのフェッチと言います。有用性が証明されていたら、メッセージの残りのフォーマットが行われ、他の番号の割り当てで、調整することが可能性があるため、一方、単一の数は、無制限の拡張を可能にするであろう。したがって、この文書は、実験とテストのために指定されたように、1つの数（6）を割り当てます。
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.
値説明セマンティクス定義0予約1禁断の2を起動し、セッションRFC 4656、セクション3.7 3ストップセッションRFC 4656、セクション3.8 4予約5要求-TW-セッションこのドキュメント、セクション3.5 6実験未定義、8.3節を参照してください。
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].
プロトコルは、UTF-8 [RFC3629、RFC5198]で符号化されTWAMP - コントロールにKeyIDを、の可能な例外を除いて、自然言語で情報を運びません。
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.
この例では、制御クライアント、サーバ、およびセッション・送信者の役割は、一つのホストに実装されているコントローラと呼ばれ、セッションリフレクタの役割は、別のホストに実装されているレスポンダと呼びます。
controller responder
+-----------------+ +-------------------+
| Server |<----------------->| |
| Control-Client | | Session-Reflector |
| Session-Sender |<--TWAMP-Test----->| |
+-----------------+ +-------------------+
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.
この例では、それらの役割は、単にネットワークの光テスト・ポイントとして機能することで応答するための単純なアーキテクチャを提供します。コントローラは、非標準的な手段を介してサーバとのテストセッションを確立します。セッションが確立された後、コントローラはレスポンダにテストパケットを送信します。以下の例外を除いてセクション4.2に記載したように、レスポンダはTWAMPのセッション反射挙動に従います。
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光の場合には、セッション・リフレクターは、必ずしもセッション状態の知識を持っていません。セッションリフレクターは、セッション状態の知識を持っていない場合は、セッション・リフレクターは、反射パケットのシーケンス番号フィールドに、受信したパケットのシーケンス番号をコピーしなければなりません。コントローラは、反射されたテストパケットを受信し、双方向のメトリックを収集します。このアーキテクチャは、双方向のメトリックの収集が可能になります。
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 - 制御プロトコルの必要性を排除し、そしてセッションリフレクターが設定され、非標準的な手段を介してサーバーとその設定を通信していることを前提としています。必要な情報をコピーし、セクション4.2.1あたりのシーケンス番号とタイムスタンプ値を生成しながら、セッション反射鏡は、単にバックコントローラに着信パケットを反映しています。 TWAMP光は、いくつかの追加のセキュリティの考慮事項を紹介します。応答を制御し、テストセッションを確立するために、非標準的な手段は、下記の機能を提供する必要があります。
The non-standard responder control protocol SHOULD have an authenticated mode of operation. The responder SHOULD be configurable to accept only authenticated control sessions.
非標準応答制御プロトコルは、動作の認証モードを有しているべきです。応答者は、認証制御セッションを受け入れるように構成可能であるべきです。
The non-standard responder control protocol SHOULD have a means to activate the authenticated and encrypted modes of the TWAMP-Test protocol.
非標準応答制御プロトコルはTWAMPテストプロトコルの認証および暗号化モードを活性化する手段を有するべきです。
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ライトテストセッションが認証または暗号化モードで動作する場合（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.、Teitelbaum、B.、カープ、A.、BOOTE、J.、およびM. Zekauskas、 "ワンウェイアクティブな測定プロトコル（OWAMP）"、RFC 4656、2006年9月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681] Almes、G.、Kalidindi、S.、およびM. Zekauskas、 "IPPMのラウンドトリップ遅延メトリック"、RFC 2681、1999年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[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問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J.とM. Padlipsky、 "ネットワークインターチェンジのUnicodeフォーマット"、RFC 5198、2008年3月。
Informative References
参考文献
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten氏、T.、 "役に立つと考えられ割り当て実験とテスト番号"、BCP 82、RFC 3692、2004年1月。
Authors' Addresses
著者のアドレス
Kaynam Hedayat Brix Networks 285 Mill Road Chelmsford, MA 01824 USA EMail: khedayat@brixnet.com URI: http://www.brixnet.com/
Kaynamヘダーヤトブリックスネットワーク285ミルロードチェルムズフォード、MA 01824 USA電子メール：khedayat@brixnet.com URI：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ウェストチェスターアベニュー。ホワイトプレーンズ、NY USA Eメール：roman.krzanowski@verizon.com URI：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 LabsのルームD3 - 3C06 200ローレルアベニュー。南ミドルタウン、NJ 07748 USA電話+1 732 420 1571 Eメール：acmorton@att.com URI：http://home.comcast.net/~acmacm/
Kiho Yum Juniper Networks 1194 Mathilda Ave. Sunnyvale, CA USA EMail: kyum@juniper.net URI: http://www.juniper.com/
紀宝ヨムジュニパーネットワークス1194マチルダアベニュー。サニーベールは、彼女にメールします：ウリक्यूँ@जुनिपर.नेटます。http：// vvvkjuniprkcom /
Jozef Z. Babiarz Nortel Networks 3500 Carling Avenue Ottawa, Ont K2H 8E9 Canada Email: babiarz@nortel.com URI: http://www.nortel.com/
ヨゼフZ. Babiarz Nortel Networksの3500カーリングアベニューオタワ、オンタリオK2H 8E9カナダEメール：babiarz@nortel.com URI：http://www.nortel.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。