[要約] RFC 5357は、TWAMP（Two-Way Active Measurement Protocol）に関するプロトコルであり、ネットワークのパフォーマンス測定を可能にする。目的は、ネットワークの遅延、ジッタ、パケットロスなどのパフォーマンス指標を測定し、問題の特定とトラブルシューティングを支援すること。
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)
双方向アクティブ測定プロトコル（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に基づいた双方向アクティブ測定プロトコル（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）は、往復遅延[RFC2681]メトリックの提案された基準を完了しました。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ネットワークでは、双方向の測定値が一般的です。これは、主にローカルクロックとリモートクロック間の同期が往復遅延に不要であり、リモートエンドでの測定サポートが単純なエコー関数に制限される場合があるためです。ただし、往復測定の最も一般的な施設はICMPエコーリクエスト/返信（PINGツールで使用）であり、この方法の問題は[RFC2681]のセクション2.6に記載されています。このメモは、双方向アクティブ測定プロトコル（TWAMP）を指定します。Twampは、Owamp [RFC4656]の方法論とアーキテクチャを使用して、双方向または往復メトリックの測定のためのオープンなプロトコルを定義します（このドキュメントでは、双方向も往復を意味します）。Owampの方法メトリック。Twampは、Echo宛先（Reflector）に適用されたタイムスタンプを使用して、より高い精度を可能にします（処理遅延を考慮することができます）。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.
OWAMP [RFC4656]と同様に、TWAMPは、TWAMPコントロールとTWAMPテストの2つの相互関連プロトコルで構成されています。これらのプロトコルの関係は、OWAMP [RFC4656]のセクション1.1で定義されています。Twamp-Controlは、テストセッションを開始、開始、および停止するために使用されますが、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 [RFC4656]のセクション1.2で定義されています。
- 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.
- サーバーは、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.
- セッションリフレクターがフェッチするパケット情報を収集しないため、FAMPアーキテクチャにはフェッチクライアントエンティティは存在しません。その結果、フェッチクライアントの必要はありません。
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]のように、同じホストが異なる論理的役割を演奏できます。たとえば、上の図では、実際には2つのホストがいる可能性があります。1つはコントロールクライアントとセッションセンダーの役割を演奏し、もう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つの音節で発音されます。
The acronym TWAMP is also pronounced in two syllables, Tee-wamp.
頭字語Twampは、Tee-Wampの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:
双方向アクティブ測定プロトコルは、双方向メトリックを測定するためのオープンプロトコルです。これは、Owamp [RFC4656]に基づいており、Owampの全体的なアーキテクチャとデザインを順守しています。以下に概説するように、Twamp-ControlおよびTwamp-Testプロトコルは、テストタスクを達成します。
- 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-Clientは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-Controlメッセージを使用したテストセッションをリクエスト（および説明）します。サーバーは、その受け入れとサポート情報で応答します。追加のメッセージで複数のテストセッションが要求される場合があります。
- 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.
- 各アクティブセッションのTWAMPテストプロトコルに従って、セッションセンダーとセッションリフレクター交換テストパケット。
- When appropriate, the Control-Client sends a message to stop all test sessions.
- 必要に応じて、Control-Clientはすべてのテストセッションを停止するメッセージを送信します。
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-Control接続セットアップ中に通信オプションを確立するために使用されます。
2) The TWAMP-Control Command Number is another intended extension mechanism, allowing additional commands to be defined in the future.
2) Twamp-Controlコマンド番号は、別の意図された拡張メカニズムであり、将来追加のコマンドを定義できるようにします。
The TWAMP-Control protocol resolves different capability levels between the Control-Client and Server.
TWAMP-Controlプロトコルは、コントロールクライアントとサーバーの間で異なる機能レベルを解決します。
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-Controlは、双方向測定のためのOwamp-Controlの誘導体です。すべてのTwamp-Controlメッセージは形式が類似しており、以下のセクションで概説されている例外を除いて、Owamp [RFC4656]のセクション3で定義されているガイドラインと同様のガイドラインに従います。そのような例外の1つは、Twampでは使用されていないFetch-Sessionコマンドです。
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-Controlのよく知られているポート番号です。クライアントは、よく知られているポート862でサーバーへのTCP接続を開きます。TCP接続を開始するホストは、コントロールクライアントの役割と（2ホストの実装で）セッションセンダーの役割を担います。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).
Control-Clientは、特定の制御接続のすべてのパケットの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秒以内に受信されていない場合、確立された制御接続を中止する場合があります。サーバーは、StartSessionsコマンドを受信した後、監視制御接続アクティビティを一時停止し、StopSessionsコマンドを受け取った後に再開するものとします（ServWaitオプションがサポートされている場合）。RefWait Timeout（以下で説明）は、テストセッション中の障害をカバーし、RefWaitがTWAMPコントロール接続によって開始されたすべてのテストセッションで期限切れになった場合、Servwait Monitoringが再開されることに注意してください（まるでSTOPセッションコマンドが受信されたかのように）。ServWait Timeoutをサポートする実装も、RefWait Timeoutを実装する必要があります。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から同じマッピングを使用して共有された秘密を使用します。サーバーは、複数のクライアントとセッションを実施する準備をしているため、KeyIDSを使用して適切な秘密キーを選択します。クライアントは通常、異なるサーバーの異なる秘密キーを持っています。共有秘密はパスフレーズです。パスフレーズの相互運用性を最大化するには、[RFC5198]（ASCIIネットワーク仮想端子定義）の付録Bを使用して、パスフレーズ文字セットをエンコードする必要があります。NewLines（キャリッジリターン（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-Control接続の各ビットはHMACによって1回認証されます。
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.
サーバースタートメッセージ（初期コントロール接続交換中にサーバーによって送信される）は、HMACフィールドで終了しないことに注意してください。したがって、最初の受け入れセッションメッセージのHMACは、サーバースタートメッセージもカバーし、HMAC計算に開始時間フィールドを含みます。
Also, in authenticated and encrypted modes, the HMAC in TWAMP-Control packets is encrypted.
また、認証されたモードと暗号化されたモードでは、Twamp-Controlパケットの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).
次のコマンドは、コントロールクライアントのために利用できます：Request-TW-Session、StartSessions、およびStop-Sessions。サーバーは、受信するコマンドに応じて特定のメッセージを送信できます（以下のセクションで説明されています）。
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-SessionコマンドはTwamp Request-Tw-Sessionコマンドに置き換えられており、felt-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で定義されているのと同じ手順に従います。Request-TW-SessionコマンドはOWAMPリクエストセッションコマンドに基づいており、OWAMPのセクション3.5で説明されているメッセージ形式を使用しますが、スケジュールスロットの説明フィールドはありません。Request-TW-Session形式の説明は次のとおりです。
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-Controlコマンド番号レジストリを参照して、追加の値が割り当てられているかどうかを判断することをお勧めします。
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のコマンド番号値はリクエスト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サーバーが予期しないコマンド番号を受信した場合、Accept-Sessionメッセージで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では、リクエストセッションメッセージがサーバーが一方向のテストパケット送信者を構成するタスクを説明する場合、コンフセンダーフィールドは1に設定されます。同様に、メッセージがセッション受信者の構成を説明するときに、conf-receiverフィールドは1に設定されます。TWAMPでは、両方のエンドポイントがテストパケットを送信および受信し、セッションセンダーが最初に送信してからテストパケットを受信し、セッションリフレクターが最初に受信してから送信します。
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.
セッションリフレクターはパケットを受信および送信するため、Conf-SenderフィールドとConf-Receiverフィールドの両方を0に設定する必要があります。これは、ホストが制御のためにTCP接続を開始するホストに従って確立されます。サーバーは、ゼロ以外の値を不適切にフォーマットされたコマンドとして解釈する必要があり、受領メッセージの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 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).
送信者ポートは、Twamp-Testパケットが送信されるUDPポートであり、Twamp-Testパケットがセッションリフレクターによって送信されるポートです（セッションセンダーは同じUDPポートを使用してパケットを送信および受信します）。レシーバーポートは、セッションセンダー（セッションリフレクターがテストパケットの受信を求められるポート）によって送信される目的のUDPポートです。レシーバーポートは、Twamp-Testパケットがセッションリフレクターによって送信される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テストセッションが要求されているインターネットパスのエンドポイントの送信者と受信機のアドレスが含まれています。それらは0に設定される場合があります。その場合、Control-ClientからServer Twamp-Controlメッセージ交換に使用される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.
セッション識別子（SID）は、Owamp [RFC4656]で定義されています。SIDは常に受信側によって生成されるため、サーバーはSIDを決定し、Request-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では、タイムアウトは、セッションリフレクターがストップセッションメッセージを受信した後に待つ必要がある間隔です。テストパケットがまだ輸送中にある場合、Stop-Sessionsメッセージの受信後にタイムアウト間隔内に到着した場合、セッションリフレクターはそれらを反映する必要があります。セッションリフレクターは、タイムアウトを超えて受信されたパケットを反映してはなりません。
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]で定義されているように、差別化されたサービスコードポイント（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.
スケジュールスロットの説明がないため、Request-TW-SessionメッセージはMBZ（ゼロでなければならない）とHMACフィールドによって完了します。これにより、Request-Tw-Sessionコマンドと呼ばれる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.
セッションリフレクターは、OWAMP [RFC4656]で定義されているように、各リクエストツーセッションコマンドに受け入れセッションメッセージを使用して応答する必要があります。フィールド= 0を受け入れると、ポートフィールドは、セッションセンダーによってTwamp-Testパケットがセッションリフレクターに送信されるポートを確認します（繰り返し）。言い換えれば、ポートフィールドは、セッションリフレクターがセッションセンダーからパケットを受信すると予想されるポート番号を示します。
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.
要求されたレシーバーポートが利用できない場合（例：使用中のポートなど）、セッションリフレクターのサーバーは、ポートフィールドでのこのセッションの代替で利用可能なポートを提案する場合があります。セッションセンダーは、代替ポートを受け入れるか、適切なパラメーターを使用した新しいセッションリクエストメッセージを作成します。それ以外の場合、コントロールクライアントのサーバーは、受け入れフィールドを使用して、他の形式のセッション拒否または障害を伝達し、代替ポートを提案してはなりません。この場合、ポートフィールドはゼロに設定する必要があります。
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では使用されていません。コントロールクライアントとセッションセンダーは、送信スケジュールを自律的に決定する場合があります。セッションリフレクターは、各テストパケットをできるだけ早くセッションセンダーに返す必要があります。
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で定義されている手順と類似しています。停止セッションコマンドは、コントロールクライアントによってのみ発行されます。メッセージには、セッションの説明レコードやスキップ範囲を含めてはなりません。メッセージは、STOPSESSIONSコマンドを完了するために、単一のブロックHMACで終了します。Twamp Stop-SessionsコマンドはSIDSを伝えないため、以前にリクエストされたすべてのセッションに適用され、StartSessionsコマンドで開始されます。
Thus, the TWAMP Stop-Sessions command is constructed as follows:
したがって、Twamp Stop-Sessionsコマンドは次のように構築されます。
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）のコマンド番号は、これが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".
ゼロ以外の受け入れ値は、ある種の障害を示します。ゼロ値は、正常な（ただし早期）完了を示します。利用可能な受け入れ値の完全なリストは、[RFC4656]のセクション3.3で説明されています。「Acceptフィールドの値」。
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-Controlセッションによって生まれたすべてのTwampテストセッションの結果は無効と見なされるべきです。受け入れセッションメッセージがまったく送信されなかった場合（何らかの理由で、TWAMPコントロールに使用されるTCP接続の障害を含む）、このTwamp-Controlセッションによって生まれたすべてのTWAMPテストセッションの結果は無効と見なされる場合があります。
Number of Sessions indicates the number of sessions that the Control-Client intends to stop.
セッションの数は、コントロールクライアントが停止する意図があるセッションの数を示します。
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-Sessionsメッセージが進行中のセッションの数を正確に考慮していない場合、無効と見なされ、Twamp-Control接続を閉じ、得られた結果は無効と見なされます。
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-Control Stop-Sessionsコマンドを受信すると、セッションリフレクターは、現在の時刻とタイムアウト（リクエスト-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 Fetch-Sessionコマンドは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-TESTプロトコルは、セッションリフレクターが受信する各テストパケットに応じてテストパケットをセッションセンダーに送信することを除いて、OWAMP-TESTプロトコル[RFC4656]に似ています。Twampは、セッションセンダーによって送信されるパケット用の2つの異なるテストパケット形式と、セッションリフレクターによって送信されるパケット用の2つの異なるパケット形式を定義します。Owamp-Testプロトコル[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]で必要に応じて、セッションセンダーの動作を詳細に知る必要はありません。さらに、セッションセンダーは、2方向のメトリックを測定するためにセッションリフレクターによって送信されたパケットから提供される必要な情報を収集および記録します。セッションセンダーが受け取ったパケットに基づく情報記録は、実装に依存しています。
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.
リフレクターテストパケット形式は、送信者のフォーマットよりも大きいことに注意してください。セッションセンダーは、同じIPパケットペイロードの長さを各送信方向で使用できるように、十分なパケットパディングを追加することができます（これは通常望ましいことです）。リフレクターのより大きなテストパケット形式を補うために、送信者は、認証されたモードと暗号化されたモードで少なくとも27オクツのパディングを、少なくとも56オクテットのパディングを追加します。
TWAMP requires the Session-Reflector to transmit a packet to the Session-Sender in response to each packet it receives.
TWAMPは、受信する各パケットに応じてセッションセンダーにパケットを送信するためにセッションリフレクターが必要です。
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.
- 認証または暗号化されたモードでは、パケットボディの適切なセクション（認証された最初のブロック（16オクテット）、暗号化された96オクテット）を復号化し、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/HOP制限値から送信者TTL値を抽出します。セッション - リフレクターの実装は、パケットのIPヘッダーからTTL/ホップ制限値を取得し、セッションセンダーによって設定された255の値を置き換える必要があります。実装が実際のTTL値を取得しない場合（そうしない唯一の理由は、到着パケットのTTLフィールドにアクセスできないことです）、送信者TTL値を255として設定する必要があります。
- 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.
- 受信したすべてのパケットに応じて、テストパケットをセッションセンダーに送信します。応答はできるだけすぐに生成する必要があります。テストパケットの形式とコンテンツは、セクション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.
- タイムアウト内で受信されていないパケット（Stop-Sessionsコマンドに続く）は、リフレクターによって無視する必要があります。セッションリフレクターは、無視されているパケットのセッションセンダーにテストパケットを生成してはなりません。
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.
セッション中のセッションセンダーの故障、またはテストセッションの進行中にセッションセンダーとセッションリフレクターの間のパスが失敗する可能性があります。セッションリフレクターは、そのセッションに関連するパケットが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.
セッションリフレクターは、受信した各パケットに応じて、セッションセンダーにパケットを送信する必要があります。セッションリフレクターは、パケットをできるだけすぐに送信する必要があります。セッションリフレクターは、UDPパケットのIPv4（またはIPv6のホップ制限）にTTLを255に設定する必要があります。
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.
テストパケットには、セッションセンダーによる双方向メトリックを計算するために必要な情報があります。テストパケットの形式は、使用されているモードによって異なります。2つの形式を以下に示します。
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].
タイムスタンプとエラーの推定値は、それぞれ反射テストパケットのセッション - リフレクターの送信タイムスタンプとエラー推定値です。すべてのタイムスタンプとエラー推定フィールドの形式は、[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 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.
Sender TTLは、セッションセンダーから送信される場合は255です。Sender 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-TestパケットのHMACフィールドは、高度な暗号化標準（AES）暗号化と同じフィールドをカバーします。したがって、認証されたモードでは、HMACは最初のブロック（16オクテット）をカバーします。暗号化モードでは、HMACは最初の6ブロック（96オクテット）をカバーします。Twamp-Testでは、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-Testのパケットパディングは擬似ランダムでなければなりません（このドキュメントで言及されている他の擬似ランダム数とは無関係に生成する必要があります）。ただし、実装は、構成パラメーター、オプション、またはすべてのゼロで構成されるパケットパディングを作成する別の手段を提供する必要があります。パケットパディングは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-Testパケットレイアウトは、認証されたモードと暗号化されたモードで同じです。セッションセンダーパケットの暗号化操作は、[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.
認証モードでは、最初のブロックのシーケンス番号のみが暗号化され、その後のタイムスタンプとシーケンス番号は明確なテキストで送信されます。クリアテキストでタイムスタンプを送信すると、セッションリフレクターによってタイムスタンプが取得されるときからそのパケットが送信される時の間の時間を短縮できます。これにより、タイムスタンプの数字が取得される前にシーケンス番号を暗号化できるため、タイムスタンプの精度が向上する可能性があります。
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-Testセッションには、AESセッションキーとHMACセッションキーの2つのキーがあり、キーはTwamp-Controlキーと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-TEST AESセッションキーは次のように取得されます。TWAMP-Control AESセッションキー（対応するTWAMPコントロールセッションに使用されるのと同じAESセッションキー）は、16-OCTETセッション識別子（SID）で暗号化されています。キーとして、シングルブロックAES-ECB暗号化を使用します。その結果、特定のTwampテストセッションのパケットを暗号化（および復号化）する際に使用されるTwamp-Test AESセッションキーが得られます。Twamp-Test AESセッションキー、Twamp-Control 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-TEST HMAC SESSION-KEYは次のように取得されます。TWAMP-CONTROL HMAC SESSION-KEY（対応するTWAMP-Controlセッションに使用されるのと同じHMACセッションキー）は、AES-CBC（暗号ブロックチェーン）を使用して暗号化されます。キーとして16-OCTETセッション識別子（SID）。これは、iV = 0で常に実行される2ブロックのCBC暗号化です。Twamp-Test HMAC Session-Key-KeyおよびTwamp-Control HMAC Session-Keyは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セッションキーは、認証モードのキーと同じ方法で取得されます。各Twamp-Testパケットは、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回設定する必要があります。
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.
この例では、コントロールとセッションセンダーの役割はコントローラーと呼ばれる1つのホストに実装されており、サーバーとセッションリフェクターの役割はレスポンダーと呼ばれる別のホストに実装されます。
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の主な違いは、Twampでのセッション再フラフレクターの動作とOwampのセッションレシーバーの動作です。行動のこの違いは、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.
サーバーグリートメッセージ（[RFC4656]のセクション3.1で定義）には、共有シークレットからキーを生成するためにPKCS＃5で使用される反復カウンターを指定するカウントフィールドが含まれています。OWAMPは、1024回の反復の下限を推奨しますが、上限はありません。カウントフィールドは、32ビットの長さであるため、サービス拒否（DOS）攻撃の機会を提供します。攻撃システムがカウントで最大値を設定する場合（2 ** 32）、攻撃下のシステムは、キーを生成しようとする間、かなりの期間失速します。したがって、TWAMP準拠システムには、最大カウント値を制限する構成制御が必要です。デフォルトの最大カウント値は32768でなければなりません。OWAMPで示唆されているように、コンピューティングのパワーが一般的になると、この値が増加する場合があります。Control-ClientがCountの最大構成値よりも大きいサーバーグリートメッセージを受信すると、制御接続を閉じる必要があります。
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 McNab、Nick Kinraid、Stanislav Shalunov、Matt Zekauskas、Walt Steverson、Jeff Boote、Murtaza Chiba、およびKevin Earnstのコメント、提案、レビュー、役立つ議論、校正について感謝します。Lars Eggert、Sam Hartman、Tim Polkは非常に有用な広告レベルのレビューを提供し、著者はメモへの貢献に感謝します。
IANA has allocated a well-known TCP port number (861) for the OWAMP-Control part of the OWAMP [RFC4656] protocol.
IANAは、OWAMP [RFC4656]プロトコルのOwamp-Control部分によく知られているTCPポート番号（861）を割り当てました。
... owamp-control 861/tcp OWAMP-Control owamp-control 861/udp OWAMP-Control # [RFC4656]
... Owamp-Control 861/TCP Owamp-Control Owamp-Control 861/UDP Owamp-Control＃[RFC4656]
IANA has also allocated a well-known TCP/UDP port number for the TWAMP-Control protocol.
IANAはまた、TWAMP-Controlプロトコルによく知られている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-CONTROL 862/TCP双方向アクティブ測定プロトコル（TWAMP）制御TWAMP-CONTROL 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-Control仕様を超えて追加の制御コマンドを追加し、この制御コマンドを使用したときに動作を説明するため、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-Controlコマンド番号レジストリを作成しました。TWAMP-Controlコマンドは、[RFC4656]のセクション3.5に示すように、Owamp-Controlメッセージの最初のOctetによって指定され、このドキュメントで変更されます。したがって、このレジストリには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コンセンサス」によってのみ更新する必要があります。別の理由がない限り、新しい値は、範囲の範囲の単調に増加する整数[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]は、実験とテストに適切な数の値を割り当てることをお勧めします。著者には、このスペースで有用な数字の数が正確には明確ではありません。または、それらが簡単に区別できるか、数値範囲の「ハイエンド」で有用であるかどうかは明確ではありません。2つが役立つかもしれません。1つはセッションコントロール用、もう1つはセッションフェッチ用です。一方、メッセージの残りの形式を調整できるため、単一の数値は無制限の拡張機能を可能にします。したがって、このドキュメントには、実験とテストのために指定された1つの数字（6）が割り当てられます。
TWAMP-Control Command Number Registry
Twamp-Controlコマンド番号レジストリ
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.
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-ControlのKeyIDを例外として、自然言語で情報を伝えません。
Appendix I - TWAMP Light (Informative)
付録I -Twamp Light（有益な）
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.
この例では、コントロール、サーバー、およびセッションセンダーの役割は、コントローラーと呼ばれる1つのホストに実装され、セッションリフェクターの役割はレスポンダーと呼ばれる別のホストに実装されます。
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-Controlプロトコルの必要性を排除し、セッションリフレクターが構成されており、非標準的な手段を通じてサーバーとの構成を通知することを前提としています。セッションリフレクターは、必要な情報をコピーし、セクション4.2.1ごとにシーケンス番号とタイムスタンプの値を生成しながら、コントローラーに戻るパケットを単純に反映します。Twamp Lightは、いくつかの追加のセキュリティ上の考慮事項を紹介します。標準以外の手段では、応答者を制御し、テストセッションを確立することは、以下にリストされている機能を提供する必要があります。
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.、Karp、A.、Boote、J。、およびM. Zekauskas、「一元配置活動測定プロトコル（OWAM）」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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、「ネットワークインターチェンジのユニコード形式」、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 Hedayat Brix Networks 285 Mill Road Chelmsford、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/
Roman M. Krzanowski、博士Verizon 500 Westchester Ave. White Plains、NY NY USAメール：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/
Al Morton AT＆T Labs Room D3-3C06 200 Laurel Ave. South Middletown、NJ 07748 USA電話1 732 420 1571メール：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/
Kiho Yum Juniper Networks 1194 Mathilda Ave. Sunnyvale、Sunnyvale、USAメール：kyum@juniper.net uri：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/
Jozef Z. Babiarz Nortel Networks 3500 Carling Avenue Ottawa、ONT K2H 8E9カナダメール：babiarz@nortel.com URI：http：//www.nortel.com/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。