[要約] RFC 4062は、OSPFベンチマーキングの用語と概念に関する情報を提供するものであり、OSPFのパフォーマンス評価と比較を目的としています。
Network Working Group V. Manral
Request for Comments: 4062 SiNett Corp.
Category: Informational R. White
Cisco Systems
A. Shaikh
AT&T Labs (Research)
April 2005
OSPF Benchmarking Terminology and Concepts
OSPFベンチマークの用語と概念
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document explains the terminology and concepts used in OSPF benchmarking. Although some of these terms may be defined elsewhere (and we will refer the reader to those definitions in some cases) we include discussions concerning these terms, as they relate specifically to the tasks involved in benchmarking the OSPF protocol.
このドキュメントでは、OSPFベンチマークで使用される用語と概念について説明します。これらの用語の一部は他の場所で定義される場合がありますが（そして、場合によってはこれらの定義を読者に紹介します）、これらの用語に関する議論は、特にOSPFプロトコルのベンチマークに関与するタスクに関連しているためです。
This document is a companion to [BENCHMARK], which describes basic Open Shortest Path First [OSPF] testing methods. This document explains terminology and concepts used in OSPF Testing Framework Documents, such as [BENCHMARK].
このドキュメントは[ベンチマーク]の仲間であり、基本的なオープン最短パス最初に[OSPF]テスト方法を説明します。このドキュメントでは、[ベンチマーク]などのOSPFテストフレームワークドキュメントで使用される用語と概念を説明しています。
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]. [RFC2119] key words in this document are used to ensure methodological control, which is very important in the specification of benchmarks. This document does not specify a network-related protocol.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [RFC2119]に記載されているように解釈される。[RFC2119]このドキュメントのキーワードは、ベンチマークの仕様において非常に重要な方法論的制御を確保するために使用されます。このドキュメントでは、ネットワーク関連のプロトコルを指定しません。
Definitions in this section are well-known industry and benchmarking terms that may be defined elsewhere.
このセクションの定義は、他の場所で定義される可能性のある有名な業界とベンチマーク用語です。
o White Box (Internal) Measurements
o ホワイトボックス（内部）測定
- Definition
- 意味
White box measurements are those reported and collected on the Device Under Test (DUT) itself.
ホワイトボックスの測定は、テスト中のデバイス（DUT）自体で報告および収集されたものです。
- Discussion
- 考察
These measurements rely on output and event recording, along with the clocking and time stamping available on the DUT itself. Taking measurements on the DUT may impact the actual outcome of the test, since it can increase processor loading, memory utilization, and timing factors. Some devices may not have the required output readily available for taking internal measurements.
これらの測定値は、DUT自体で利用可能なクロッキングとタイムスタンピングとともに、出力とイベントの記録に依存しています。DUTで測定を行うと、プロセッサの負荷、メモリ利用、およびタイミング要因が増加する可能性があるため、テストの実際の結果に影響を与える可能性があります。一部のデバイスでは、内部測定を行うために必要な出力を容易に利用できない場合があります。
Note: White box measurements can be influenced by the vendor's implementation of various timers and processing models. Whenever possible, internal measurements should be compared to external measurements to verify and validate them.
注：ホワイトボックスの測定は、さまざまなタイマーと処理モデルのベンダーの実装の影響を受ける可能性があります。可能な場合はいつでも、内部測定を外部測定と比較して、それらを検証および検証する必要があります。
Because of the potential for variations in collection and presentation methods across different DUTs, white box measurements MUST NOT be used as a basis for comparison in benchmarks. This has been a guiding principle of the Benchmarking Methodology Working Group.
さまざまなDUTでの収集方法とプレゼンテーション方法の変動の可能性があるため、ホワイトボックスの測定値をベンチマークの比較の基礎として使用してはなりません。これは、ベンチマーク方法論ワーキンググループの指針となっています。
o Black Box (External) Measurements
o ブラックボックス（外部）測定
- Definition
- 意味
Black box measurements infer the performance of the DUT through observation of its communications with other devices.
ブラックボックスの測定では、他のデバイスとの通信を観察することにより、DUTのパフォーマンスを推測します。
- Discussion
- 考察
One example of a black box measurement is when a downstream device receives complete routing information from the DUT, it can be inferred that the DUT has transmitted all the routing information available. External measurements of internal operations may suffer in that they include not just the protocol action times, but also propagation delays, queuing delays, and other such factors.
ブラックボックス測定の1つの例は、下流のデバイスがDUTから完全なルーティング情報を受信した場合、DUTが利用可能なすべてのルーティング情報を送信したと推測できます。内部操作の外部測定は、プロトコルのアクション時間だけでなく、伝播遅延、遅延、その他のそのような要因も含まれるという点で苦しむ可能性があります。
For the purposes of [BENCHMARK], external techniques are more readily applicable.
[ベンチマーク]の目的のために、外部の手法はより容易に適用可能です。
o Multi-device Measurements
o マルチデバイス測定
- Measurements assessing communications (usually in combination with internal operations) between two or more DUTs. Multi-device measurements may be internal or external.
- 2つ以上のDUTの間のコミュニケーション（通常は内部操作と組み合わせて）を評価する測定。マルチデバイス測定は、内部または外部である場合があります。
Terms in this section are defined elsewhere and are included only as they apply to [BENCHMARK].
このセクションの用語は他の場所で定義されており、[ベンチマーク]に適用される場合にのみ含まれています。
o Point-to-Point Links
o ポイントツーポイントリンク
- Definition
- 意味
See [OSPF], Section 1.2.
[OSPF]、セクション1.2を参照してください。
- Discussion
- 考察
A point-to-point link can take less time to converge than a broadcast link of the same speed because it does not have the overhead of DR election. Point-to-point links can be either numbered or unnumbered. However, in the context of [BENCHMARK] and [OSPF], the two can be regarded as the same.
ポイントツーポイントリンクは、選挙博士のオーバーヘッドがないため、同じ速度のブロードキャストリンクよりも収束に時間がかかる場合があります。ポイントツーポイントリンクには、番号が付けられていないか、数の数字ができません。ただし、[ベンチマーク]と[OSPF]のコンテキストでは、2つは同じと見なすことができます。
o Broadcast Link
o 放送リンク
- Definition
- 意味
See [OSPF], Section 1.2.
[OSPF]、セクション1.2を参照してください。
- Discussion
- 考察
The adjacency formation time on a broadcast link can be greater than that on a point-to-point link of the same speed because DR election has to take place. All routers on a broadcast network form adjacency with the DR and BDR.
放送リンクの隣接編成時間は、選挙博士が行われなければならないため、同じ速度のポイントツーポイントリンクでそれよりも大きくなる可能性があります。ブロードキャストネットワーク上のすべてのルーターは、DRおよびBDRとの隣接を形成します。
Asynchronous flooding also takes place through the DR. In the context of convergence, it may take more time for an LSA to be flooded from one DR-other router to another because the LSA first has to be processed at the DR.
非同期洪水もDRを介して行われます。Convergenceのコンテキストでは、LSAを最初にDRで処理する必要があるため、LSAが1つのDR-Otherルーターから別のルーターに浸水するのにもっと時間がかかる場合があります。
o Shortest Path First Execution Time
o 最短パス最初の実行時間
- Definition
- 意味
The time taken by a router to complete the SPF process, as described in [OSPF].
[OSPF]で説明されているように、SPFプロセスを完了するためにルーターがかかった時間。
- Discussion
- 考察
This does not include the time taken by the router to install routes in the forwarding engine.
これには、転送エンジンにルートを取り付けるためのルーターが取った時間は含まれません。
Some implementations may force two intervals, the SPF hold time and the SPF delay, between successive SPF calculations. If an SPF hold time exists, it should be subtracted from the total SPF execution time. If an SPF delay exists, it should be noted in the test results.
いくつかの実装は、SPFを保持する時間とSPF遅延の2つの間隔を強制的に強制する場合があります。SPF保持時間が存在する場合、総SPF実行時間から差し引く必要があります。SPF遅延が存在する場合、テスト結果に注意する必要があります。
- Measurement Units
- 測定単位
The SPF time is generally measured in milliseconds.
SPF時間は通常、ミリ秒で測定されます。
o Hello Interval
o こんにちは間隔
- Definition
- 意味
See [OSPF], Section 7.1.
[OSPF]、セクション7.1を参照してください。
- Discussion
- 考察
The hello interval must be the same for all routers on a network.
ハロー間隔は、ネットワーク上のすべてのルーターで同じでなければなりません。
Decreasing the hello interval can allow the router dead interval (below) to be reduced, thus reducing convergence times in those situations where the router dead interval's timing out causes an OSPF process to notice an adjacency failure. Further discussion of small hello intervals is given in [OSPF-SCALING].
ハロー間隔を減らすと、ルーターの死んだ間隔（下）を減らすことができ、ルーターの死んだインターバルのタイミングでOSPFプロセスが隣接障害に気付くような状況で収束時間を短縮することができます。小さなハロー間隔のさらなる議論は、[OSPFスケーリング]に記載されています。
o Router Dead Interval
o ルーターデッドインターバル
- Definition
- 意味
See [OSPF], Section 7.1.
[OSPF]、セクション7.1を参照してください。
- Discussion
- 考察
This is advertised in the router's Hello Packets in the Router-DeadInterval field. The router dead interval should be some multiple of the HelloInterval (perhaps 4 times the hello interval) and must be the same for all routers attached to a common network.
これは、ルーターの介入フィールドのルーターのハローパケットに宣伝されています。ルーターのデッド間隔は、HelloIntervalの複数（おそらくHello Hello間隔の4倍）である必要があり、共通ネットワークに接続されているすべてのルーターで同じでなければなりません。
A network is termed as converged when all the devices within the network have a loop-free path to each possible destination. However, because we are not testing network convergence but testing performance for a particular device within a network, this definition needs to be streamlined to fit within a single device view.
ネットワークは、ネットワーク内のすべてのデバイスが可能な各宛先へのループフリーパスを持っている場合に収束と呼ばれます。ただし、ネットワークの収束をテストするのではなく、ネットワーク内の特定のデバイスのパフォーマンスをテストしているため、この定義は単一のデバイスビュー内に収まるように合理化する必要があります。
In this case, convergence will mean the point in time when the DUT has performed all actions needed in order to react to the change in the topology represented by the test condition. For instance, an OSPF device must flood any new information it has received, rebuild its shortest path first (SPF) tree, and install any new paths or destinations in the local routing information base (RIB, or routing table).
この場合、収束は、テスト条件で表されるトポロジの変化に反応するために、DUTが必要なすべてのアクションを実行した時点を意味します。たとえば、OSPFデバイスは、受信した新しい情報をあふれさせ、最初に最短パス（SPF）ツリーを再構築し、ローカルルーティング情報ベース（リブ、またはルーティングテーブル）に新しいパスまたは目的地をインストールする必要があります。
Note that the word "convergence" has two distinct meanings: the process of a group of individuals meeting at the same place, and the process of an individual coming to the same place as an existing group. This work focuses on the second meaning of the word, so we consider the time required for a single device to adapt to a network change to be Single Router Convergence.
「収束」という言葉には、同じ場所で会う個人のグループのプロセスと、既存のグループと同じ場所に来る個人のプロセスという2つの異なる意味があることに注意してください。この作業は、単語の2番目の意味に焦点を当てているため、単一のデバイスが単一のルーター収束になるためにネットワークの変更に適応するのに必要な時間を考慮します。
This concept does not include the time required for the control plane of the device to transfer the information required to forward packets to the data plane. It also does not include the amount of time between when the data plane receives that information and when it is able to forward traffic.
この概念には、デバイスの制御プレーンがデータプレーンに転送するために必要な情報を転送するために必要な時間は含まれていません。また、データプレーンがその情報を受信したときとトラフィックを転送できる場合の間の時間は含まれません。
Obviously, there are several elements to convergence, even under the definition given above for a single device, including (but not limited to) the following:
明らかに、単一のデバイスについて上記の定義の下でも、以下を含む（ただし、これらに限定されない）、収束にはいくつかの要素があります。
o The time it takes for the DUT to pass the information about a network event on to its neighbors.
o DUTがネットワークイベントに関する情報を隣人に渡すのにかかる時間。
o The time it takes for the DUT to process information about a network event and to calculate a new Shortest Path Tree (SPT).
o DUTがネットワークイベントに関する情報を処理し、新しい最短パスツリー（SPT）を計算するのにかかる時間。
o The time it takes for the DUT to make changes in its local RIB reflecting the new shortest path tree.
o DUTが新しい最短のパスツリーを反映して地元のrib骨に変更を加えるのに時間がかかります。
A network event is an event that causes a change in the network topology.
ネットワークイベントは、ネットワークトポロジの変更を引き起こすイベントです。
o Link or Neighbor Device Up
o リンクまたはネイバーデバイスアップ
The time needed for an OSPF implementation to recognize a new link coming up on the device, to build any necessary adjacencies, to synchronize its database, and to perform all other actions necessary to converge.
OSPF実装がデバイスに表示される新しいリンクを認識し、必要な隣接を構築し、データベースを同期させ、収束に必要な他のすべてのアクションを実行するために必要な時間。
o Initialization
o 初期化
The time needed for an OSPF implementation to be initialized, to recognize any links across which OSPF must run, to build any needed adjacencies, to synchronize its database, and to perform other actions necessary to converge.
OSPFの実装を初期化するために必要な時間、OSPFが実行する必要があるリンクを認識し、必要な隣接を構築し、データベースを同期させ、収束に必要な他のアクションを実行するために必要な時間。
o Adjacency Down
o 隣接する
The time needed for an OSPF implementation to recognize a link down/adjacency loss based on hello timers alone, to propagate any information as necessary to its remaining adjacencies, and to perform other actions necessary to converge.
OSPFの実装に必要な時間は、ハロータイマーだけに基づいてリンクダウン/隣接する損失を認識し、残りの隣接に必要な情報を伝播し、収束に必要な他のアクションを実行します。
o Link Down
o リンクダウンします
The time needed for an OSPF implementation to recognize a link down based on layer 2-provided information, to propagate any information as needed to its remaining adjacencies, and to perform other actions necessary to converge.
OSPF実装がレイヤー2を提供する情報に基づいてリンクを認識し、必要に応じて残りの隣接に情報を伝播し、収束に必要な他のアクションを実行するために必要な時間。
This document does not modify the underlying security considerations in [OSPF].
このドキュメントは、[OSPF]の基礎となるセキュリティ上の考慮事項を変更しません。
The authors would like to thank Howard Berkowitz (hcb@clark.net), Kevin Dubray (kdubray@juniper.net), Scott Poretsky (sporetsky@avici.com), and Randy Bush (randy@psg.com) for their discussion, ideas, and support.
著者は、Howard Berkowitz（hcb@clark.net）、Kevin Dubray（kdubray@juniper.net）、Scott Poretsky（sporetsky@avici.com）、およびRandy Bush（randy@psg.com）に議論したいと思います。アイデア、サポート。
[BENCHMARK] Manral, V., White, R., and A. Shaikh, "Benchmarking Basic OSPF Single Router Control Plane Convergence", RFC 4061, April 2005.
[ベンチマーク] Manral、V.、White、R。、およびA. Shaikh、「ベンチマーク基本的なOSPFシングルルーター制御プレーンの収束」、RFC 4061、2005年4月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[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月。
[OSPF-SCALING] Choudhury, Gagan L., Editor, "Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance", Work in Progress, August 2003.
[OSPF-SCALING] Choudhury、Gagan L.、編集者、「特定のOSPFパケットと混雑回避の優先順位付けされた治療」、2003年8月、進行中の作業。
Authors' Addresses
著者のアドレス
Vishwas Manral, SiNett Corp, Ground Floor, Embassy Icon Annexe, 2/1, Infantry Road, Bangalore, India
Vishwas Manral、Sinett Corp、1階、大使館のアイコンAnnexe、2/1、India、Bangalore、India
EMail: vishwas@sinett.com
Russ White Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709
Russ White Cisco Systems、Inc。7025 Kit Creek Rd。研究トライアングルパーク、ノースカロライナ州27709
EMail: riw@cisco.com
Aman Shaikh AT&T Labs (Research) 180 Park Av, PO Box 971 Florham Park, NJ 07932
Aman Shaikh AT＆T Labs（Research）180 Park AV、PO Box 971 Florham Park、NJ 07932
EMail: ashaikh@research.att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
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 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。