[要約] 要約：RFC 4063は、基本的なOSPF収束ベンチマークを使用する際の考慮事項について説明しています。 目的：このRFCの目的は、ネットワークエンジニアがOSPFの収束時間を評価する際に考慮すべき要素を提供することです。
Network Working Group V. Manral
Request for Comments: 4063 SiNett Corp.
Category: Informational R. White
Cisco Systems
A. Shaikh
AT&T Labs (Research)
April 2005
Considerations When Using Basic OSPF Convergence Benchmarks
基本的な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 discusses the applicability of various tests for measuring single router control plane convergence, specifically in regard to the Open Shortest First (OSPF) protocol. There are two general sections in this document, the first discusses advantages and limitations of specific OSPF convergence tests, and the second discusses more general pitfalls to be considered when routing protocol convergence is tested.
このドキュメントでは、特にオープンで最短の最初（OSPF）プロトコルに関して、単一ルーター制御プレーンの収束を測定するためのさまざまなテストの適用性について説明します。このドキュメントには2つの一般的なセクションがあり、最初のセクションは特定のOSPF収束テストの利点と制限について説明し、2番目はルーティングプロトコルの収束をテストする際に考慮すべきより一般的な落とし穴について説明します。
There is a growing interest in testing single router control plane convergence for routing protocols, and many people are looking at testing methodologies that can provide information on how long it takes for a network to converge after various network events occur. It is important to consider the framework within which any given convergence test is executed when one attempts to apply the results of the testing, since the framework can have a major impact on the results. For instance, determining when a network is converged, what parts of the router's operation are considered within the testing, and other such things will have a major impact on the apparent performance that routing protocols provide.
ルーティングプロトコルの単一ルーター制御プレーンの収束をテストすることに関心が高まっており、多くの人が、さまざまなネットワークイベントが発生した後にネットワークが収束するのにかかる時間に関する情報を提供できるテスト方法論を検討しています。フレームワークは結果に大きな影響を与える可能性があるため、テストの結果を適用しようとするときに特定の収束テストが実行されるフレームワークを考慮することが重要です。たとえば、ネットワークがいつ収束されるか、ルーターの操作のどの部分がテスト内で考慮されるかを判断すると、そのようなことはルーティングプロトコルが提供する見かけのパフォーマンスに大きな影響を与えます。
This document describes in detail various benefits and pitfalls of tests described in [BENCHMARK]. It also explains how such measurements can be useful for providers and the research community.
このドキュメントでは、[ベンチマーク]で説明されているテストのさまざまな利点と落とし穴について詳しく説明しています。また、このような測定値がプロバイダーと研究コミュニティにとってどのように役立つかを説明しています。
NOTE: In this document, the word "convergence" refers to single router control plane convergence [TERM].
注：このドキュメントでは、「収束」という言葉は、単一のルーター制御平面収束[用語]を指します。
o To be able to compare the iterations of a protocol implementation. It is often useful to be able to compare the performance of two iterations of a given implementation of a protocol in order to determine where improvements have been made and where further improvements can be made.
o プロトコル実装の反復を比較できるようにします。多くの場合、プロトコルの特定の実装の2つの反復のパフォーマンスを比較して、改善がどこに行われたか、さらに改善できる場所を決定することができます。
o To understand, given a set of parameters (network conditions), how a particular implementation on a particular device will perform. For instance, if you were trying to decide the processing power (size of device) required in a certain location within a network, you could emulate the conditions that will exist at that point in the network and use the test described to measure the performance of several different routers. The results of these tests can provide one possible data point for an intelligent decision.
o 理解するために、一連のパラメーター（ネットワーク条件）を考えると、特定のデバイスでの特定の実装がどのように実行されるかを理解します。たとえば、ネットワーク内の特定の場所で必要な処理能力（デバイスのサイズ）を決定しようとしている場合、ネットワーク内のその時点で存在する条件をエミュレートし、説明したテストを使用してのパフォーマンスを測定することができます。いくつかの異なるルーター。これらのテストの結果は、インテリジェントな決定のための1つの可能なデータポイントを提供できます。
If the device being tested is to be deployed in a running network, using routes taken from the network where the equipment is to be deployed rather than some generated topology in these tests will yield results that are closer to the real performance of the device. Care should be taken to emulate or take routes from the actual location in the network where the device will be (or would be) deployed. For instance, one set of routes may be taken from an ABR, one set from an area 0 only router, various sets from stub area, another set from various normal areas, etc.
テストされているデバイスが実行中のネットワークに展開される場合、これらのテストで生成されたトポロジではなく、機器が展開されるネットワークから取得したルートを使用して、デバイスの実際のパフォーマンスに近い結果が得られます。デバイスが展開される（または展開される）ネットワーク内の実際の場所からエミュレートまたはルートを取るように注意する必要があります。たとえば、1つのルートのセットは、ABRから取得できます。1つのセットは、エリア0のみのルーター、スタブエリアからのさまざまなセット、さまざまな通常の領域からの別のセットなどです。
o To measure the performance of an OSPF implementation in a wide variety of scenarios.
o さまざまなシナリオでOSPF実装のパフォーマンスを測定するため。
o To be used as parameters in OSPF simulations by researchers. It may sometimes be required for certain kinds of research to measure the individual delays of each parameter within an OSPF implementation. These delays can be measured using the methods defined in [BENCHMARK].
o 研究者によるOSPFシミュレーションのパラメーターとして使用されます。OSPF実装内の各パラメーターの個々の遅延を測定するために、特定の種類の研究が必要になる場合があります。これらの遅延は、[ベンチマーク]で定義された方法を使用して測定できます。
o To help optimize certain configurable parameters. It may sometimes be helpful for operators to know the delay required for individual tasks in order to optimize the resource usage in the network. For example, if the processing time on a router is found to be x seconds, determining the rate at which to flood LSAs to that router would be helpful so as not to overload the network.
o 特定の構成可能なパラメーターを最適化するのに役立ちます。ネットワーク内のリソース使用を最適化するために、オペレーターが個々のタスクに必要な遅延を知ることができる場合があります。たとえば、ルーターの処理時間がx秒であることが判明した場合、ネットワークにオーバーロードしないように、そのルーターにLSAをあふれさせるレートを決定します。
o The interactions of convergence and forwarding; testing is restricted to events occurring within the control plane. Forwarding performance is the primary focus in [INTERCONNECT], and it is expected to be dealt with in work that ensues from [FIB-TERM].
o 収束と転送の相互作用。テストは、コントロールプレーン内で発生するイベントに制限されています。転送パフォーマンスは[相互接続]の主な焦点であり、[FIB-Term]から続く仕事で対処されることが期待されています。
o Duplicate LSAs are Acknowledged Immediately. A few tests rely on the property that duplicate LSA Acknowledgements are not delayed but are done immediately. However, if an implementation does not acknowledge duplicate LSAs immediately on receipt, the testing methods presented in [BENCHMARK] could give inaccurate measurements.
o 重複したLSAはすぐに認められます。いくつかのテストは、LSAの謝辞を重複させるプロパティに依存しています。ただし、実装がレシート時にすぐに重複したLSAを確認しない場合、[ベンチマーク]で提示されたテスト方法は、不正確な測定値を提供する可能性があります。
o It is assumed that SPF is non-preemptive. If SPF is implemented so that it can (and will be) preempted, the SPF measurements taken in [BENCHMARK] would include the times that the SPF process is not running, thus giving inaccurate measurements. ([BENCHMARK] measures the total time taken for SPF to run, not the amount of time that SPF actually spends on the device's processor.)
o SPFは非寛容であると想定されています。SPFが実装されています（および予約される）場合、[ベンチマーク]で取得したSPF測定には、SPFプロセスが実行されていない時間が含まれ、したがって不正確な測定値が得られます。（[ベンチマーク]は、SPFがデバイスのプロセッサに実際に費やす時間ではなく、SPFが実行するのにかかった合計時間を測定します。）
o Some implementations may be multithreaded or use a multiprocess/multirouter model of OSPF. If because of this any of the assumptions made during measurement are violated in such a model, measurements could be inaccurate.
o いくつかの実装は、マルチスレッドにされたり、OSPFのマルチプロセス/マルチリューターモデルを使用したりする場合があります。このため、測定中に行われた仮定のいずれかがそのようなモデルで違反されている場合、測定は不正確になる可能性があります。
o The measurements resulting from the tests in [BENCHMARK] may not provide the information required to deploy a device in a large-scale network. The tests described focus on individual components of an OSPF implementation's performance, and it may be difficult to combine the measurements in a way that accurately depicts a device's performance in a large-scale network. Further research is required in this area.
o [ベンチマーク]のテストから生じる測定では、大規模なネットワークにデバイスを展開するために必要な情報を提供しない場合があります。説明されているテストでは、OSPF実装のパフォーマンスの個々のコンポーネントに焦点を当てており、大規模なネットワークでのデバイスのパフォーマンスを正確に描写する方法で測定値を組み合わせることは困難な場合があります。この分野ではさらなる研究が必要です。
o The measurements described in [BENCHMARK] should be used with great care when comparing two different implementations of OSPF from two different vendors. For instance, there are many other factors than convergence speed that need to be taken into consideration when comparing different vendors' products. One difficulty is aligning the resources available on one device to the resources available on another.
o [ベンチマーク]で説明されている測定値は、2つの異なるベンダーとOSPFの2つの異なる実装を比較する場合、細心の注意を払って使用する必要があります。たとえば、さまざまなベンダーの製品を比較する際に考慮する必要がある収束速度以外の多くの要因があります。1つの難しさが、あるデバイスで利用可能なリソースを別のデバイスで利用可能なリソースに合わせることです。
Some observations recorded while implementing the tests described in [BENCHMARK] are noted in this section.
[ベンチマーク]で説明されているテストの実装中に記録されたいくつかの観察結果は、このセクションに記載されています。
The most difficult test to perform is the external measurement of the time required to perform an SPF calculation because the amount of time between the first LSA that indicates a topology change and the duplicate LSA is critical. If the duplicate LSA is sent too quickly, it may be received before the device being tested actually begins running SPF on the network change information. If the delay between the two LSAs is too long, the device may finish SPF processing before receiving the duplicate LSA. It is important to closely investigate any delays between the receipt of an LSA and the beginning of an SPF calculation in the tested device; multiple tests with various delays might be required to determine what delay needs to be used to measure the SPF calculation time accurately.
実行するのが最も難しいテストは、トポロジーの変化と重複LSAを示す最初のLSAの間の時間の量が重要であるため、SPF計算を実行するのに必要な時間の外部測定です。重複したLSAがあまりにも速く送信された場合、テストされるデバイスが実際にネットワーク変更情報でSPFの実行を開始する前に受信される場合があります。2つのLSA間の遅延が長すぎる場合、デバイスは重複したLSAを受信する前にSPF処理を完了する場合があります。LSAの受領と、テストされたデバイスでのSPF計算の開始との間の遅延を綿密に調査することが重要です。SPF計算時間を正確に測定するために使用する必要がある遅延を決定するために、さまざまな遅延を伴う複数のテストが必要になる場合があります。
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遅延が存在する場合、テスト結果に注意する必要があります。
The device on which measurements are taken (not the device being tested) also adds noise to the test results, primarily in the form of delay in packet processing and measurement output. The largest source of noise is generally the delay between the receipt of packets by the measuring device and the receipt of information about the packet by the device's output, where the event can be measured. The following steps may be taken to reduce this sampling noise:
測定値（テストされているデバイスではなく）が使用されるデバイスは、主にパケット処理と測定出力の遅延という形で、テスト結果にノイズを追加します。最大のノイズソースは、一般に、測定デバイスによるパケットの受領と、イベントを測定できるデバイスの出力によるパケットに関する情報の受領との間の遅延です。このサンプリングノイズを減らすために、次の手順を取ることができます。
o Increasing the number of samples taken will generally improve the tester's ability to determine what is noise, and to remove it from the results. This applies to the DUT as well.
o 採取されたサンプルの数を増やすと、一般に、ノイズとは何かを決定し、結果から削除するテスターの能力が向上します。これはDUTにも当てはまります。
o Try to take time-stamp for a packet as early as possible. Depending on the operating system being used on the box, one can instrument the kernel to take the time-stamp when the interrupt is processed. This does not eliminate the noise completely, but at least reduces it.
o できるだけ早くパケットのタイムスタンプを取るようにしてください。ボックスで使用されているオペレーティングシステムに応じて、中割り込みが処理されたときにタイムスタンプを取るようにカーネルを器具にすることができます。これはノイズを完全に排除するわけではありませんが、少なくともそれを減らします。
o Keep the measurement box as lightly loaded as possible. This applies to the DUT as well.
o 測定ボックスをできるだけ軽くロードしておきます。これはDUTにも当てはまります。
o Having an estimate of noise can also be useful.
o ノイズの見積もりを持つことも役立ちます。
The DUT also adds noise to the measurement.
DUTは測定にもノイズを追加します。
Although the tester will (generally) not have access to internal information about the OSPF implementation being tested using [BENCHMARK], the more thorough the tester's knowledge of the implementation is, the more accurate the results of the tests will be. For instance, in some implementations, the installation of routes in local routing tables may occur while the SPF is being calculated, dramatically impacting the time required to calculate the SPF.
テスターは（一般的に）[ベンチマーク]を使用してテストされているOSPF実装に関する内部情報にアクセスできませんが、実装に関するテスターの知識がより徹底的になるほど、テストの結果はより正確になります。たとえば、いくつかの実装では、SPFが計算されている間にローカルルーティングテーブルにルートのインストールが発生し、SPFの計算に必要な時間に劇的に影響を与えます。
One method that can be used to become familiar with the tests described in [BENCHMARK] is to perform the tests on an OSPF implementation for which all the internal details are available. Although there is no assurance that any two implementations will be similar, this will provide a better understanding of the tests themselves.
[ベンチマーク]で説明されているテストに精通するために使用できる1つの方法は、すべての内部詳細が利用可能なOSPF実装でテストを実行することです。2つの実装が類似しているという保証はありませんが、これはテスト自体をよりよく理解することができます。
In many OSPF benchmark tests, a generator injecting a number of LSAs is called for. There are several areas in which injected LSAs can be varied in testing:
多くのOSPFベンチマークテストでは、多数のLSAを注入するジェネレーターが求められています。注入されたLSAをテストで変化させることができるいくつかの領域があります。
o The number of destinations represented by the injected LSAs
o 注入されたLSAで表される目的地の数
Each destination represents a single reachable IP network; these will be leaf nodes on the shortest path tree. The primary impact to performance should be the time required to insert destinations in the local routing table and handling the memory required to store the data.
各宛先は、単一の到達可能なIPネットワークを表します。これらは、最短のパスツリーの葉のノードになります。パフォーマンスへの主な影響は、ローカルルーティングテーブルに目的地を挿入し、データを保存するのに必要なメモリを処理するのに必要な時間である必要があります。
o The types of LSAs injected
o 注入されたLSAのタイプ
There are several types of LSAs that would be acceptable under different situations; within an area, for instance, types 1, 2, 3, 4, and 5 are likely to be received by a router. Within a not-so-stubby area, however, type-7 LSAs would replace the type-5 LSAs received. These sorts of characterizations are important to note in any test results.
さまざまな状況で受け入れられるLSAにはいくつかのタイプがあります。たとえば、エリア内では、タイプ1、2、3、4、および5がルーターによって受信される可能性があります。ただし、それほどスタッバーではないエリア内では、タイプ7 LSAが受信したタイプ5 LSAを置き換えます。この種の特性は、テスト結果で注意することが重要です。
o The number of LSAs injected
o 注入されたLSAの数
Within any injected set of information, the number of each type of LSA injected is also important. This will impact the shortest path algorithm's ability to handle large numbers of nodes, large shortest path first trees, etc.
注入された情報セット内で、注入された各タイプのLSAの数も重要です。これは、多数のノード、最も短いパスファーストツリーなどを処理する最短経路アルゴリズムの能力に影響を与えます。
o The order of LSA injection
o LSA注射の順序
The order in which LSAs are injected should not favor any given data structure used for storing the LSA database on the device being tested. For instance, AS-External LSAs have AS wide flooding scope; any type-5 LSA originated is immediately flooded to all neighbors. However, the type-4 LSA, which announces the ASBR as a border router, is originated in an area at SPF time (by ABRs on the edge of the area in which the ASBR is). If SPF isn't scheduled immediately on the ABRs originating the type-4 LSA, the type-4 LSA is sent after the type-5 LSA's reach a router in the adjacent area. Therefore, routes to the external destinations aren't immediately added to the routers in the other areas. When the routers that already have the type 5s receive the type-4 LSA, all the external routes are added to the tree at the same time. This timing could produce different results than a router receiving a type 4 indicating the presence of a border router, followed by the type 5s originated by that border router.
LSAが注入される順序は、テスト対象のデバイス上にLSAデータベースを保存するために使用される特定のデータ構造を支持してはなりません。たとえば、外部LSAは幅広い洪水範囲を持っています。生まれたタイプ5 LSAは、すぐにすべての隣人に浸水します。ただし、ASBRを境界ルーターとして発表するType-4 LSAは、SPF時のエリア（ASBRの領域の端にあるABRによって）で発生します。SPFがタイプ4 LSAを発信するABRにすぐにスケジュールされていない場合、隣接する領域のタイプ5 LSAがルーターに到達した後、タイプ4 LSAが送信されます。したがって、外部宛先へのルートは、他の領域のルーターにすぐに追加されません。既にタイプ5を持っているルーターがタイプ4 LSAを受信すると、すべての外部ルートが同時にツリーに追加されます。このタイミングは、ボーダールーターの存在を示すタイプ4を受信するルーターとは異なる結果を生み出し、その後、そのボーダールーターが発信するタイプ5が続きます。
The ordering can be changed in various tests to provide insight into the efficiency of storage within the DUT. Any such changes in ordering should be noted in test results.
順序は、DUT内のストレージの効率性に関する洞察を提供するために、さまざまなテストで変更できます。注文のこのような変更は、テスト結果に注意する必要があります。
The complexity of Dijkstra's algorithm depends on the data structure used for storing vertices with their current minimum distances from the source; the simplest structure is a list of vertices currently reachable from the source. In a simple list of vertices, finding the minimum cost vertex would then take O(size of the list). There will be O(n) such operations if we assume that all the vertices are ultimately reachable from the source. Moreover, after the vertex with minimum cost is found, the algorithm iterates through all the edges of the vertex and updates the cost of other vertices. With an adjacency list representation, this step, when iterated over all the vertices, would take O(E) time, with E being the number of edges in the graph. Thus, the overall running time is:
Dijkstraのアルゴリズムの複雑さは、ソースからの現在の最小距離で頂点を保存するために使用されるデータ構造に依存します。最も単純な構造は、ソースから現在到達可能な頂点のリストです。頂点の単純なリストでは、最小コストの頂点を見つけると、O（リストのサイズ）が取得されます。すべての頂点が最終的にソースから到達可能であると仮定した場合、O（n）そのような操作があります。さらに、最小コストの頂点が見つかった後、アルゴリズムは頂点のすべてのエッジを繰り返し、他の頂点のコストを更新します。隣接するリストの表現を使用すると、このステップは、すべての頂点に繰り返されると、o（e）時間がかかり、eはグラフのエッジ数です。したがって、全体的な実行時間は次のとおりです。
O(sum(i:1, n)(size(list at level i) + E).
o（sum（i：1、n）（サイズ（レベルIのリスト）e）。
So everything boils down to the size(list at level i).
したがって、すべてがサイズに要約されます（レベルIのリスト）。
If the graph is linear,
グラフが線形の場合、
root
|
1
|
2
|
3
|
4
|
5
|
6
and source is a vertex on the end, then size(list at level i) = 1 for all i. Moreover, E = n - 1. Therefore, running time is O(n).
ソースは最後の頂点であり、すべてのiに対してサイズ（レベルIのリスト）= 1です。さらに、e = n -1。したがって、実行時間はo（n）です。
If the graph is a balanced binary tree,
グラフがバランスのとれたバイナリツリーの場合、
root
/ \
1 2
/ \ / \
3 4 5 6
size(list at level i) is a little complicated. First, it increases by 1 at each level up to a certain number, and then it goes down by 1. If we assume that the tree is a complete tree (as shown above) with k levels (1 to k), then size(list) goes on like this: 1, 2, 3,
サイズ（レベルIのリスト）は少し複雑です。まず、各レベルで特定の数値まで1回増加し、次に1倍になります。ツリーがkレベル（1〜K）の完全なツリー（上記のように）であると仮定した場合、サイズ（サイズ（）リスト）このように続きます：1、2、3、
Then the number of edges E is still n - 1. It then turns out that the run-time is O(n^2) for such a tree.
次に、エッジEの数はまだn -1です。その後、そのようなツリーの実行時間はo（n^2）であることがわかります。
If the graph is a complete graph (fully-connected mesh), then size(list at level i) = n - i. Number of edges E = O(n^2). Therefore, run-time is O(n^2).
グラフが完全なグラフ（完全に接続されたメッシュ）である場合、サイズ（レベルIのリスト）= n -i。エッジ数e = o（n^2）。したがって、実行時間はO（n^2）です。
Therefore, the performance of the shortest path first algorithm used to compute the best paths through the network is dependent on the construction of the tree. The best practice would be to try to make any emulated network look as much like a real network as possible, especially in the area of the tree depth, the meshiness of the network, the number of stub links versus transit links, and the number of connections and nodes to process at each level within the original tree.
したがって、ネットワークを介して最適なパスを計算するために使用される最短パス最初のアルゴリズムのパフォーマンスは、ツリーの構築に依存します。ベストプラクティスは、エミュレートされたネットワークを可能な限り実際のネットワークと同じように見せようとすることです。特に、ツリーの深さの領域、ネットワークの粘り気のある領域、スタブリンクの数とトランジットリンク、および元のツリー内の各レベルで処理する接続とノード。
As the size of networks grows, it becomes more and more difficult to actually create a large-scale network on which to test the properties of routing protocols and their implementations. In general, network emulators are used to provide emulated topologies that can be advertised to a device with varying conditions. Route generators tend to be either a specialized device, a piece of software which runs on a router, or a process that runs on another operating system, such as Linux or another variant of Unix.
ネットワークのサイズが大きくなるにつれて、ルーティングプロトコルとその実装のプロパティをテストするための大規模なネットワークを実際に作成することがますます困難になります。一般に、ネットワークエミュレーターは、さまざまな条件のあるデバイスに宣伝できるエミュレートトポロジを提供するために使用されます。ルートジェネレーターは、特殊なデバイス、ルーターで実行されるソフトウェアの一部、またはLinuxやUNIXの別のバリアントなどの別のオペレーティングシステムで実行されるプロセスのいずれかである傾向があります。
Some of the characteristics of this device should be as follows:
このデバイスの特性の一部は次のとおりです。
o The ability to connect to several devices using both point-to-point and broadcast high-speed media. Point-to-point links can be emulated with high-speed Ethernet as long as there is no hub or other device between the DUT and the route generator, and the link is configured as a point-to-point link within OSPF [BROADCAST-P2P].
o ポイントツーポイントとブロードキャスト高速メディアの両方を使用して複数のデバイスに接続する機能。Point-to-Pointリンクは、DUTとルートジェネレーターの間にハブや他のデバイスがない限り、高速イーサネットでエミュレートでき、リンクはOSPF内のポイントツーポイントリンクとして構成されています[Broadcast--p2p]。
o The ability to create a set of LSAs that appear to be a logical, realistic topology. For instance, the generator should be able to mix the number of point-to-point and broadcast links within the emulated topology and to inject varying numbers of externally reachable destinations.
o 論理的で現実的なトポロジーのように見えるLSAのセットを作成する能力。たとえば、発電機は、エミュレートトポロジ内のポイントツーポイントとブロードキャストリンクの数を混合し、さまざまな数の外部的に到達可能な目的地を注入できる必要があります。
o The ability to withdraw and add routing information into and from the emulated topology to emulate flapping links.
o エミュレートトポロジーにルーティング情報を引き出して追加して、羽ばたきリンクをエミュレートする機能。
o The ability to randomly order the LSAs representing the emulated topology as they are advertised.
o エミュレートトポロジが宣伝されているときにLSAをランダムに注文する能力。
o The ability to log or otherwise measure the time between packets transmitted and received.
o 送信されて受信したパケット間の時間を記録または測定する機能。
o The ability to change the rate at which OSPF LSAs are transmitted.
o OSPF LSAが送信される速度を変更する機能。
o The generator and the collector should be fast enough that they are not bottlenecks. The devices should also have a degree of granularity of measurement at least as small as is desired from the test results.
o 発電機とコレクターは、ボトルネックではないほど速くなければなりません。また、デバイスには、少なくともテスト結果から望まれるほど小さい測定の粒度がある必要があります。
This document does not modify the underlying security considerations in [OSPF].
このドキュメントは、[OSPF]の基礎となるセキュリティ上の考慮事項を変更しません。
Thanks to Howard Berkowitz (hcb@clark.net) and the rest of the BGP benchmarking team for their support and to Kevin Dubray (kdubray@juniper.net), who realized the need for this document.
Howard Berkowitz（hcb@clark.net）と残りのBGPベンチマークチームのサポートと、このドキュメントの必要性を認識したKevin Dubray（kdubray@juniper.net）に感謝します。
[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月。
[TERM] Manral, V., White, R., and A. Shaikh, "OSPF Benchmarking Terminology and Concepts", RFC 4062, April 2005.
[Term] Manral、V.、White、R。、およびA. Shaikh、「OSPF Benchmarking emerology and Concepts」、RFC 4062、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月。
[INTERCONNECT] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[Interconnect] Bradner、S。およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク方法論」、RFC 2544、1999年3月。
[FIB-TERM] Trotter, G., "Terminology for Forwarding Information Base (FIB) based Router Performance", RFC 3222, December 2001.
[FIB-Term] Trotter、G。、「情報ベース（FIB）ベースのルーターパフォーマンスのための用語」、RFC 3222、2001年12月。
[BROADCAST-P2P] Shen, Naiming, et al., "Point-to-point operation over LAN in link-state routing protocols", Work in Progress, August, 2003.
[Broadcast-P2P] Shen、Naiming、et al。、「Link-State Routing ProtocolsのLAN上のポイントツーポイント操作」、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、Infantry Road、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エディター機能の資金は現在、インターネット協会によって提供されています。