[要約] RFC 7718は、OWAMPのためのレジストリに関する規格です。OWAMPは、ネットワークの性能測定を行うためのプロトコルであり、このRFCはそのレジストリの管理と利用方法を定義しています。目的は、OWAMPの実装と運用の一貫性を確保し、ネットワークの性能測定における信頼性と互換性を向上させることです。
Internet Engineering Task Force (IETF) A. Morton
Request for Comments: 7718 AT&T Labs
Updates: 4656 December 2015
Category: Standards Track
ISSN: 2070-1721
Registries for the One-Way Active Measurement Protocol (OWAMP)
One-Way Active Measurement Protocol（OWAMP）のレジストリ
Abstract
概要
This memo describes the registries for OWAMP -- the One-Way Active Measurement Protocol. The registries allow assignment of Mode bit positions and OWAMP Command numbers. Per this memo, IANA has established the registries for new features, called the OWAMP-Modes registry and the OWAMP Control Command Number registry. This memo updates RFC 4656.
このメモは、OWAMP（一方向アクティブ測定プロトコル）のレジストリーについて説明しています。レジストリは、モードビット位置とOWAMPコマンド番号の割り当てを可能にします。このメモに従って、IANAはOWAMP-ModesレジストリとOWAMP制御コマンド番号レジストリと呼ばれる新機能のレジストリを確立しました。このメモはRFC 4656を更新します。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7718.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7718で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations for OWAMP-Control Registries . . . . . . 3
3.1. Control Command Number Registry . . . . . . . . . . . . . 3
3.1.1. Registry Specification . . . . . . . . . . . . . . . 3
3.1.2. Registry Management . . . . . . . . . . . . . . . . . 3
3.1.3. Experimental Numbers . . . . . . . . . . . . . . . . 3
3.1.4. OWAMP-Control Command Numbers Initial Contents . . . 3
3.2. OWAMP-Modes . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.1. Registry Specification . . . . . . . . . . . . . . . 4
3.2.2. Registry Management . . . . . . . . . . . . . . . . . 4
3.2.3. Experimental Numbers . . . . . . . . . . . . . . . . 4
3.2.4. OWAMP-Modes Initial Contents . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
The One-Way Active Measurement Protocol (OWAMP) [RFC4656] was prepared to support measurements of metrics specified by the IP Performance Metrics (IPPM) working group in the IETF. The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is an extension of OWAMP. The TWAMP specification gathered wide review as it approached completion, and the by-products were several recommendations for new features in TWAMP. As a result, a registry of new features was established for TWAMP. However, there were no new features proposed for OWAMP until recently [RFC7717].
一方向アクティブ測定プロトコル（OWAMP）[RFC4656]は、IETFのIPパフォーマンスメトリック（IPPM）ワーキンググループによって指定されたメトリックの測定をサポートするために作成されました。双方向アクティブ測定プロトコル（TWAMP）[RFC5357]は、OWAMPの拡張です。 TWAMP仕様は完成に近づくにつれて幅広いレビューを集め、副産物はTWAMPの新機能に関するいくつかの推奨事項でした。その結果、TWAMPの新機能のレジストリが確立されました。ただし、最近まで[OWC]に提案された新しい機能はありませんでした[RFC7717]。
This memo establishes the needed registries for OWAMP and updates [RFC4656].
このメモは、OWAMPに必要なレジストリを確立し、[RFC4656]を更新します。
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]で説明されているように解釈されます。
The purpose and scope of this memo is to describe and request the establishment of registries for future OWAMP [RFC4656] extensions. IANA already administers the "Two-way Active Measurement Protocol (TWAMP) Parameters", and this request follows a similar form (with one exception identified below).
このメモの目的と範囲は、将来のOWAMP [RFC4656]拡張のためのレジストリの確立について説明し、要求することです。 IANAは「Two-way Active Measurement Protocol（TWAMP）Parameters」をすでに管理しており、このリクエストは同様の形式に従います（以下に示す1つの例外があります）。
This memo also provides the initial contents for the OWAMP registries.
このメモは、OWAMPレジストリの最初のコンテンツも提供します。
The OWAMP-Control protocol coordinates the measurement capability. All OWAMP-Control messages follow specifications defined in Section 3 of [RFC4656].
OWAMP-Controlプロトコルは、測定機能を調整します。すべてのOWAMP-Controlメッセージは、[RFC4656]のセクション3で定義された仕様に従います。
IANA has created an OWAMP-Control Command Number registry.
IANAはOWAMP-Controlコマンド番号レジストリを作成しました。
OWAMP-Control Commands follow specifications defined in Section 3.4 of [RFC4656].
OWAMP制御コマンドは、[RFC4656]のセクション3.4で定義された仕様に従います。
OWAMP-Control Command Numbers are specified in the first octet of OWAMP-Control-Client command messages consistent with Section 3 of [RFC4656]. There are a maximum of 256 command numbers.
OWAMP-Controlコマンド番号は、[RFC4656]のセクション3と一致するOWAMP-Control-Clientコマンドメッセージの最初のオクテットで指定されます。最大256個のコマンド番号があります。
Because the "OWAMP-Control Command Numbers" registry can contain only 256 values, and because OWAMP is an IETF protocol, these registries MUST be updated only by "IETF Review" as specified in [RFC5226] (an RFC that documents registry use and is approved by the IESG).
「OWAMP-Control Command Numbers」レジストリに含めることができる値は256のみであり、OWAMPはIETFプロトコルであるため、これらのレジストリは、[RFC5226]（レジストリの使用を文書化しているRFC IESGによって承認された）。
One experimental value is currently assigned in the Command Numbers Registry, as indicated in the initial contents below.
以下の最初の内容に示されているように、現在、1つの実験値がコマンド番号レジストリに割り当てられています。
OWAMP-Control Commands follows the procedure defined in Section 3.5 of [RFC4656] and in the remainder of Section 3 of that document.
OWAMP制御コマンドは、[RFC4656]のセクション3.5とそのドキュメントのセクション3の残りの部分で定義されている手順に従います。
The complete set of OWAMP-Control Command Numbers are as follows (including two reserved values):
OWAMP制御コマンド番号の完全なセットは次のとおりです（2つの予約値を含む）。
OWAMP-Control Command Numbers
OWAMP制御コマンド番号
Value Description Semantics Reference
Definition
==========================================================
0 Reserved Section 3.1.4 RFC 7718
1 Request-Session Section 3.5 RFC 4656
2 Start-Sessions Section 3.7 RFC 4656
3 Stop-Sessions Section 3.8 RFC 4656
4 Fetch-Sessions Section 3.9 RFC 4656
5-253 Unassigned
254 Experimentation Section 3.1.4 RFC 7718
255 Reserved Section 3.1.4 RFC 7718
IANA has created an OWAMP-Modes registry.
IANAはOWAMP-Modesレジストリを作成しました。
OWAMP-Modes are specified in OWAMP Server Greeting messages and Set-up Response messages consistent with Section 3.1 of [RFC4656]. Modes are currently indicated by setting single bits in the 32-bit Modes field. However, more complex encoding may be used in the future.
OWAMP-Modeは、[RFC4656]のセクション3.1に準拠するOWAMPサーバーグリーティングメッセージとセットアップ応答メッセージで指定されます。モードは現在、32ビットの[モード]フィールドに1ビットを設定することで示されます。ただし、より複雑なエンコーディングが将来使用される可能性があります。
Because the "OWAMP-Modes" are based on only 32 bit positions with each position conveying a unique feature, and because OWAMP is an IETF protocol, these registries MUST be updated only by "IETF Review" as specified in [RFC5226] (an RFC that documents registry use and is approved by the IESG). IANA SHOULD allocate monotonically increasing bit positions when requested.
「OWAMP-Modes」は32ビットの位置のみに基づいており、各位置は固有の機能を伝達するため、OWAMPはIETFプロトコルであるため、これらのレジストリは、[RFC5226]（RFC5226）で指定されている「IETF Review」によってのみ更新する必要があります。レジストリの使用を文書化し、IESGによって承認されています。 IANAは、要求されたときに単調に増加するビット位置を割り当てる必要があります（SHOULD）。
No experimental bit positions are currently assigned in the Modes registry, as indicated in the initial contents below.
以下の初期コンテンツに示されているように、現在、Modesレジストリには実験的なビット位置は割り当てられていません。
OWAMP-Control connection establishment follows the procedure defined in Section 3.1 of [RFC4656].
OWAMP-Control接続の確立は、[RFC4656]のセクション3.1で定義された手順に従います。
In the OWAMP-Modes registry, assignments are straightforward on the basis of bit positions, and there are no references to values -- this is a difference from the comparable TWAMP registry (and a topic for improvement in the TWAMP-Modes registry that is reconciled in [RFC7717]).
OWAMP-Modesレジストリでは、割り当てはビット位置に基づいて簡単であり、値への参照はありません-これは、比較可能なTWAMPレジストリ（および調整されたTWAMP-Modesレジストリの改善に関するトピック）との違いです[RFC7717]で）。
An extension of the OWAMP-Modes is proposed in [RFC7717]. With this extension, the complete set of OWAMP Mode bit positions are as follows (including one reserved bit position):
OWAMP-Modesの拡張は[RFC7717]で提案されています。この拡張により、OWAMPモードのビット位置の完全なセットは次のとおりです（1つの予約済みビット位置を含む）。
OWAMP-Modes
OWAMPモード
Bit Semantics
Pos. Description Definition Reference
=======================================================
0 Unauthenticated Section 3.1 RFC 4656
1 Authenticated Section 3.1 RFC 4656
2 Encrypted Section 3.1 RFC 4656
3 Reserved Section 3.2.4 RFC 7718
------------------------------------------------------
4 IKEv2-derived Shared Section 3.2.4 RFC 7718
Secret Key of RFC 7718,
Section 5 of RFC 7717
of RFC 7717
------------------------------------------------------
5-31 Unassigned
In the original OWAMP Modes field, setting bit position 0, 1, or 2 indicated the security mode of the Control protocol, and the Test protocol inherited the same mode (see Section 4 of [RFC4656]).
元のOWAMPモードフィールドで、ビット位置0、1、または2を設定すると、制御プロトコルのセキュリティモードが示され、テストプロトコルは同じモードを継承しました（[RFC4656]のセクション4を参照）。
The value of the Modes field sent by the Server in the Server-Greeting message is the bit-wise OR of the modes (bit positions) that it is willing to support during this session. Thus, the five least significant bits of the 32-bit Modes field are used. When no other features are activated, the 27 most significant bits MUST be zero. A Control-Client conforming to [RFC4656] MAY ignore the values in the 29 most significant bits of the Modes field, or it MAY support features that are communicated in other bit positions, such as the IKEv2-derived Shared Secret Key extension [RFC7717].
Server-Greetingメッセージでサーバーによって送信されたModesフィールドの値は、このセッション中にサポートしようとするモード（ビット位置）のビット単位のORです。したがって、32ビットのModesフィールドの最下位5ビットが使用されます。他の機能がアクティブになっていない場合、27の最上位ビットはゼロでなければなりません。 [RFC4656]に準拠するコントロールクライアントは、モードフィールドの最上位29ビットの値を無視してもよいし、IKEv2派生の共有秘密鍵拡張[RFC7717]などの他のビット位置で通信される機能をサポートしてもよい（MAY） 。
OWAMP and TWAMP registries for Modes may grow to contain different features and functions due to the inherent differences in one-way and two-way measurement configurations and the metrics they measure. No attempt will be made to coordinate them unnecessarily, except for the Reserved bit position 3 above. This is available for assignment if a mixed security mode similar to [RFC5618] is defined for OWAMP; it would allow alignment with the comparable TWAMP feature.
モードのOWAMPおよびTWAMPレジストリは、一方向および双方向の測定構成とそれらが測定するメトリックの固有の違いにより、異なる機能を含むように拡張する場合があります。上記の予約済みビット位置3を除いて、それらを不必要に調整する試みは行われません。これは、OWAMPに[RFC5618]と同様の混合セキュリティモードが定義されている場合に割り当てに使用できます。これにより、同等のTWAMP機能との調整が可能になります。
As this memo simply documents the creation of OWAMP registries, it presents no new security or privacy issues for the Internet.
このメモは単にOWAMPレジストリの作成を文書化しているだけなので、インターネットの新しいセキュリティやプライバシーの問題はありません。
The security considerations that apply to any active measurement of live networks are relevant here as well. See [RFC4656] and [RFC5357].
ライブネットワークのアクティブな測定に適用されるセキュリティの考慮事項は、ここでも関係があります。 [RFC4656]と[RFC5357]を参照してください。
Privacy considerations for measurement systems, particularly when Internet users participate in the tests in some way, are described in [RFC7594].
特にインターネットユーザーが何らかの方法でテストに参加する場合の測定システムのプライバシーに関する考慮事項は、[RFC7594]で説明されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://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, <http://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、<http://www.rfc-editor.org/info/rfc4656>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[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, <http://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、<http://www.rfc-editor.org/info/rfc5357>。
[RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, DOI 10.17487/RFC5618, August 2009, <http://www.rfc-editor.org/info/rfc5618>.
[RFC5618] Morton、A。およびK. Hedayat、「双方向アクティブ測定プロトコル（TWAMP）の混合セキュリティモード」、RFC 5618、DOI 10.17487 / RFC5618、2009年8月、<http：//www.rfc-editor .org / info / rfc5618>。
[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, <http://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月、<http://www.rfc-editor.org/info/rfc7594>。
[RFC7717] Pentikousis, K., Ed., Zhang, E., and Y. Cui, "IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)", RFC 7717, DOI 10.17487/RFC7717, December 2015, <http://www.rfc-editor.org/info/rfc7717>.
[RFC7717] Pentikousis、K.、Ed。、Zhang、E。、およびY. Cui、「一方向アクティブ測定プロトコル（OWAMP）および双方向アクティブ測定プロトコル（TWAMP）のIKEv2派生共有秘密鍵」 、RFC 7717、DOI 10.17487 / RFC7717、2015年12月、<http://www.rfc-editor.org/info/rfc7717>。
Acknowledgements
謝辞
The author would like to thank Kostas Pentikousis, Nalini Elkins, Mike Ackermann, and Greg Mirsky for insightful reviews and comments. We thought Spencer Dawkins caught the last of the small errors in his AD review, but Nevil Brownlee found a few more during OPS-DIR review. Roni Even found our use of "IETF Consensus" was out of date with [RFC5226]. Michelle Cotton helped to clarify the IANA considerations.
著者は、洞察に満ちたレビューとコメントを提供してくれたKostas Pentikousis、Nalini Elkins、Mike Ackermann、およびGreg Mirskyに感謝します。 Spencer Dawkinsが彼のADレビューで最後の小さなエラーをキャッチしたと思いましたが、Nevil BrownleeがOPS-DIRレビューでさらにいくつかを発見しました。 Roni Evenは、「IETF Consensus」の使用が[RFC5226]で古くなっていることを発見しました。ミシェルコットンは、IANAの考慮事項を明確にするのに役立ちました。
Author's Address
著者のアドレス
Al Morton AT&T Labs 200 Laurel Avenue South Middletown,, NJ 07748 United States
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
URI: http://home.comcast.net/~acmacm/