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
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 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）プロトコルに関して、単一ルータ制御プレーンのコンバージェンスを測定するための種々の試験の適用可能性を論じています。二つの一般的なセクションは、この文書であり、最初は、特定のOSPF収束テストの利点と制限について説明し、第二は、ルーティングプロトコルの収束をテストする際に考慮すべき、より一般的な落とし穴を説明します。
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.
ルーティングプロトコルのための単一のルータコントロールプレーンのコンバージェンスをテストし、多くの人々は、それが様々なネットワークイベントが発生した後に収束するネットワークのためにかかる時間についての情報を提供することができるテスト方法を見ているの関心が高まっています。 1つのフレームワークは結果に大きな影響を与える可能性があるため、試験の結果を適用しようとしたとき、任意の所与の収束テストが実行される枠組みを考慮することが重要です。例えば、ネットワークが収束している場合を決定、ルータの操作のどのような部分は、テスト内であると考えられる、およびその他のようなものは、ルーティングプロトコルが提供することが明らかにパフォーマンスに大きな影響を持つことになります。
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.
この文書では詳細に[BENCHMARK]に記載した試験の様々な利点と落とし穴を説明しています。また、このような測定は、プロバイダや研究コミュニティのためにどのように活用できるかを説明します。
NOTE: In this document, the word "convergence" refers to single router control plane convergence [TERM].
注：この文書では、用語「収束」とは、単一のルータ制御プレーンのコンバージェンス[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.
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].
研究者によってOSPFシミュレーションのパラメータとして使用されるように、O。研究の特定の種類は、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は、特定の設定可能なパラメータの最適化を支援します。事業者は、ネットワーク内のリソースの使用を最適化するために、個々のタスクに必要な遅延を知ることは、時には役に立つかもしれません。たとえば、ルータの処理時間は、ネットワークが過負荷にならないように役立つだろうそのルータにLSAをフラッディングする速度を決定し、x秒であることが判明した場合。
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であり;テストでは、制御プレーン内で発生するイベントに制限されています。パフォーマンスを転送する[INTERCONNECT]における主要な焦点であり、[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処理は、このように不正確な測定値を与え、実行されていないこと時間を含むであろう。 （[BENCHMARK]は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.
二つの異なるベンダーからOSPFの二つの異なる実装を比較するときにO [ベンチマーク]に記載の測定は、細心の注意を払って使用しなければなりません。例えば、異なるベンダーの製品を比較する際に考慮する必要が収束速度よりも他の多くの要因があります。一つの問題は、別の利用可能なリソースへの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.
実行するのが最も困難な試験は、トポロジー変化を示す第1の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計算の間に、2つの間隔、SPFホールド時間とSPF遅延を強制することができます。 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できるだけ早期にパケットのためのタイムスタンプを取るようにしてください。割り込みが処理されるときボックスで使用されているオペレーティングシステムに応じて、1缶楽器カーネルは、タイムスタンプを取ります。これは完全にノイズを除去するが、少なくともそれを軽減しません。
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は、測定にノイズを追加します。
4.3. Gaining an Understanding of the Implementation Improves Measurements
4.3. 実装の理解を得ることは測定を向上します
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.
[ベンチマーク]に記載の試験に精通するために使用することができる一つの方法は、すべての内部詳細が利用可能である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
注入のLSAで表される宛先の数O
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.
o The types of LSAs injected
注入されたLSAのタイプO
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.
o The number of LSAs injected
注入されたLSAの数O
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.
o The order of LSA injection
LSA注入の順序O
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.
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:
ダイクストラのアルゴリズムの複雑さは、ソースから現在の最小距離を有する頂点を記憶するために使用されるデータ構造に依存します。最も簡単な構造は、ソースから現在到達可能な頂点のリストです。頂点の単純なリストでは、最小コストの頂点を見つけることは、次にO（リストの大きさ）を取ります。我々は、すべての頂点が元から最終的に到達可能であることを前提とした場合にO（n）のような操作があります。また、最小のコストで頂点後の頂点のすべてのエッジを介して、アルゴリズムの反復を発見し、他の頂点のコストを更新します。隣接リスト表現と、このステップは、すべての頂点にわたって反復するとき、Eはグラフのエッジの数であると、O（E）時間がかかります。このように、全体の実行時間は次のとおりです。
O(sum(i:1, n)(size(list at level i) + E).
O（和（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
ルート| 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でリスト）= 1次に、端の頂点です。また、E = N - 1のため、実行時間はO（N）です。
If the graph is a balanced binary tree,
グラフは、平衡二分木である場合、
root / \ 1 2 / \ / \ 3 4 5 6
ルート/ \ 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ずつ増加し、我々は木は、その後、Kレベル（K 1）との完全なツリー（上記のように）、サイズ（であると仮定すれば、それは1だけダウンリストは）このようになります：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.
このようなツリー1.それは次に、実行時間はO（N ^ 2）であることが判明 - 次に、エッジEの数は依然としてnです。
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.
したがって、ネットワークを介して最良経路を計算するために使用される最短パス優先アルゴリズムの性能は、ツリーの構成に依存しています。任意のエミュレートされたネットワークを作ってみることであろうベストプラクティスは、特にツリーの深さ、ネットワークのmeshiness、トランジットリンク対スタブリンクの数、および数の領域に、可能な限り実際のネットワークのように見えます接続ノードは、元のツリー内の各レベルで処理します。
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。ポイントツーポイントリンクであればDUTと経路生成器との間には、ハブまたは他の装置が存在しないような高速イーサネットでエミュレートすることができ、リンクがOSPF [放送用内でポイントツーポイントリンクとして構成されています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.
論理的、現実的なトポロジーのように見えるのLSAのセットを作成する機能、O。例えば、発電機は、エミュレートされたトポロジ内のポイントツーポイント及び放送リンクの数を混合すると、外部から到達可能な目的地の変化数を注入することができなければなりません。
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.
ランダムにそれらがアドバタイズされるようにエミュレートされたトポロジーを表すLSAを注文する能力O。
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.
OSPF用のLSAが送信される速度を変更する能力O。
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.
ハワード・バーコウィッツ（hcb@clark.net）と彼らのサポートのために、この文書の必要性を実現ケビンDubray（kdubray@juniper.net）、へのBGPベンチマークチームの残りに感謝します。
[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月。
[TERM] Manral, V., White, R., and A. Shaikh, "OSPF Benchmarking Terminology and Concepts", RFC 4062, April 2005.
[TERM] Manral、V.、ホワイト、R.、およびA.シェイク、 "OSPFベンチマークの用語と概念"、RFC 4062、2005年4月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF]モイ、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.
、RFC 2544、1999年3月 "ネットワーク相互接続デバイスのためのベンチマーキング方法論" [相互接続]ブラドナー、S.とJ. McQuaid、。
[FIB-TERM] Trotter, G., "Terminology for Forwarding Information Base (FIB) based Router Performance", RFC 3222, December 2001.
[FIB-TERM]トロッター、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.
[放送P2P]シェン、Naimingら、「リンクステートルーティングプロトコルにおけるLAN経由ポイントツーポイント操作」、進歩、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機能のための基金は現在、インターネット協会によって提供されます。