[要約] RFC 8545は、OWAMPとTWAMPのためのよく知られたポート割り当てに関する情報を提供しています。OWAMPとTWAMPは、ネットワークのアクティブな測定を行うためのプロトコルです。
Internet Engineering Task Force (IETF) A. Morton, Ed.
Request for Comments: 8545 AT&T Labs
Updates: 4656, 5357 G. Mirsky, Ed.
Category: Standards Track ZTE Corp.
ISSN: 2070-1721 March 2019
Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP)
一方向アクティブ測定プロトコル（OWAMP）および双方向アクティブ測定プロトコル（TWAMP）の既知のポート割り当て
Abstract
概要
This memo explains the motivation and describes the reassignment of well-known ports for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) for control and measurement. It also clarifies the meaning and composition of these Standards Track protocol names for the industry.
このメモは、動機を説明し、制御と測定のための1ウェイアクティブ測定プロトコル（OWAMP）と2ウェイアクティブ測定プロトコル（TWAMP）の既知のポートの再割り当てについて説明します。また、業界におけるこれらのスタンダードトラックプロトコル名の意味と構成を明確にします。
This memo updates RFCs 4656 and 5357, in terms of the UDP well-known port assignments, and it clarifies the complete OWAMP and TWAMP protocol composition for the industry.
このメモは、UDPウェルノウンポート割り当てに関してRFC 4656および5357を更新し、業界の完全なOWAMPおよびTWAMPプロトコル構成を明確にします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8545.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8545で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Scope ...........................................................3
4. Definitions and Background ......................................3
5. New Well-Known Ports ............................................5
5.1. Impact on TWAMP-Control Protocol ...........................5
5.2. Impact on OWAMP-Control Protocol ...........................6
5.3. Impact on OWAMP-Test/TWAMP-Test Protocols ..................6
6. Security Considerations .........................................7
7. IANA Considerations .............................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................9
Appendix A. Background on TWAMP Light .............................10
Acknowledgements ..................................................11
Contributors ......................................................11
Authors' Addresses ................................................11
The IETF IP Performance Metrics (IPPM) Working Group first developed the One-Way Active Measurement Protocol (OWAMP), as specified in [RFC4656]. Further protocol development to support testing resulted in the Two-Way Active Measurement Protocol (TWAMP), as specified in [RFC5357].
[RFC4656]で指定されているように、IETF IPパフォーマンスメトリック（IPPM）ワーキンググループは最初に一方向アクティブ測定プロトコル（OWAMP）を開発しました。テストをサポートするためのさらなるプロトコル開発の結果、[RFC5357]で指定されているように、双方向アクティブ測定プロトコル（TWAMP）が生まれました。
Both OWAMP and TWAMP require the implementation of a control and mode negotiation protocol (OWAMP-Control and TWAMP-Control) that employs the reliable transport services of TCP (including security configuration and key derivation). The control protocols arrange for the configuration and management of test sessions using the associated test protocol (OWAMP-Test or TWAMP-Test) on UDP transport.
OWAMPとTWAMPの両方で、TCPの信頼できるトランスポートサービス（セキュリティ構成とキーの派生を含む）を使用する制御およびモードネゴシエーションプロトコル（OWAMP-ControlおよびTWAMP-Control）の実装が必要です。制御プロトコルは、UDPトランスポートで関連するテストプロトコル（OWAMP-TestまたはTWAMP-Test）を使用して、テストセッションの構成と管理を行います。
The IETF recognizes the value of assigning a well-known UDP port to the OWAMP-Test and TWAMP-Test protocols and also recognizes that this goal can be easily arranged through port reassignments.
IETFは、既知のUDPポートをOWAMP-TestおよびTWAMP-Testプロトコルに割り当てることの価値を認識しており、この目標はポートの再割り当てによって簡単に調整できることも認識しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The scope of this memo is twofold: (1) to reallocate the well-known ports for the UDP test protocols that compose necessary parts of their respective Standards Track protocols (OWAMP and TWAMP) and (2) to clarify the meaning and composition of these Standards Track protocol names for the industry.
このメモの範囲は2つあります：（1）それぞれのStandards Trackプロトコル（OWAMPおよびTWAMP）の必要な部分を構成するUDPテストプロトコル用の既知のポートを再割り当てすること、および（2）これらの意味と構成を明確にすること標準業界のプロトコル名を追跡します。
This memo updates [RFC4656] and [RFC5357], in terms of the UDP well-known port assignments.
このメモは、UDPの既知のポート割り当てに関して、[RFC4656]と[RFC5357]を更新します。
This section defines key terms and clarifies the required composition of the OWAMP and TWAMP Standards Track protocols.
このセクションでは、主要な用語を定義し、OWAMPおよびTWAMP Standards Trackプロトコルの必要な構成を明確にします。
"OWAMP-Control" is the protocol defined in Section 3 of [RFC4656].
「OWAMP-Control」は、[RFC4656]のセクション3で定義されているプロトコルです。
"OWAMP-Test" is the protocol defined in Section 4 of [RFC4656].
「OWAMP-Test」は、[RFC4656]のセクション4で定義されているプロトコルです。
OWAMP is described in this direct quote from Section 1.1 of [RFC4656]: "OWAMP actually consists of two inter-related protocols: OWAMP-Control and OWAMP-Test." A similar sentence appears in Section 2 of [RFC4656]. For avoidance of doubt, the implementation of both OWAMP-Control and OWAMP-Test is REQUIRED for Standards Track OWAMP as specified in [RFC4656] (applying the consensus of many dictionary definitions of "consist").
OWAMPは、[RFC4656]のセクション1.1からのこの直接の引用で説明されています：「OWAMPは実際には、2つの相互に関連するプロトコル：OWAMP-ControlとOWAMP-Testで構成されています。」 [RFC4656]のセクション2にも同様の文があります。誤解を避けるために、[RFC4656]で指定されているように、標準トラックOWAMPにはOWAMP-ControlとOWAMP-Testの両方の実装が必要です（ "consist"の多くの辞書定義のコンセンサスを適用）。
"TWAMP-Control" is the protocol defined in Section 3 of [RFC5357].
「TWAMP-Control」は、[RFC5357]のセクション3で定義されているプロトコルです。
"TWAMP-Test" is the protocol defined in Section 4 of [RFC5357].
「TWAMP-Test」は、[RFC5357]のセクション4で定義されているプロトコルです。
TWAMP is described in this direct quote from Section 1.1 of [RFC5357]: "Similar to OWAMP [RFC4656], TWAMP consists of two inter-related protocols: TWAMP-Control and TWAMP-Test." For avoidance of doubt, the implementation of both TWAMP-Control and TWAMP-Test is REQUIRED for Standards Track TWAMP as specified in [RFC5357] (applying the consensus of many dictionary definitions of "consist").
TWAMPは、[RFC5357]のセクション1.1からのこの直接の引用で説明されています。誤解を避けるために、[RFC5357]で指定されているように、標準トラックTWAMPにはTWAMP-ControlとTWAMP-Testの両方の実装が必要です（「consist」の多くの辞書定義のコンセンサスを適用）。
"TWAMP Light" is an idea described in Appendix I ("TWAMP Light (Informative)") of [RFC5357]; TWAMP Light includes an unspecified control protocol combined with the TWAMP-Test protocol. In [RFC5357], the TWAMP Light idea was relegated to Appendix I because TWAMP Light failed to meet the requirements for IETF protocols (there are no specifications for negotiating this form of operation and no specifications for mandatory-to-implement security features), as described in Appendix A of this memo. See also [LarsAD] and [TimDISCUSS].
「TWAMP Light」は、[RFC5357]の付録I（「TWAMP Light（Informative）」）に記載されているアイデアです。 TWAMP Lightには、TWAMP-Testプロトコルと組み合わせた未指定の制御プロトコルが含まれています。 [RFC5357]では、TWAMP LightがIETFプロトコルの要件を満たせなかったため、TWAMP Lightのアイデアは付録Iに追いやられました（この形式の操作をネゴシエートするための仕様や、必須から実装までのセキュリティ機能の仕様はありません）。このメモの付録Aに記載されています。 [LarsAD]と[TimDISCUSS]も参照してください。
Since the idea of TWAMP Light clearly includes the TWAMP-Test component of TWAMP, it is considered reasonable for future systems to use the TWAMP-Test well-known UDP port (whose reallocated assignment is specified in this document). Clearly, the TWAMP Light idea envisions many components and communication capabilities beyond TWAMP-Test (implementing the security requirements, for example); otherwise, Appendix I of [RFC5357] would be one sentence long (equating TWAMP Light with TWAMP-Test only).
TWAMPライトのアイデアにはTWAMPのTWAMP-Testコンポーネントが明確に含まれているため、将来のシステムではTWAMP-Testの既知のUDPポート（再割り当ての割り当てはこのドキュメントで指定されています）を使用するのが妥当と考えられます。明らかに、TWAMP Lightのアイデアは、TWAMP-Test（セキュリティ要件の実装など）を超える多くのコンポーネントと通信機能を想定しています。それ以外の場合、[RFC5357]の付録Iは1文になります（TWAMP LightとTWAMP-Testのみを同等と見なします）。
Originally, both TCP and UDP well-known ports were assigned to the control protocols that are essential components of Standards Track OWAMP and TWAMP.
もともと、TCPとUDPの両方の既知のポートは、Standards Track OWAMPとTWAMPの必須コンポーネントである制御プロトコルに割り当てられていました。
Since OWAMP-Control and TWAMP-Control require TCP transport, they cannot make use of the UDP ports that were originally assigned. However, test sessions using OWAMP-Test or TWAMP-Test operate on UDP transport.
OWAMP-ControlとTWAMP-ControlはTCPトランスポートを必要とするため、最初に割り当てられたUDPポートを使用できません。ただし、OWAMP-TestまたはTWAMP-Testを使用したテストセッションは、UDPトランスポートで動作します。
Per this memo, IANA has reassigned the UDP well-known port from the control protocol to the test protocol (see Section 7 ("IANA Considerations")). The use of this UDP port is OPTIONAL in Standards Track OWAMP and TWAMP. It may simplify some operations to have a well-known port available for the test protocols or for future specifications involving TWAMP-Test to use this port as a default port. For example, [TR-390] is a specification for testing at the customer edge of IP networks, and conforming implementations will benefit from reallocation of the well-known UDP port to the test protocol.
このメモに従って、IANAはUDP既知のポートを制御プロトコルからテストプロトコルに再割り当てしました（セクション7（「IANAの考慮事項」）を参照）。このUDPポートの使用は、Standards Track OWAMPおよびTWAMPではオプションです。テストプロトコルまたはTWAMP-Testを含む将来の仕様でこのポートをデフォルトポートとして使用するための既知のポートを使用できるようにすると、一部の操作が簡略化される場合があります。たとえば、[TR-390]はIPネットワークの顧客エッジでのテストのための仕様であり、準拠する実装は、よく知られているUDPポートをテストプロトコルに再割り当てすることでメリットを得られます。
Section 3.5 of [RFC5357] describes the detailed process of negotiating the Receiver Port number, on which the TWAMP Session-Reflector will send and receive TWAMP-Test packets; see the quoted text below. The Control-Client, acting on behalf of the Session-Sender, proposes the Receiver Port number from the Dynamic Ports range [RFC6335]:
[RFC5357]のセクション3.5では、TWAMPセッションリフレクターがTWAMPテストパケットを送受信するレシーバーポート番号をネゴシエートする詳細なプロセスについて説明しています。以下の引用テキストを参照してください。 Control-Clientは、Session-Senderに代わって機能し、動的ポート範囲[RFC6335]からレシーバーポート番号を提案します。
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テストパケットがセッションセンダーによって送信される目的のUDPポートです（セッションリフレクターがテストパケットの受信を要求されるポート）。レシーバーポートは、TWAMPテストパケットがセッションリフレクターによって送信されるUDPポートでもあります（セッションリフレクターは、パケットの送受信に同じUDPポートを使用します）。
It is possible that the proposed Receiver Port may not be available, e.g., the port is in use by another test session or another application. In this case, we update the last paragraph of Section 3.5 of [RFC5357] per Erratum ID 1587 (see <https://www.rfc-editor.org/errata/eid1587>) as follows:
提案されたレシーバーポートが使用できない可能性があります。たとえば、ポートが別のテストセッションまたは別のアプリケーションで使用されている場合などです。この場合、エラータID 1587（<https://www.rfc-editor.org/errata/eid1587>を参照）に従って、[RFC5357]のセクション3.5の最後の段落を次のように更新します。
... the Server at the Session-Reflector MAY suggest an alternate and available port for this session in the Port field. The Control-Client either accepts the alternate port or composes a new Session-Request message with suitable parameters. Otherwise, the Server uses the Accept field to convey other forms of session rejection or failure to the Control-Client and MUST NOT suggest an alternate port; in this case, the Port field MUST be set to zero.
... Session-Reflectorのサーバーは、Portフィールドでこのセッションに使用可能な代替ポートを提案する場合があります。 Control-Clientは、代替ポートを受け入れるか、適切なパラメーターを使用して新しいSession-Requestメッセージを作成します。それ以外の場合、サーバーはAcceptフィールドを使用して、他の形式のセッション拒否または失敗をControl-Clientに伝え、代替ポートを提案してはなりません（MUST NOT）。この場合、Portフィールドはゼロに設定する必要があります。
A Control-Client that supports the use of the allocated TWAMP-Test Receiver Port (Section 7) MAY request to use that port number in the Request-TW-Session command. If the Server does not support the allocated TWAMP-Test Receiver Port, then it sends an alternate port number in the Accept-Session message with Accept field = 0. Thus, the deployment of the allocated TWAMP Receiver Port number is backward compatible with existing TWAMP-Control solutions that are based on [RFC5357]. Of course, using a UDP port number chosen from the Dynamic Ports range [RFC6335] will help avoid the situation where the Control-Client or Server finds that the proposed port is already in use.
割り当てられたTWAMPテストレシーバーポート（セクション7）の使用をサポートするコントロールクライアントは、Request-TW-Sessionコマンドでそのポート番号を使用するように要求できます。サーバーが割り当てられたTWAMPテストレシーバーポートをサポートしない場合、サーバーはAccept-SessionメッセージでAcceptフィールド= 0の代替ポート番号を送信します。したがって、割り当てられたTWAMPレシーバーポート番号の展開は既存のTWAMPと下位互換性があります-[RFC5357]に基づく制御ソリューション。もちろん、動的ポート範囲[RFC6335]から選択されたUDPポート番号を使用すると、提案されたポートがすでに使用されていることがControl-Clientまたはサーバーで検出される状況を回避できます。
As described above, an OWAMP-Control client that supports the use of the allocated OWAMP-Test Receiver Port (Section 7) MAY request to use that port number in the Request-Session command. If the Server does not support the allocated OWAMP-Test Receiver Port (or does not have the port available), then it sends an alternate port number in the Accept-Session message with Accept field = 0. Further exchanges proceed as already specified.
上記のように、割り当てられたOWAMP-Testレシーバーポート（セクション7）の使用をサポートするOWAMP-Controlクライアントは、Request-Sessionコマンドでそのポート番号を使用するように要求できます。サーバーが割り当てられたOWAMPテストレシーバーポートをサポートしていない場合（または使用可能なポートがない場合）、サーバーはAcceptフィールドが0のAccept-Sessionメッセージで代替ポート番号を送信します。以降の交換は既に指定されているとおりに行われます。
OWAMP-Test/TWAMP-Test may be used to measure IP performance metrics in an Equal-Cost Multipath (ECMP) environment. Though algorithms to balance IP flows among available paths have not been standardized, the most common is the five-tuple that uses destination IP address, source IP address, protocol type, destination port number, and source port number. When attempting to monitor different paths in an ECMP network, it is sufficient to vary only one of five parameters, e.g., the source port number. Thus, there will be no negative impact on the ability to arrange concurrent OWAMP/TWAMP test sessions between the same test points to monitor different paths in the ECMP network when using the reallocated UDP port number as the Receiver Port, as using the port is optional.
OWAMP-Test / TWAMP-Testは、等コストマルチパス（ECMP）環境でIPパフォーマンスメトリックを測定するために使用できます。使用可能なパス間でIPフローのバランスをとるアルゴリズムは標準化されていませんが、最も一般的なのは、宛先IPアドレス、送信元IPアドレス、プロトコルタイプ、宛先ポート番号、および送信元ポート番号を使用する5タプルです。 ECMPネットワーク内の異なるパスを監視する場合は、5つのパラメーター（送信元ポート番号など）の1つのみを変更するだけで十分です。したがって、ポートの使用はオプションであるため、再割り当てされたUDPポート番号をレシーバーポートとして使用する場合、ECMPネットワーク内の異なるパスを監視するために同じテストポイント間で同時にOWAMP / TWAMPテストセッションを配置する機能に悪影響はありません。 。
The security considerations that apply to any active measurement of live paths are relevant here as well (see [RFC4656] and [RFC5357]).
ライブパスのアクティブな測定に適用されるセキュリティの考慮事項は、ここでも関連があります（[RFC4656]および[RFC5357]を参照）。
When considering the privacy of those involved in measurement or those whose traffic is measured, the sensitive information available to potential observers is greatly reduced when using active techniques that are within this scope of work. Passive observations of user traffic for measurement purposes raise many privacy issues. We refer the reader to the security and privacy considerations described in the Large-Scale Measurement of Broadband Performance (LMAP) framework [RFC7594], which covers both active and passive techniques.
測定に関与している人やトラフィックが測定されている人のプライバシーを検討する場合、この作業範囲内のアクティブな手法を使用すると、潜在的な観察者が入手できる機密情報が大幅に減少します。測定目的でのユーザートラフィックの受動的な観察は、多くのプライバシー問題を引き起こします。アクティブとパッシブの両方の手法をカバーするブロードバンドパフォーマンスの大規模測定（LMAP）フレームワーク[RFC7594]で説明されているセキュリティとプライバシーの考慮事項について読者に説明します。
The registered UDP port as the Receiver Port for OWAMP-Test/ TWAMP-Test could become a target of denial of service (DoS) or could be used to aid man-in-the-middle (MITM) attacks. To improve protection against DoS, the following methods are recommended:
OWAMP-Test / TWAMP-Testのレシーバーポートとして登録されたUDPポートは、サービス拒否（DoS）のターゲットになるか、中間者（MITM）攻撃の支援に使用される可能性があります。 DoSに対する保護を強化するには、次の方法をお勧めします。
o filtering access to the OWAMP/TWAMP Receiver Port via an access list.
o アクセスリストを介したOWAMP / TWAMPレシーバーポートへのアクセスのフィルタリング。
o using a non-globally routable IP address for the OWAMP/TWAMP Session-Reflector address.
o OWAMP / TWAMP Session-ReflectorアドレスにグローバルにルーティングできないIPアドレスを使用する。
A MITM attacker may try to modify the contents of the OWAMP-Test/ TWAMP-Test packets in order to alter the measurement results. However, an implementation can use authenticated mode to detect modification of data. In addition, an implementation can use encrypted mode to prevent eavesdropping and undetected modification of the OWAMP-Test/TWAMP-Test packets.
MITM攻撃者は、測定結果を変更するために、OWAMP-Test / TWAMP-Testパケットの内容を変更しようとする可能性があります。ただし、実装では認証モードを使用してデータの変更を検出できます。さらに、実装は暗号化モードを使用して、OWAMP-Test / TWAMP-Testパケットの盗聴や検出されない変更を防ぐことができます。
There is also the risk of a network under test giving special treatment to flows involving the well-known UDP port, with or without knowing source and destination addresses of measurement systems, and thus biasing the results through preferential or detrimental processing.
また、テスト中のネットワークが、測定システムの送信元アドレスと宛先アドレスを知っているかどうかにかかわらず、既知のUDPポートを含むフローに特別な処理を与え、優先的または有害な処理によって結果にバイアスをかけるリスクもあります。
IANA has reallocated two UDP port numbers from the System Ports range of the "Service Name and Transport Protocol Port Number Registry" [RFC6335]. Specifically, IANA has reallocated UDP ports 861 and 862 as shown below, leaving the TCP port assignments as is. IANA has also updated the Assignee and Contact for these ports (both UDP and TCP) to be the IESG and the IETF Chair, respectively.
IANAは、「サービス名とトランスポートプロトコルのポート番号レジストリ」[RFC6335]のシステムポート範囲から2つのUDPポート番号を再割り当てしました。具体的には、IANAは、次に示すようにUDPポート861および862を再割り当てし、TCPポートの割り当てはそのままにします。 IANAは、これらのポート（UDPとTCPの両方）の担当者と連絡先をそれぞれIESGとIETF議長に更新しました。
+---------------+--------+-----------+------------------+-----------+
| Service | Port | Transport | Description | Reference |
| Name | Number | Protocol | | |
+---------------+--------+-----------+------------------+-----------+
| owamp-control | 861 | tcp | OWAMP-Control | RFC 4656 |
| owamp-test | 861 | udp | OWAMP-Test | RFC 8545 |
| | | | Receiver Port | |
| | | | | |
| twamp-control | 862 | tcp | TWAMP-Control | RFC 5357 |
| twamp-test | 862 | udp | TWAMP-Test | RFC 8545 |
| | | | Receiver Port | |
+---------------+--------+-----------+------------------+-----------+
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.
[RFC4656] Shalunov、S.、Teitelbaum、B.、Karp、A.、Boote、J。、およびM. Zekauskas、「A One-way Active Measurement Protocol（OWAMP）」、RFC 4656、DOI 10.17487 / RFC4656、9月2006、<https://www.rfc-editor.org/info/rfc4656>。
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.
[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A.、Yum、K。、およびJ. Babiarz、「A Two-Way Active Measurement Protocol（TWAMP）」、RFC 5357、DOI 10.17487 / RFC5357、10月2008、<https://www.rfc-editor.org/info/rfc5357>。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスタールンド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<https://www.rfc-editor.org/info/rfc6335>。
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, <https://www.rfc-editor.org/info/rfc7594>.
[RFC7594] Eardley、P.、Morton、A.、Bagnulo、M.、Burbridge、T.、Aitken、P。、およびA. Akhter、「ブロードバンドパフォーマンスの大規模測定（LMAP）のフレームワーク」、RFC 7594、DOI 10.17487 / RFC7594、2015年9月、<https://www.rfc-editor.org/info/rfc7594>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[IPPM-TWAMP-06] Hedayat, K., Krzanowski, R., Yum, K., Morton, A., and J. Babiarz, "A Two-way Active Measurement Protocol (TWAMP)", Work in Progress, draft-ietf-ippm-twamp-06, December 2007.
[IPPM-TWAMP-06] Hedayat、K.、Krzanowski、R.、Yum、K.、Morton、A.、J。Babiarz、「A Two-way Active Measurement Protocol（TWAMP）」、Work in Progress、draft -ietf-ippm-twamp-06、2007年12月。
[LarsAD] Eggert, L., "Subject: [ippm] AD review: draft-ietf-ippm-twamp-06.txt", message to the ippm mailing list, April 2008, <https://mailarchive.ietf.org/ rch/msg/ippm/LzcTPYhPhWhbb5-ncR046XKpnzo>.
[LarsAD] Eggert、L。、「件名：[ippm] ADレビュー：draft-ietf-ippm-twamp-06.txt」、ippmメーリングリストへのメッセージ、2008年4月、<https://mailarchive.ietf.org / rch / msg / ippm / LzcTPYhPhWhbb5-ncR046XKpnzo>。
[TimDISCUSS] "Tim Polk's Ballot discuss", July 2008, <https://datatracker.ietf.org/doc/rfc5357/history>.
[TimDISCUSS]「Tim Polkの投票について」、2008年7月、<https://datatracker.ietf.org/doc/rfc5357/history>。
[TR-390] Broadband Forum, "TR-390: Performance Measurement from IP Edge to Customer Equipment using TWAMP Light", Issue: 1, May 2017, <https://www.broadband-forum.org/technical/ download/TR-390.pdf>.
[TR-390]ブロードバンドフォーラム、「TR-390：IPエッジから顧客機器までのTWAMP Lightを使用したパフォーマンス測定」、問題：2017年5月1日、<https://www.broadband-forum.org/technical/ download / TR-390.pdf>。
This informative appendix provides the background on the decision to move the TWAMP Light idea to an informative appendix in [RFC5357].
この有益な付録は、TWAMPライトのアイデアを[RFC5357]の有益な付録に移動する決定の背景を提供します。
As also noted in Section 4, the TWAMP Light idea was relegated to Appendix I of [RFC5357] because it failed to meet the requirements for IETF protocols (there are no specifications for negotiating this form of operation and no specifications for mandatory-to-implement security features), as described in the references cited below:
セクション4でも述べたように、TWAMPライトのアイデアは、IETFプロトコルの要件を満たせなかったため、[RFC5357]の付録Iに追いやられました（この形式の操作をネゴシエートするための仕様や実装するための仕様はありません）セキュリティ機能）、以下に引用されている参考文献に記載されています：
o Lars Eggert's Area Director review [LarsAD], where he pointed out that having two variants of TWAMP (TWAMP Light and Complete TWAMP) requires a protocol mechanism to negotiate which variant will be used. Note that "Complete TWAMP" is called "Standards Track TWAMP" in this document. See Lars's "Section 5.2, paragraph 0" comment on [LarsAD], which refers to a section in [IPPM-TWAMP-06]. The working group consensus was to place the TWAMP Light description in Appendix I and to refer to that appendix only as an "incremental path to adopting TWAMP, by implementing the TWAMP-Test protocol first."
o Lars Eggertのエリアディレクターレビュー[LarsAD]は、TWAMPの2つのバリアント（TWAMP LightとComplete TWAMP）を使用するには、どのバリアントを使用するかをネゴシエートするためのプロトコルメカニズムが必要であることを指摘しました。このドキュメントでは、「Complete TWAMP」を「Standards Track TWAMP」と呼びます。 [IPPM-TWAMP-06]のセクションを参照する、Larsの[セクション5.2、段落0]の[LarsAD]に関するコメントを参照してください。ワーキンググループのコンセンサスは、TWAMPライトの説明を付録Iに置き、その付録を「最初にTWAMPテストプロトコルを実装することにより、TWAMPを採用するための増分パス」と呼ぶことでした。
o Tim Polk's "Ballot discuss" of 2008-07-16 [TimDISCUSS], which points out that TWAMP Light was an incomplete specification because the key required for authenticated and encrypted modes depended on the TWAMP-Control Session key. Additional requirement statements were added in Appendix I to address Tim's Ballot discuss (see the last three paragraphs of Appendix I in [RFC5357]).
o Tim Polkの2008-07-16 [TimDISCUSS]の「バロットディスカッション」は、認証および暗号化モードに必要なキーがTWAMP-Controlセッションキーに依存していたため、TWAMP Lightが不完全な仕様であったことを指摘しています。 Timの投票に関する議論に対処するために、追加の要件ステートメントが付録Iに追加されました（[RFC5357]の付録Iの最後の3つの段落を参照）。
Since the idea of TWAMP Light clearly includes the TWAMP-Test protocol and other undefined facilities, Appendix I of [RFC5357] simply describes ideas for how TWAMP-Test might be used outside of the context of Standards Track TWAMP.
TWAMP LightのアイデアにはTWAMP-Testプロトコルとその他の未定義の機能が明確に含まれているため、[RFC5357]の付録Iは、Standards Track TWAMPのコンテキスト外でTWAMP-Testを使用する方法についてのアイデアを簡単に説明しています。
Acknowledgements
謝辞
The authors thank the IPPM Working Group for their rapid review; thanks also to Muthu Arul Mozhi Perumal and Luay Jalil for their participation and suggestions.
著者は迅速なレビューをしてくれたIPPMワーキンググループに感謝します。また、Muthu Arul Mozhi PerumalとLuay Jalilの参加と提案に感謝します。
Contributors
貢献者
Richard Foote and Luis M. Contreras made notable contributions on this topic.
Richard FooteとLuis M. Contrerasがこのトピックについて注目すべき貢献をしました。
Authors' Addresses
著者のアドレス
Al Morton (editor) AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States of America
Al Morton（編集者）AT＆T Labs 200 Laurel Avenue South Middletown、NJ 07748アメリカ合衆国
Phone: +1 732 420 1571
Fax: +1 732 368 1192
Email: acmorton@att.com
Greg Mirsky (editor) ZTE Corp.
グレッグ・ミルスキー（編集者）ZTE Corp.
Email: gregimirsky@gmail.com