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
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).
著作権（C）インターネット協会（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]試験方法を説明し、[BENCHMARK]のコンパニオン、です。この文書では、このような[BENCHMARK]として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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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.
- 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.
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.
- 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.
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.
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.
o Broadcast Link
お Ｂろあｄかｓｔ ぃんｋ
- 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.
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を介して行わ。収束の文脈では、LSAが最初DRで処理されなければならないため、LSAは別のDR-他のルータからフラッディングするためのより多くの時間がかかることがあります。
o Shortest Path First Execution Time
O最短パス優先実行時間
- Definition
- 定義
The time taken by a router to complete the SPF process, as
described in [OSPF].
- 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計算の間に、2つの間隔、SPFホールド時間とSPF遅延を強制することができます。 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.
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）ツリーを再構築し、及びローカルルーティング情報ベース（RIB、またはルーティング・テーブル）内の任意の新しいパスまたは宛先をインストールしなければなりません。
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).
DUTは、ネットワークイベントについての情報を処理するために、新たな最短パスツリー（SPT）を計算するのにかかる時間、O。
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.
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.
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.
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.
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.
著者は、彼らの議論のためのハワード・バーコウィッツ（hcb@clark.net）、ケビンDubray（kdubray@juniper.net）、スコット・Poretsky（sporetsky@avici.com）、およびランディブッシュ（randy@psg.com）感謝したいと思いますアイデア、およびサポート。
[BENCHMARK] Manral, V., White, R., and A. Shaikh, "Benchmarking Basic OSPF Single Router Control Plane Convergence", RFC 4061, April 2005.
[BENCHMARK] Manral、V.、ホワイト、R.、およびA.シェイク、 "ベンチマークの基本的なOSPFシングルルータコントロールプレーンのコンバージェンス"、RFC 4061、2005年4月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF]モイ、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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スケーリング]チョードリー、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社、階、大使館アイコン別館、2/1、歩兵ロード、バンガロール、インド
EMail: vishwas@sinett.com
メールアドレス：vishwas@sinett.com
Russ White Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709
ラスホワイトシスコシステムズ株式会社7025キットクリークRdを。リサーチトライアングルパーク、NC 27709
EMail: riw@cisco.com
メールアドレス：riw@cisco.com
Aman Shaikh AT&T Labs (Research) 180 Park Av, PO Box 971 Florham Park, NJ 07932
アマンシェイクAT＆T Labs社（リサーチ）180公園のAv、私書箱971フローラムパーク、NJ 07932
EMail: ashaikh@research.att.com
メールアドレス：ashaikh@research.att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。