[要約] RFC 2544は、ネットワークインターコネクトデバイスのベンチマークテスト方法論を提供しています。その目的は、ネットワークデバイスの性能評価と比較を可能にすることです。
Network Working Group S. Bradner
Request for Comments: 2544 Harvard University
Obsoletes: 1944 J. McQuaid
Category: Informational NetScout Systems
March 1999
Benchmarking Methodology for Network Interconnect Devices
ネットワーク相互接続デバイスのベンチマーク方法論
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 (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
IESG Note
IESGノート
This document is a republication of RFC 1944 correcting the values for the IP addresses which were assigned to be used as the default addresses for networking test equipment. (See section C.2.2 ). This RFC replaces and obsoletes RFC 1944.
このドキュメントは、ネットワーキングテスト機器のデフォルトアドレスとして使用されるように割り当てられたIPアドレスの値を修正するRFC 1944の再公開です。（セクションc.2.2を参照）。このRFCは、RFC 1944を置き換えて廃止します。
Abstract
概要
This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. Appendix A lists the tests and conditions that we believe should be included for specific cases and gives additional information about testing practices. Appendix B is a reference listing of maximum frame rates to be used with specific frame sizes on various media and Appendix C gives some examples of frame formats to be used in testing.
このドキュメントでは、ネットワーク相互接続デバイスのパフォーマンス特性を説明するために使用できる多くのテストについて説明および定義します。テストの定義に加えて、このドキュメントでは、テストの結果を報告するための特定の形式についても説明しています。付録Aには、特定のケースに含めるべきだと思われるテストと条件をリストし、テストの実践に関する追加情報を提供します。付録Bは、さまざまなメディアで特定のフレームサイズで使用される最大フレームレートの参照リストであり、付録Cはテストで使用するフレーム形式の例をいくつか示します。
Vendors often engage in "specsmanship" in an attempt to give their products a better position in the marketplace. This often involves "smoke & mirrors" to confuse the potential users of the products.
ベンダーは、多くの場合、市場でより良い地位を提供しようとするために「スペックマンシップ」に従事します。これには、多くの場合、製品の潜在的なユーザーを混乱させる「煙と鏡」が含まれます。
This document defines a specific set of tests that vendors can use to measure and report the performance characteristics of network devices. The results of these tests will provide the user comparable data from different vendors with which to evaluate these devices.
このドキュメントでは、ベンダーがネットワークデバイスのパフォーマンス特性を測定および報告するために使用できる特定のテストセットを定義します。これらのテストの結果は、これらのデバイスを評価するためのさまざまなベンダーからのユーザーに比較可能なデータを提供します。
A previous document, "Benchmarking Terminology for Network Interconnect Devices" (RFC 1242), defined many of the terms that are used in this document. The terminology document should be consulted before attempting to make use of this document.
以前のドキュメント「ネットワーク相互接続デバイスのベンチマーク用語」（RFC 1242）は、このドキュメントで使用されている多くの用語を定義しました。このドキュメントを使用しようとする前に、用語文書に相談する必要があります。
In producing this document the authors attempted to keep in mind the requirement that apparatus to perform the described tests must actually be built. We do not know of "off the shelf" equipment available to implement all of the tests but it is our opinion that such equipment can be constructed.
このドキュメントを作成する際、著者は、説明されたテストを実行する装置を実際に構築する必要があるという要件を念頭に置いてみました。すべてのテストを実装するために利用可能な「棚から外れる」機器はわかりませんが、そのような機器を構築できるというのは私たちの意見です。
There are a number of tests described in this document. Not all of the tests apply to all types of devices under test (DUTs). Vendors should perform all of the tests that can be supported by a specific type of product. The authors understand that it will take a considerable period of time to perform all of the recommended tests nder all of the recommended conditions. We believe that the results are worth the effort. Appendix A lists some of the tests and conditions that we believe should be included for specific cases.
このドキュメントで説明されている多くのテストがあります。すべてのテストが、テスト中のすべてのタイプのデバイス（DUTS）に適用されるわけではありません。ベンダーは、特定の種類の製品でサポートできるすべてのテストを実行する必要があります。著者は、推奨されるすべての条件をすべてすべての推奨テストを実行するのにかなりの期間がかかることを理解しています。結果は努力する価値があると信じています。付録Aには、特定のケースに含まれるべきであると思われるテストと条件の一部をリストします。
Performing all of the recommended tests will result in a great deal of data. Much of this data will not apply to the evaluation of the devices under each circumstance. For example, the rate at which a router forwards IPX frames will be of little use in selecting a router for an environment that does not (and will not) support that protocol. Evaluating even that data which is relevant to a particular network installation will require experience which may not be readily available. Furthermore, selection of the tests to be run and evaluation of the test data must be done with an understanding of generally accepted testing practices regarding repeatability, variance and statistical significance of small numbers of trials.
推奨されるすべてのテストを実行すると、多くのデータが発生します。このデータの多くは、各状況下でのデバイスの評価には適用されません。たとえば、ルーターがIPXフレームを転送するレートは、そのプロトコルをサポートしていない（そしてしない）環境のルーターを選択するのにほとんど役に立たないでしょう。特定のネットワークインストールに関連するデータさえ評価するには、容易に利用できない場合の経験が必要です。さらに、実行するテストの選択とテストデータの評価は、少数の試験の再現性、分散、統計的有意性に関する一般的に受け入れられているテスト慣行を理解して行う必要があります。
In this document, the words that are used to define the significance of each particular requirement are capitalized. These words are:
このドキュメントでは、特定の各要件の重要性を定義するために使用される単語が大文字です。これらの言葉は次のとおりです。
* "MUST" This word, or the words "REQUIRED" and "SHALL" mean that the item is an absolute requirement of the specification.
* この単語、または「必要な」という言葉と「必要」と「「必要」と「」とは、項目が仕様の絶対的な要件であることを意味します。
* "SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
* 「この単語または形容詞」を推奨する「すべき」は、「特定の状況にはこの項目を無視するために正当な理由が存在する可能性があることを意味しますが、完全な意味を理解し、別のコースを選択する前にケースを慎重に検討する必要があります。
* "MAY" This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.
* この単語または形容詞「オプション」を「5月」と意味します。このアイテムが本当にオプションであることを意味します。1人のベンダーは、特定の市場に必要なものを必要とするため、またはたとえば製品を強化するため、アイテムを含めることを選択できます。別のベンダーは同じアイテムを省略する場合があります。
An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements. An implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be "conditionally compliant".
実装するプロトコルの要件の1つ以上を満たすことができない場合、実装は準拠していません。すべてのマストを満たす実装とそのプロトコルのすべての要件は、「無条件に準拠している」と言われています。すべての必須要件を満たすが、そのプロトコルのすべての要件が「条件付きに準拠している」と言われるものではない。
The ideal way to implement this series of tests is to use a tester with both transmitting and receiving ports. Connections are made from the sending ports of the tester to the receiving ports of the DUT and from the sending ports of the DUT back to the tester. (see Figure 1) Since the tester both sends the test traffic and receives it back, after the traffic has been forwarded but the DUT, the tester can easily determine if all of the transmitted packets were received and verify that the correct packets were received. The same functionality can be obtained with separate transmitting and receiving devices (see Figure 2) but unless they are remotely controlled by some computer in a way that simulates the single tester, the labor required to accurately perform some of the tests (particularly the throughput test) can be prohibitive.
この一連のテストを実装する理想的な方法は、送信ポートと受信ポートの両方でテスターを使用することです。接続は、テスターの送信ポートからDUTの受信ポートへのポートと、DUTの送信ポートからテスターに戻ります。（図1を参照）テスターは両方ともテストトラフィックを送信し、それを受け取るため、トラフィックが転送された後、テスターはすべての送信パケットを受信したかどうかを簡単に判断し、正しいパケットが受信されたことを確認できます。同じ機能を個別の送信および受信デバイスで取得できます（図2を参照）が、単一のテスターをシミュレートする方法で一部のコンピューターによってリモート制御されていない限り、テストの一部を正確に実行するために必要な労働（特にスループットテスト）禁止される可能性があります。
+------------+
| |
+------------| tester |<-------------+
| | | |
| +------------+ |
| |
| +------------+ |
| | | |
+----------->| DUT |--------------+
| |
+------------+
Figure 1
+--------+ +------------+ +----------+
| | | | | |
| sender |-------->| DUT |--------->| receiver |
| | | | | |
+--------+ +------------+ +----------+
Figure 2
Two different setups could be used to test a DUT which is used in real-world networks to connect networks of differing media type, local Ethernet to a backbone FDDI ring for example. The tester could support both media types in which case the set up shown in Figure 1 would be used.
2つの異なるセットアップを使用して、実際のネットワークで使用されるDUTをテストして、さまざまなメディアタイプ、ローカルイーサネットのネットワークをバックボーンFDDIリングに接続します。テスターは両方のメディアタイプをサポートできます。その場合、図1に示すセットアップが使用されます。
Two identical DUTs are used in the other test set up. (see Figure 3) In many cases this set up may more accurately simulate the real world. For example, connecting two LANs together with a WAN link or high speed backbone. This set up would not be as good at simulating a system where clients on a Ethernet LAN were interacting with a server on an FDDI backbone.
他のテストのセットアップでは、2つの同一のDUTが使用されます。（図3を参照）多くの場合、このセットアップは現実の世界をより正確にシミュレートする可能性があります。たとえば、2つのLANをWANリンクまたは高速バックボーンと一緒に接続します。このセットアップは、イーサネットLAN上のクライアントがFDDIバックボーンのサーバーと対話しているシステムをシミュレートするのにそれほど良くありません。
+-----------+
| |
+---------------------| tester |<---------------------+
| | | |
| +-----------+ |
| |
| +----------+ +----------+ |
| | | | | |
+------->| DUT 1 |-------------->| DUT 2 |---------+
| | | |
+----------+ +----------+
Figure 3
図3
Before starting to perform the tests, the DUT to be tested MUST be configured following the instructions provided to the user. Specifically, it is expected that all of the supported protocols will be configured and enabled during this set up (See Appendix A). It is expected that all of the tests will be run without changing the configuration or setup of the DUT in any way other than that required to do the specific test. For example, it is not acceptable to change the size of frame handling buffers between tests of frame handling rates or to disable all but one transport protocol when testing the throughput of that protocol. It is necessary to modify the configuration when starting a test to determine the effect of filters on throughput, but the only change MUST be to enable the specific filter. The DUT set up SHOULD include the normally recommended routing update intervals and keep alive frequency. The specific version of the software and the exact DUT configuration, including what functions are disabled, used during the tests MUST be included as part of the report of the results.
テストの実行を開始する前に、テスト対象のDUTは、ユーザーに提供された指示に従って構成する必要があります。具体的には、このセットアップ中にすべてのサポートされているプロトコルが構成および有効になることが予想されます（付録Aを参照）。すべてのテストは、特定のテストを行うために必要なもの以外のいかなる方法でも、DUTの構成またはセットアップを変更することなく実行されることが予想されます。たとえば、フレーム処理レートのテスト間のフレーム処理バッファーのサイズを変更したり、そのプロトコルのスループットをテストするときに1つの輸送プロトコルを除くすべてを無効にすることは許容できません。テストを開始するときに構成を変更してスループットに対するフィルターの効果を決定する必要がありますが、唯一の変更は特定のフィルターを有効にすることです。DUTのセットアップには、通常推奨されるルーティング更新間隔を含め、生存頻度を維持する必要があります。ソフトウェアの特定のバージョンと、テスト中に使用される機能を含む正確なDUT構成は、結果のレポートの一部として含める必要があります。
The formats of the test frames to use for TCP/IP over Ethernet are shown in Appendix C: Test Frame Formats. These exact frame formats SHOULD be used in the tests described in this document for this protocol/media combination and that these frames will be used as a template for testing other protocol/media combinations. The specific formats that are used to define the test frames for a particular test series MUST be included in the report of the results.
イーサネット上のTCP/IPに使用するテストフレームの形式は、付録C：テストフレーム形式に示されています。これらの正確なフレーム形式は、このプロトコル/メディアの組み合わせのためにこのドキュメントで説明されているテストで使用する必要があり、これらのフレームは他のプロトコル/メディアの組み合わせをテストするためのテンプレートとして使用されます。特定のテストシリーズのテストフレームを定義するために使用される特定の形式は、結果のレポートに含める必要があります。
All of the described tests SHOULD be performed at a number of frame sizes. Specifically, the sizes SHOULD include the maximum and minimum legitimate sizes for the protocol under test on the media under test and enough sizes in between to be able to get a full characterization of the DUT performance. Except where noted, at least five frame sizes SHOULD be tested for each test condition.
説明されているすべてのテストは、さまざまなフレームサイズで実行する必要があります。具体的には、サイズには、テスト中のメディアでテスト中のプロトコルの最大および最小合法サイズと、DUTパフォーマンスの完全な特性評価を得るために十分なサイズを含める必要があります。記載されている場合を除き、テスト条件ごとに少なくとも5つのフレームサイズをテストする必要があります。
Theoretically the minimum size UDP Echo request frame would consist of an IP header (minimum length 20 octets), a UDP header (8 octets) and whatever MAC level header is required by the media in use. The theoretical maximum frame size is determined by the size of the length field in the IP header. In almost all cases the actual maximum and minimum sizes are determined by the limitations of the media.
理論的には、最小サイズのUDPエコー要求フレームは、IPヘッダー（最小長20オクテット）、UDPヘッダー（8オクテット）、および使用中のメディアが必要とするMACレベルヘッダーで構成されます。理論的な最大フレームサイズは、IPヘッダーの長さフィールドのサイズによって決まります。ほとんどすべての場合、実際の最大サイズと最小サイズは、メディアの制限によって決定されます。
In theory it would be ideal to distribute the frame sizes in a way that would evenly distribute the theoretical frame rates. These recommendations incorporate this theory but specify frame sizes which are easy to understand and remember. In addition, many of the same frame sizes are specified on each of the media types to allow for easy performance comparisons.
理論的には、理論的なフレームレートを均等に分配する方法でフレームサイズを分配することが理想的です。これらの推奨事項にはこの理論が組み込まれていますが、理解しやすく、覚えやすいフレームサイズを指定します。さらに、同じフレームサイズの多くが各メディアタイプで指定されており、パフォーマンスの比較を容易にします。
Note: The inclusion of an unrealistically small frame size on some of the media types (i.e. with little or no space for data) is to help characterize the per-frame processing overhead of the DUT.
注：一部のメディアタイプに非現実的に小さなフレームサイズを含めること（つまり、データ用のスペースがほとんどまたはまったくない）は、DUTのフラームごとの処理オーバーヘッドを特徴付けるのに役立ちます。
64, 128, 256, 512, 1024, 1280, 1518
64、128、256、512、1024、1280、1518
These sizes include the maximum and minimum frame sizes permitted by the Ethernet standard and a selection of sizes between these extremes with a finer granularity for the smaller frame sizes and higher frame rates.
これらのサイズには、イーサネット標準で許可されている最大および最小フレームサイズと、これらの極端なサイズの選択が、より小さなフレームサイズとより高いフレームレートのためのより細かい粒度があります。
54, 64, 128, 256, 1024, 1518, 2048, 4472
54、64、128、256、1024、1518、2048、4472
The frame size recommendations for token ring assume that there is no RIF field in the frames of routed protocols. A RIF field would be present in any direct source route bridge performance test. The minimum size frame for UDP on token ring is 54 octets. The maximum size of 4472 octets is recommended for 16Mb token ring instead of the theoretical size of 17.9Kb because of the size limitations imposed by many token ring interfaces. The reminder of the sizes are selected to permit direct comparisons with other types of media. An IP (i.e. not UDP) frame may be used in addition if a higher data rate is desired, in which case the minimum frame size is 46 octets.
トークンリングのフレームサイズの推奨事項は、ルーティングされたプロトコルのフレームにRIFフィールドがないことを前提としています。RIFフィールドは、直接的なソースルートブリッジパフォーマンステストに存在します。トークンリングのUDPの最小サイズフレームは54オクテットです。多くのトークンリングインターフェイスによって課されるサイズの制限のため、17.9kbの理論サイズではなく、16MBトークンリングの最大サイズ4472オクテットに推奨されます。サイズのリマインダーは、他のタイプのメディアとの直接的な比較を可能にするために選択されます。より高いデータレートが必要な場合、IP（つまり、UDPではない）フレームが使用される場合があります。その場合、最小フレームサイズは46オクテットです。
54, 64, 128, 256, 1024, 1518, 2048, 4472
54、64、128、256、1024、1518、2048、4472
The minimum size frame for UDP on FDDI is 53 octets, the minimum size of 54 is recommended to allow direct comparison to token ring performance. The maximum size of 4472 is recommended instead of the theoretical maximum size of 4500 octets to permit the same type of comparison. An IP (i.e. not UDP) frame may be used in addition if a higher data rate is desired, in which case the minimum frame size is 45 octets.
FDDI上のUDPの最小サイズフレームは53オクテットで、トークンリングパフォーマンスへの直接比較を可能にするために54の最小サイズが推奨されます。同じタイプの比較を可能にするために、4500オクテットの理論的最大サイズではなく、最大サイズ4472が推奨されます。IP（つまり、UDPではない）フレームを使用すると、より高いデータレートが必要な場合に使用できます。その場合、最小フレームサイズは45オクテットです。
When the interconnect DUT supports connecting links with disparate MTUs, the frame sizes for the link with the *larger* MTU SHOULD be used, up to the limit of the protocol being tested. If the interconnect DUT does not support the fragmenting of frames in the presence of MTU mismatch, the forwarding rate for that frame size shall be reported as zero.
InterConnect DUTがリンクを異なるMTUと接続することをサポートする場合、テスト対象のプロトコルの限界まで、 *より大きな * MTUとのリンクのフレームサイズを使用する必要があります。相互接続DUTがMTUの不一致の存在下でフレームの断片化をサポートしていない場合、そのフレームサイズの転送速度はゼロと報告されます。
For example, the test of IP forwarding with a bridge or router that joins FDDI and Ethernet should use the frame sizes of FDDI when going from the FDDI to the Ethernet link. If the bridge does not support IP fragmentation, the forwarding rate for those frames too large for Ethernet should be reported as zero.
たとえば、FDDIとイーサネットを結合するブリッジまたはルーターを使用したIP転送のテストでは、FDDIからイーサネットリンクに行くときにFDDIのフレームサイズを使用する必要があります。ブリッジがIP断片化をサポートしていない場合、イーサネットには大きすぎるフレームの転送レートはゼロと報告する必要があります。
The test equipment SHOULD discard any frames received during a test run that are not actual forwarded test frames. For example, keep-alive and routing update frames SHOULD NOT be included in the count of received frames. In any case, the test equipment SHOULD verify the length of the received frames and check that they match the expected length.
テスト機器は、実際の転送されたテストフレームではないテスト実行中に受け取ったフレームを廃棄する必要があります。たとえば、キープアライブおよびルーティングアップデートフレームを受信フレームのカウントに含めないでください。いずれにせよ、テスト機器は受信したフレームの長さを検証し、予想される長さと一致することを確認する必要があります。
Preferably, the test equipment SHOULD include sequence numbers in the transmitted frames and check for these numbers on the received frames. If this is done, the reported results SHOULD include in addition to the number of frames dropped, the number of frames that were received out of order, the number of duplicate frames received and the number of gaps in the received frame numbering sequence. This functionality is required for some of the described tests.
好ましくは、テスト機器に送信されたフレームにシーケンス番号を含め、受信したフレームでこれらの数値を確認する必要があります。これが行われた場合、報告された結果には、ドロップされたフレームの数、受信したフレームの数、受信した重複フレームの数、受信したフレーム番号のシーケンスのギャップ数に加えて、報告された結果が含まれる必要があります。この機能は、説明されているテストの一部に必要です。
It might be useful to know the DUT performance under a number of conditions; some of these conditions are noted below. The reported results SHOULD include as many of these conditions as the test equipment is able to generate. The suite of tests SHOULD be first run without any modifying conditions and then repeated under each of the conditions separately. To preserve the ability to compare the results of these tests any frames that are required to generate the modifying conditions (management queries for example) will be included in the same data stream as the normal test frames in place of one of the test frames and not be supplied to the DUT on a separate network port.
多くの条件下でDUTパフォーマンスを知ることは有用かもしれません。これらの条件のいくつかは、以下に記載されています。報告された結果には、テスト機器が生成できる限り、これらの条件の多くを含める必要があります。一連のテストは、最初に変更条件なしで実行し、次に各条件の下で個別に繰り返される必要があります。これらのテストの結果を比較する機能を維持するために、変更条件（たとえば、管理クエリ）を生成するために必要なフレームは、テストフレームの1つではなく、通常のテストフレームと同じデータストリームに含まれます。別のネットワークポートでDUTに供給されます。
In most router designs special processing is required when frames addressed to the hardware broadcast address are received. In bridges (or in bridge mode on routers) these broadcast frames must be flooded to a number of ports. The stream of test frames SHOULD be augmented with 1% frames addressed to the hardware broadcast address. The frames sent to the broadcast address should be of a type that the router will not need to process. The aim of this test is to determine if there is any effect on the forwarding rate of the other data in the stream. The specific frames that should be used are included in the test frame format document. The broadcast frames SHOULD be evenly distributed throughout the data stream, for example, every 100th frame.
ほとんどのルーター設計では、ハードウェアブロードキャストアドレスにアドレス指定されたフレームが受信される場合、特別な処理が必要です。ブリッジ（またはルーターのブリッジモード）では、これらのブロードキャストフレームは多くのポートに浸水する必要があります。テストフレームのストリームは、ハードウェアブロードキャストアドレスにアドレス指定された1％フレームで拡張する必要があります。ブロードキャストアドレスに送信されたフレームは、ルーターが処理する必要のないタイプである必要があります。このテストの目的は、ストリーム内の他のデータの転送速度に影響があるかどうかを判断することです。使用する特定のフレームは、テストフレーム形式のドキュメントに含まれています。ブロードキャストフレームは、たとえば100番目のフレームごとに、データストリーム全体に均等に分散する必要があります。
The same test SHOULD be performed on bridge-like DUTs but in this case the broadcast packets will be processed and flooded to all outputs.
同じテストをブリッジのようなDUTSで実行する必要がありますが、この場合、放送パケットは処理され、すべての出力に浸水します。
It is understood that a level of broadcast frames of 1% is much higher than many networks experience but, as in drug toxicity evaluations, the higher level is required to be able to gage the effect which would otherwise often fall within the normal variability of the system performance. Due to design factors some test equipment will not be able to generate a level of alternate frames this low. In these cases the percentage SHOULD be as small as the equipment can provide and that the actual level be described in the report of the test results.
1％のブロードキャストフレームのレベルは多くのネットワークの経験よりもはるかに高いことが理解されていますが、薬物毒性評価のように、より高いレベルは、そうでなければしばしば、しばしば、システムパフォーマンス。設計要因により、一部のテスト機器は、これが低いレベルの代替フレームを生成することができません。これらの場合、パーセンテージは、機器が提供できるのと同じくらい小さく、実際のレベルをテスト結果のレポートで説明する必要があります。
Most data networks now make use of management protocols such as SNMP. In many environments there can be a number of management stations sending queries to the same DUT at the same time.
現在、ほとんどのデータネットワークは、SNMPなどの管理プロトコルを利用しています。多くの環境では、同じDUTにクエリを同時に送信する多くの管理ステーションがあります。
The stream of test frames SHOULD be augmented with one management query as the first frame sent each second during the duration of the trial. The result of the query must fit into one response frame. The response frame SHOULD be verified by the test equipment. One example of the specific query frame that should be used is shown in Appendix C.
最初のフレームがトライアルの期間中に毎秒送信されるため、テストフレームのストリームは1つの管理クエリで拡張する必要があります。クエリの結果は、1つの応答フレームに適合する必要があります。応答フレームは、テスト機器によって検証する必要があります。使用する特定のクエリフレームの1つの例は、付録Cに示されています。
The processing of dynamic routing protocol updates could have a significant impact on the ability of a router to forward data frames. The stream of test frames SHOULD be augmented with one routing update frame transmitted as the first frame transmitted during the trial.
動的ルーティングプロトコルの更新の処理は、データフレームを転送するルーターの能力に大きな影響を与える可能性があります。テストフレームのストリームは、トライアル中に送信された最初のフレームとして送信される1つのルーティングアップデートフレームで拡張する必要があります。
Routing update frames SHOULD be sent at the rate specified in Appendix C for the specific routing protocol being used in the test. Two routing update frames are defined in Appendix C for the TCP/IP over Ethernet example. The routing frames are designed to change the routing to a number of networks that are not involved in the forwarding of the test data. The first frame sets the routing table state to "A", the second one changes the state to "B". The frames MUST be alternated during the trial.
ルーティングアップデートフレームは、テストで使用されている特定のルーティングプロトコルについて、付録Cで指定されたレートで送信する必要があります。2つのルーティングアップデートフレームは、イーサネット上のTCP/IPの付録Cで定義されています。ルーティングフレームは、テストデータの転送に関与していない多くのネットワークにルーティングを変更するように設計されています。最初のフレームはルーティングテーブルの状態を「A」に設定し、2番目のフレームは状態を「B」に変更します。試験中にフレームを交互にする必要があります。
The test SHOULD verify that the routing update was processed by the DUT.
テストでは、ルーティングアップデートがDUTによって処理されたことを確認する必要があります。
Filters are added to routers and bridges to selectively inhibit the forwarding of frames that would normally be forwarded. This is usually done to implement security controls on the data that is accepted between one area and another. Different products have different capabilities to implement filters.
ルーターとブリッジにフィルターが追加され、通常は転送されるフレームの転送を選択的に阻害します。これは通常、ある領域と別の領域の間で受け入れられているデータにセキュリティ制御を実装するために行われます。さまざまな製品には、フィルターを実装する機能が異なります。
The DUT SHOULD be first configured to add one filter condition and the tests performed. This filter SHOULD permit the forwarding of the test data stream. In routers this filter SHOULD be of the form:
DUTは、最初に1つのフィルター条件と実行されたテストを追加するように構成する必要があります。このフィルターは、テストデータストリームの転送を可能にするはずです。ルーターでは、このフィルターはフォームである必要があります。
forward input_protocol_address to output_protocol_address
input_protocol_address output_protocol_addressへ
In bridges the filter SHOULD be of the form:
ブリッジでは、フィルターはフォームである必要があります。
forward destination_hardware_address
フォワードdestination_hardware_address
The DUT SHOULD be then reconfigured to implement a total of 25 filters. The first 24 of these filters SHOULD be of the form:
その後、DUTを再構成して、合計25個のフィルターを実装する必要があります。これらのフィルターの最初の24は、次の形式でなければなりません。
block input_protocol_address to output_protocol_address
input_protocol_addressをoutput_protocol_addressにブロックします
The 24 input and output protocol addresses SHOULD not be any that are represented in the test data stream. The last filter SHOULD permit the forwarding of the test data stream. By "first" and "last" we mean to ensure that in the second case, 25 conditions must be checked before the data frames will match the conditions that permit the forwarding of the frame. Of course, if the DUT reorders the filters or does not use a linear scan of the filter rules the effect of the sequence in which the filters are input is properly lost.
24の入力および出力プロトコルアドレスは、テストデータストリームで表されるものであってはなりません。最後のフィルターでは、テストデータストリームの転送が可能になります。「最初」と「最後」とは、2番目のケースでは、データフレームがフレームの転送を許可する条件と一致する前に25の条件をチェックする必要があることを確認することを意味します。もちろん、DUTがフィルターを再配置するか、フィルターの線形スキャンを使用しない場合、フィルターが入力されるシーケンスの効果が適切に失われます。
The exact filters configuration command lines used SHOULD be included with the report of the results.
使用される正確なフィルター構成コマンドラインは、結果のレポートに含める必要があります。
Two sets of filter addresses are required, one for the single filter case and one for the 25 filter case.
2セットのフィルターアドレスが必要です。1つはシングルフィルターケースに、もう1つは25フィルターケース用です。
The single filter case should permit traffic from IP address 198.18.1.2 to IP address 198.19.65.2 and deny all other traffic.
単一のフィルターケースでは、IPアドレス198.18.1.2からIPアドレス198.19.65.2へのトラフィックが許可され、他のすべてのトラフィックが拒否されます。
The 25 filter case should follow the following sequence.
25フィルターケースは、次のシーケンスに従う必要があります。
deny aa.ba.1.1 to aa.ba.100.1 deny aa.ba.2.2 to aa.ba.101.2 deny aa.ba.3.3 to aa.ba.103.3 ... deny aa.ba.12.12 to aa.ba.112.12 allow aa.bc.1.2 to aa.bc.65.1 deny aa.ba.13.13 to aa.ba.113.13 deny aa.ba.14.14 to aa.ba.114.14 ... deny aa.ba.24.24 to aa.ba.124.24 deny all else
aa.ba.1.1をaa.ba.100.1に拒否aa.ba.2.2からaa.ba.101.2からaa.ba.103.3に拒否します。112.12 AA.BC.1.2をAA.BC.65.1に許可するAA.BA.13.13をaa.ba.113.13に拒否aa.ba.14.14からaa.ba.114.14 ....124.24他のすべてを拒否します
All previous filter conditions should be cleared from the router before this sequence is entered. The sequence is selected to test to see if the router sorts the filter conditions or accepts them in the order that they were entered. Both of these procedures will result in a greater impact on performance than will some form of hash coding.
このシーケンスが入力される前に、すべての以前のフィルター条件をルーターからクリアする必要があります。シーケンスは、ルーターがフィルター条件をソートするか、入力された順序でそれらを受け入れるかどうかを確認するためにテストするために選択されます。これらの手順は両方とも、何らかの形のハッシュコーディングよりもパフォーマンスに大きな影響を与えます。
It is easier to implement these tests using a single logical stream of data, with one source protocol address and one destination protocol address, and for some conditions like the filters described above, a practical requirement. Networks in the real world are not limited to single streams of data. The test suite SHOULD be first run with a single protocol (or hardware for bridge tests) source and destination address pair. The tests SHOULD then be repeated with using a random destination address. While testing routers the addresses SHOULD be random and uniformly distributed over a range of 256 networks and random and uniformly distributed over the full MAC range for bridges. The specific address ranges to use for IP are shown in Appendix C.
1つのソースプロトコルアドレスと1つの宛先プロトコルアドレスを備えた単一の論理ストリーム、および上記のフィルターのような一部の条件では、実用的な要件を使用して、これらのテストを実装する方が簡単です。現実の世界のネットワークは、単一のデータのストリームに限定されません。テストスイートは、最初に単一のプロトコル（またはブリッジテスト用のハードウェア）ソースと宛先アドレスペアで実行する必要があります。その後、ランダムな宛先アドレスを使用してテストを繰り返す必要があります。ルーターのテスト中は、アドレスはランダムであり、256のネットワークの範囲で均一に分布し、ブリッジ用の完全なMAC範囲にランダムで均一に分布する必要があります。IPに使用する特定のアドレス範囲は、付録Cに示されています。
It is not reasonable that all of the routing information necessary to forward the test stream, especially in the multiple address case, will be manually set up. At the start of each trial a routing update MUST be sent to the DUT. This routing update MUST include all of the network addresses that will be required for the trial. All of the addresses SHOULD resolve to the same "next-hop". Normally this will be the address of the receiving side of the test equipment. This routing update will have to be repeated at the interval required by the routing protocol being used. An example of the format and repetition interval of the update frames is given in Appendix C.
特に複数のアドレスケースでテストストリームを転送するために必要なすべてのルーティング情報が手動でセットアップされることは合理的ではありません。各トライアルの開始時に、ルーティングアップデートをDUTに送信する必要があります。このルーティングアップデートには、トライアルに必要なすべてのネットワークアドレスを含める必要があります。すべてのアドレスは、同じ「ネクストホップ」に解決する必要があります。通常、これはテスト機器の受信側のアドレスになります。このルーティングアップデートは、使用されているルーティングプロトコルで必要な間隔で繰り返す必要があります。更新フレームの形式と繰り返し間隔の例は、付録Cに記載されています。
Normal network activity is not all in a single direction. To test the bidirectional performance of a DUT, the test series SHOULD be run with the same data rate being offered from each direction. The sum of the data rates should not exceed the theoretical limit for the media.
通常のネットワークアクティビティはすべて単一の方向ではありません。DUTの双方向性能をテストするには、各方向から同じデータレートが提供されているため、テストシリーズを実行する必要があります。データレートの合計は、メディアの理論的制限を超えてはなりません。
The full suite of tests SHOULD be run along with whatever modifier conditions that are relevant using a single input and output network port on the DUT. If the internal design of the DUT has multiple distinct pathways, for example, multiple interface cards each with multiple network ports, then all possible types of pathways SHOULD be tested separately.
完全な一連のテストは、DUT上の単一の入力ネットワークポートを使用して関連する修飾条件とともに実行する必要があります。DUTの内部設計に複数の異なる経路、たとえば複数のインターフェイスカードがそれぞれ複数のネットワークポートを持つ複数のインターフェイスカードがある場合、すべての可能なタイプの経路を個別にテストする必要があります。
Many current router and bridge products provide many network ports in the same module. In performing these tests first half of the ports are designated as "input ports" and half are designated as "output ports". These ports SHOULD be evenly distributed across the DUT architecture. For example if a DUT has two interface cards each of which has four ports, two ports on each interface card are designated as input and two are designated as output. The specified tests are run using the same data rate being offered to each of the input ports. The addresses in the input data streams SHOULD be set so that a frame will be directed to each of the output ports in sequence so that all "output" ports will get an even distribution of packets from this input. The same configuration MAY be used to perform a bidirectional multi-stream test. In this case all of the ports are considered both input and output ports and each data stream MUST consist of frames addressed to all of the other ports.
多くの現在のルーターとブリッジ製品は、同じモジュールで多くのネットワークポートを提供しています。これらのテストを実行する際に、ポートの前半は「入力ポート」として指定され、半分は「出力ポート」として指定されます。これらのポートは、DUTアーキテクチャ全体に均等に配布する必要があります。たとえば、DUTがそれぞれ4つのポートを備えた2つのインターフェイスカードを持っている場合、各インターフェイスカードに2つのポートが入力として指定され、2つが出力として指定されます。指定されたテストは、各入力ポートに提供される同じデータレートを使用して実行されます。入力データストリームのアドレスは、すべての「出力」ポートがこの入力からパケットの均等な配布を取得できるように、フレームが順番に各出力ポートに向けられるように設定する必要があります。同じ構成を使用して、双方向のマルチストリームテストを実行することができます。この場合、すべてのポートは入力ポートと出力ポートの両方と見なされ、各データストリームは他のすべてのポートにアドレス指定されたフレームで構成されている必要があります。
Consider the following 6 port DUT:
次の6ポートDUTを検討してください。
--------------
---------| in A out X|--------
---------| in B out Y|--------
---------| in C out Z|--------
--------------
The addressing of the data streams for each of the inputs SHOULD be:
各入力のデータストリームのアドレス指定は、次のようにする必要があります。
stream sent to input A: packet to out X, packet to out Y, packet to out Z stream sent to input B: packet to out X, packet to out Y, packet to out Z stream sent to input C packet to out X, packet to out Y, packet to out Z
入力a：out xへのパケット、パケットy、out z z streamへのパケットb：out xへのパケット、パケットy、パケット、アウトzストリームから送信されたzパケットcパケットをout xに入力するzストリーム、yへのパケット、zからパケット
Note that these streams each follow the same sequence so that 3 packets will arrive at output X at the same time, then 3 packets at Y, then 3 packets at Z. This procedure ensures that, as in the real world, the DUT will have to deal with multiple packets addressed to the same output at the same time.
これらのストリームはそれぞれ同じシーケンスに従い、3つのパケットが同時に出力Xに到達し、次にYで3つのパケットに到達することに注意してください。同時に同じ出力にアドレス指定された複数のパケットに対処する。
This document does not address the issue of testing the effects of a mixed protocol environment other than to suggest that if such tests are wanted then frames SHOULD be distributed between all of the test protocols. The distribution MAY approximate the conditions on the network in which the DUT would be used.
このドキュメントでは、そのようなテストが必要な場合、フレームをすべてのテストプロトコル間で分散する必要があることを示唆する以外に、混合プロトコル環境の効果をテストする問題に対処しません。分布は、DUTが使用されるネットワーク上の条件に近似する場合があります。
This document does not address the issue of testing the effects of a mixed frame size environment other than to suggest that if such tests are wanted then frames SHOULD be distributed between all of the listed sizes for the protocol under test. The distribution MAY approximate the conditions on the network in which the DUT would be used. The authors do not have any idea how the results of such a test would be interpreted other than to directly compare multiple DUTs in some very specific simulated network.
このドキュメントでは、そのようなテストが必要な場合、テスト中のプロトコルのすべてのリストされたサイズの間にフレームを配布する必要があることを示唆する以外に、混合フレームサイズ環境の効果をテストする問題に対処しません。分布は、DUTが使用されるネットワーク上の条件に近似する場合があります。著者は、いくつかの非常に具体的なシミュレーションネットワークで複数のDUTを直接比較する以外に、このようなテストの結果がどのように解釈されるかを考えていません。
19. Testing performance beyond a single DUT.
19. 単一のDUTを超えたパフォーマンスのテスト。
In the performance testing of a single DUT, the paradigm can be described as applying some input to a DUT and monitoring the output. The results of which can be used to form a basis of characterization of that device under those test conditions.
単一のDUTのパフォーマンステストでは、パラダイムは、DUTに何らかの入力を適用し、出力を監視すると説明できます。その結果は、それらのテスト条件下でそのデバイスの特性評価の基礎を形成するために使用できます。
This model is useful when the test input and output are homogenous (e.g., 64-byte IP, 802.3 frames into the DUT; 64 byte IP, 802.3 frames out), or the method of test can distinguish between dissimilar input/output. (E.g., 1518 byte IP, 802.3 frames in; 576 byte, fragmented IP, X.25 frames out.)
このモデルは、テスト入力と出力が均質である場合に役立ちます（例：64バイトIP、DUTへの802.3フレーム、64バイトIP、802.3フレーム）、またはテストの方法が異なる入力/出力を区別できます。（例えば、1518バイトIP、802.3フレームで; 576バイト、断片化IP、X.25フレームアウト。）
By extending the single DUT test model, reasonable benchmarks regarding multiple DUTs or heterogeneous environments may be collected. In this extension, the single DUT is replaced by a system of interconnected network DUTs. This test methodology would support the benchmarking of a variety of device/media/service/protocol combinations. For example, a configuration for a LAN-to-WAN-to-LAN test might be:
単一のDUTテストモデルを拡張することにより、複数のDUTまたは不均一環境に関する合理的なベンチマークを収集することができます。この拡張では、単一のDUTは相互接続されたネットワークDUTSのシステムに置き換えられます。このテスト方法は、さまざまなデバイス/メディア/サービス/プロトコルの組み合わせのベンチマークをサポートします。たとえば、LAN-to-wan-to-lanテストの構成は次のとおりです。
(1) 802.3-> DUT 1 -> X.25 @ 64kbps -> DUT 2 -> 802.3
Or a mixed LAN configuration might be:
または混合LAN構成は次のとおりです。
(2) 802.3 -> DUT 1 -> FDDI -> DUT 2 -> FDDI -> DUT 3 -> 802.3
In both examples 1 and 2, end-to-end benchmarks of each system could be empirically ascertained. Other behavior may be characterized through the use of intermediate devices. In example 2, the configuration may be used to give an indication of the FDDI to FDDI capability exhibited by DUT 2.
例1と2の両方で、各システムのエンドツーエンドのベンチマークを経験的に確認することができます。他の動作は、中間デバイスを使用することで特徴付けられる場合があります。例2では、構成を使用して、DUT 2が示すFDDIからFDDI機能の兆候を示すことができます。
Because multiple DUTs are treated as a single system, there are limitations to this methodology. For instance, this methodology may yield an aggregate benchmark for a tested system. That benchmark alone, however, may not necessarily reflect asymmetries in behavior between the DUTs, latencies introduce by other apparatus (e.g., CSUs/DSUs, switches), etc.
複数のDUTは単一のシステムとして扱われるため、この方法論には制限があります。たとえば、この方法論は、テストされたシステムの集計ベンチマークを生成する可能性があります。ただし、そのベンチマークだけで、必ずしもDUTS、他の装置（CSUS/DSU、スイッチなど）によって導入されるレイテンシの間の行動の非対称性を反映するとは限りません。
Further, care must be used when comparing benchmarks of different systems by ensuring that the DUTs' features/configuration of the tested systems have the appropriate common denominators to allow comparison.
さらに、テストされたシステムのDUTの機能/構成が比較を可能にする適切な共通分母を確保することにより、異なるシステムのベンチマークを比較するときに注意する必要があります。
The maximum frame rates that should be used when testing LAN connections SHOULD be the listed theoretical maximum rate for the frame size on the media.
LAN接続をテストするときに使用する必要がある最大フレームレートは、メディアのフレームサイズの記載されている理論的最大レートである必要があります。
The maximum frame rate that should be used when testing WAN connections SHOULD be greater than the listed theoretical maximum rate for the frame size on that speed connection. The higher rate for WAN tests is to compensate for the fact that some vendors employ various forms of header compression.
WAN接続をテストするときに使用する必要がある最大フレームレートは、その速度接続のフレームサイズの記載されている理論的最大レートよりも大きくなければなりません。WANテストの高いレートは、一部のベンダーがさまざまな形式のヘッダー圧縮を使用しているという事実を補うことです。
A list of maximum frame rates for LAN connections is included in Appendix B.
LAN接続の最大フレームレートのリストは、付録Bに含まれています。
It is convenient to measure the DUT performance under steady state load but this is an unrealistic way to gauge the functioning of a DUT since actual network traffic normally consists of bursts of frames. Some of the tests described below SHOULD be performed with both steady state traffic and with traffic consisting of repeated bursts of frames. The frames within a burst are transmitted with the minimum legitimate inter-frame gap.
定常状態の負荷でDUTパフォーマンスを測定するのは便利ですが、実際のネットワークトラフィックは通常フレームのバーストで構成されているため、これはDUTの機能を測定する非現実的な方法です。以下に説明するテストの一部は、定常状態交通と、フレームの繰り返しバーストで構成されるトラフィックの両方で実行する必要があります。バースト内のフレームは、最小合法的なフレーム間ギャップで送信されます。
The objective of the test is to determine the minimum interval between bursts which the DUT can process with no frame loss. During each test the number of frames in each burst is held constant and the inter-burst interval varied. Tests SHOULD be run with burst sizes of 16, 64, 256 and 1024 frames.
テストの目的は、DUTがフレーム損失なしで処理できるバースト間の最小間隔を決定することです。各テスト中に、各バーストのフレームの数が一定に保たれ、バースト間間隔が変化しました。テストは、16、64、256、および1024フレームのバーストサイズで実行する必要があります。
Although it is possible to configure some token ring and FDDI interfaces to transmit more than one frame each time that the token is received, most of the network devices currently available transmit only one frame per token. These tests SHOULD first be performed while transmitting only one frame per token.
トークンが受信されるたびに複数のフレームを送信するようにトークンリングとFDDIインターフェイスを構成することは可能ですが、現在利用可能なネットワークデバイスのほとんどは、トークンごとに1つのフレームのみを送信します。これらのテストは、最初にトークンごとに1つのフレームのみを送信しながら実行する必要があります。
Some current high-performance workstation servers do transmit more than one frame per token on FDDI to maximize throughput. Since this may be a common feature in future workstations and servers, interconnect devices with FDDI interfaces SHOULD be tested with 1, 4, 8, and 16 frames per token. The reported frame rate SHOULD be the average rate of frame transmission over the total trial period.
現在の高性能ワークステーションサーバーの一部は、Sultputを最大化するために、FDDI上のトークンごとに複数のフレームを送信します。これは将来のワークステーションとサーバーの一般的な機能である可能性があるため、FDDIインターフェイスを備えたインターコネクトデバイスは、トークンあたり1、4、8、および16フレームでテストする必要があります。報告されたフレームレートは、合計試行期間にわたるフレーム送信の平均レートである必要があります。
A particular test consists of multiple trials. Each trial returns one piece of information, for example the loss rate at a particular input frame rate. Each trial consists of a number of phases:
特定のテストは、複数の試行で構成されています。各トライアルは、特定の入力フレームレートでの損失率など、1つの情報を返します。各試験は多くのフェーズで構成されています。
a) If the DUT is a router, send the routing update to the "input" port and pause two seconds to be sure that the routing has settled.
a) DUTがルーターの場合は、ルーティングアップデートを「入力」ポートに送信し、ルーティングが解決したことを確認するために2秒一時停止します。
b) Send the "learning frames" to the "output" port and wait 2 seconds to be sure that the learning has settled. Bridge learning frames are frames with source addresses that are the same as the destination addresses used by the test frames. Learning frames for other protocols are used to prime the address resolution tables in the DUT. The formats of the learning frame that should be used are shown in the Test Frame Formats document.
b) 「学習フレーム」を「出力」ポートに送信し、2秒待って、学習が解決したことを確認します。ブリッジ学習フレームは、テストフレームで使用される宛先アドレスと同じソースアドレスを備えたフレームです。他のプロトコルの学習フレームは、DUTのアドレス解像度表をプライミングするために使用されます。使用すべき学習フレームの形式は、テストフレーム形式のドキュメントに表示されます。
c) Run the test trial.
c) テストトライアルを実行します。
d) Wait for two seconds for any residual frames to be received.
d) 残留フレームが受信されるまで2秒間待ちます。
e) Wait for at least five seconds for the DUT to restabilize.
e) DUTが再検証するまで、少なくとも5秒間待ちます。
The aim of these tests is to determine the rate continuously supportable by the DUT. The actual duration of the test trials must be a compromise between this aim and the duration of the benchmarking test suite. The duration of the test portion of each trial SHOULD be at least 60 seconds. The tests that involve some form of "binary search", for example the throughput test, to determine the exact result MAY use a shorter trial duration to minimize the length of the search procedure, but the final determination SHOULD be made with full length trials.
これらのテストの目的は、DUTが継続的にサポートできるレートを決定することです。テスト試験の実際の期間は、この目的とベンチマークテストスイートの期間との間の妥協点でなければなりません。各試行のテスト部分の期間は、少なくとも60秒でなければなりません。正確な結果を決定するための「バイナリ検索」、たとえばスループットテストなどの「バイナリ検索」を含むテストは、より短い試行時間を使用して検索手順の長さを最小化する可能性がありますが、最終決定は完全な長さの試行で行う必要があります。
The DUT SHOULD be able to respond to address resolution requests sent by the DUT wherever the protocol requires such a process.
DUTは、プロトコルがそのようなプロセスを必要とする場所であればどこでもDUTが送信した住所解決要求に応答できるはずです。
26. Benchmarking tests:
26. ベンチマークテスト：
Note: The notation "type of data stream" refers to the above modifications to a frame stream with a constant inter-frame gap, for example, the addition of traffic filters to the configuration of the DUT.
注：「データストリームのタイプ」と表記は、たとえば、DUTの構成にトラフィックフィルターを追加するなど、一定のフレーム間ギャップを持つフレームストリームの上記の変更を指します。
Objective: To determine the DUT throughput as defined in RFC 1242.
目的：RFC 1242で定義されているDUTスループットを決定します。
Procedure: Send a specific number of frames at a specific rate through the DUT and then count the frames that are transmitted by the DUT. If the count of offered frames is equal to the count of received frames, the fewer frames are received than were transmitted, the rate of the offered stream is reduced and the test is rerun.
手順：特定の数のフレームをDUTを通じて特定のレートで送信し、DUTによって送信されるフレームをカウントします。提供されたフレームのカウントが受信フレームのカウントに等しい場合、送信されるよりも受信されるフレームが少なく、提供されるストリームの速度が低下し、テストが再実行されます。
The throughput is the fastest rate at which the count of test frames transmitted by the DUT is equal to the number of test frames sent to it by the test equipment.
スループットは、DUTによって送信されるテストフレームのカウントが、テスト機器から送信されるテストフレームの数に等しい最速の速度です。
Reporting format: The results of the throughput test SHOULD be reported in the form of a graph. If it is, the x coordinate SHOULD be the frame size, the y coordinate SHOULD be the frame rate. There SHOULD be at least two lines on the graph. There SHOULD be one line showing the theoretical frame rate for the media at the various frame sizes. The second line SHOULD be the plot of the test results. Additional lines MAY be used on the graph to report the results for each type of data stream tested. Text accompanying the graph SHOULD indicate the protocol, data stream format, and type of media used in the tests.
レポート形式：スループットテストの結果は、グラフの形式で報告する必要があります。もしそうなら、x座標はフレームサイズである必要があり、y座標はフレームレートでなければなりません。グラフには少なくとも2つの行があるはずです。さまざまなフレームサイズのメディアの理論的フレームレートを示す1つのラインが必要です。2番目の行は、テスト結果のプロットです。グラフで追加の行を使用して、テストされたデータストリームの各タイプの結果を報告することができます。グラフに付随するテキストは、テストで使用されるメディアのプロトコル、データストリーム形式、およびタイプを示す必要があります。
We assume that if a single value is desired for advertising purposes the vendor will select the rate for the minimum frame size for the media. If this is done then the figure MUST be expressed in frames per second. The rate MAY also be expressed in bits (or bytes) per second if the vendor so desires. The statement of performance MUST include a/ the measured maximum frame rate, b/ the size of the frame used, c/ the theoretical limit of the media for that frame size, and d/ the type of protocol used in the test. Even if a single value is used as part of the advertising copy, the full table of results SHOULD be included in the product data sheet.
広告目的で単一の値が望まれる場合、ベンダーはメディアの最小フレームサイズのレートを選択すると仮定します。これが行われた場合、図は1秒あたりのフレームで表現する必要があります。レートは、ベンダーが望む場合、1秒あたりビット（またはバイト）で表現することもできます。パフォーマンスのステートメントには、A/測定された最大フレームレート、使用されるフレームのサイズ、そのフレームサイズのメディアの理論的限界、およびテストで使用されるプロトコルのタイプを含める必要があります。単一の値が広告コピーの一部として使用されている場合でも、結果の完全な表を製品データシートに含める必要があります。
Objective: To determine the latency as defined in RFC 1242.
目的：RFC 1242で定義されているレイテンシを決定します。
Procedure: First determine the throughput for DUT at each of the listed frame sizes. Send a stream of frames at a particular frame size through the DUT at the determined throughput rate to a specific destination. The stream SHOULD be at least 120 seconds in duration. An identifying tag SHOULD be included in one frame after 60 seconds with the type of tag being implementation dependent. The time at which this frame is fully transmitted is recorded (timestamp A). The receiver logic in the test equipment MUST recognize the tag information in the frame stream and record the time at which the tagged frame was received (timestamp B).
手順：最初にリストされている各フレームサイズでDUTのスループットを決定します。特定のスループットレートでDUTを介して特定のフレームサイズでフレームのストリームを特定の宛先に送信します。ストリームは、期間が少なくとも120秒でなければなりません。識別タグは、60秒後に1つのフレームに含める必要があります。このフレームが完全に送信される時間が記録されています（タイムスタンプA）。テスト機器の受信機ロジックは、フレームストリームのタグ情報を認識し、タグ付きフレームを受信した時間を記録する必要があります（タイムスタンプB）。
The latency is timestamp B minus timestamp A as per the relevant definition frm RFC 1242, namely latency as defined for store and forward devices or latency as defined for bit forwarding devices.
レイテンシは、関連する定義FRM RFC 1242、つまり、ストアおよびフォワードデバイスで定義されているレイテンシまたはビット転送デバイスで定義されているレイテンシです。
The test MUST be repeated at least 20 times with the reported value being the average of the recorded values.
報告された値は記録された値の平均であるため、テストは少なくとも20回繰り返す必要があります。
This test SHOULD be performed with the test frame addressed to the same destination as the rest of the data stream and also with each of the test frames addressed to a new destination network.
このテストは、他のデータストリームと同じ宛先に宛てられたテストフレームと、新しい宛先ネットワークに宛てられた各テストフレームでも実行される必要があります。
Reporting format: The report MUST state which definition of latency (from RFC 1242) was used for this test. The latency results SHOULD be reported in the format of a table with a row for each of the tested frame sizes. There SHOULD be columns for the frame size, the rate at which the latency test was run for that frame size, for the media types tested, and for the resultant latency values for each type of data stream tested.
レポート形式：レポートは、このテストに使用されたレイテンシの定義（RFC 1242から）を記載する必要があります。レイテンシの結果は、テストされたフレームサイズごとに行を持つテーブルの形式で報告する必要があります。フレームサイズの列、そのフレームサイズのレイテンシテストが実行された速度、テストされたメディアタイプ、およびテストされた各タイプのデータストリームの結果として得られるレイテンシー値については、列が必要です。
Objective: To determine the frame loss rate, as defined in RFC 1242, of a DUT throughout the entire range of input data rates and frame sizes.
目的：RFC 1242で定義されているフレーム損失率を、入力データレートとフレームサイズの全範囲を通じてDUTのフレーム損失率を決定します。
Procedure: Send a specific number of frames at a specific rate through the DUT to be tested and count the frames that are transmitted by the DUT. The frame loss rate at each point is calculated using the following equation:
手順：特定の数のフレームを特定のレートで送信して、テストするDUTを通じて特定のレートで送信し、DUTが送信するフレームをカウントします。各ポイントでのフレーム損失率は、次の方程式を使用して計算されます。
( ( input_count - output_count ) * 100 ) / input_count
The first trial SHOULD be run for the frame rate that corresponds to 100% of the maximum rate for the frame size on the input media. Repeat the procedure for the rate that corresponds to 90% of the maximum rate used and then for 80% of this rate. This sequence SHOULD be continued (at reducing 10% intervals) until there are two successive trials in which no frames are lost. The maximum granularity of the trials MUST be 10% of the maximum rate, a finer granularity is encouraged.
最初の試行は、入力メディアのフレームサイズの最大レートの100％に対応するフレームレートに対して実行する必要があります。使用される最大レートの90％に相当するレートの手順を繰り返し、このレートの80％について繰り返します。このシーケンスは、フレームが失われない2つの連続した試行が行われるまで（10％間隔を減らす）継続する必要があります。試験の最大粒度は最大レートの10％でなければならず、より細かい粒度が奨励されています。
Reporting format: The results of the frame loss rate test SHOULD be plotted as a graph. If this is done then the X axis MUST be the input frame rate as a percent of the theoretical rate for the media at the specific frame size. The Y axis MUST be the percent loss at the particular input rate. The left end of the X axis and the bottom of the Y axis MUST be 0 percent; the right end of the X axis and the top of the Y axis MUST be 100 percent. Multiple lines on the graph MAY used to report the frame loss rate for different frame sizes, protocols, and types of data streams.
レポート形式：フレーム損失率テストの結果は、グラフとしてプロットする必要があります。これが行われた場合、x軸は、特定のフレームサイズでのメディアの理論レートの割合として入力フレームレートでなければなりません。Y軸は、特定の入力レートでの損失率でなければなりません。x軸の左端とy軸の底部は0％でなければなりません。x軸の右端とy軸の上部は100％でなければなりません。グラフ上の複数の行は、異なるフレームサイズ、プロトコル、およびデータストリームの種類のフレーム損失レートを報告するために使用できます。
Note: See section 18 for the maximum frame rates that SHOULD be used.
注：使用する必要がある最大フレームレートについては、セクション18を参照してください。
Objective: To characterize the ability of a DUT to process back-to-back frames as defined in RFC 1242.
目的：RFC 1242で定義されているように、DUTが連続フレームを処理する能力を特徴付ける。
Procedure: Send a burst of frames with minimum inter-frame gaps to the DUT and count the number of frames forwarded by the DUT. If the count of transmitted frames is equal to the number of frames forwarded the length of the burst is increased and the test is rerun. If the number of forwarded frames is less than the number transmitted, the length of the burst is reduced and the test is rerun.
手順：DUTに最小限のフレームのギャップでフレームのバーストを送信し、DUTによって転送されるフレームの数をカウントします。送信されたフレームの数が転送されたフレームの数に等しい場合、バーストの長さが増加し、テストが再実行されます。転送されたフレームの数が送信された数より少ない場合、バーストの長さが減少し、テストが再実行されます。
The back-to-back value is the number of frames in the longest burst that the DUT will handle without the loss of any frames. The trial length MUST be at least 2 seconds and SHOULD be repeated at least 50 times with the average of the recorded values being reported.
連続した値は、DUTがフレームを失うことなく処理する最も長いバーストのフレームの数です。試行の長さは少なくとも2秒でなければならず、記録された値の平均が報告されている場合、少なくとも50回繰り返す必要があります。
Reporting format: The back-to-back results SHOULD be reported in the format of a table with a row for each of the tested frame sizes. There SHOULD be columns for the frame size and for the resultant average frame count for each type of data stream tested. The standard deviation for each measurement MAY also be reported.
レポート形式：連続した結果は、テストされたフレームサイズごとに行を持つテーブルの形式で報告する必要があります。フレームサイズと、テストされた各タイプのデータストリームの結果の平均フレームカウントの列があるはずです。各測定の標準偏差も報告できます。
Objective: To characterize the speed at which a DUT recovers from an overload condition.
目的：DUTが過負荷状態から回復する速度を特徴付ける。
Procedure: First determine the throughput for a DUT at each of the listed frame sizes.
手順：最初にリストされている各フレームサイズでDUTのスループットを決定します。
Send a stream of frames at a rate 110% of the recorded throughput rate or the maximum rate for the media, whichever is lower, for at least 60 seconds. At Timestamp A reduce the frame rate to 50% of the above rate and record the time of the last frame lost (Timestamp B). The system recovery time is determined by subtracting Timestamp B from Timestamp A. The test SHOULD be repeated a number of times and the average of the recorded values being reported.
記録されたスループットレートの110％またはメディアの最大レートのレートで、少なくとも60秒間、メディアの最大レートでフレームのストリームを送信します。タイムスタンプでは、フレームレートを上記のレートの50％に低下させ、失われた最後のフレームの時間を記録します（タイムスタンプB）。システムの回復時間は、タイムスタンプAからタイムスタンプBを差し引くことで決定されます。テストは何度も繰り返し、記録された値の平均を報告する必要があります。
Reporting format: The system recovery results SHOULD be reported in the format of a table with a row for each of the tested frame sizes. There SHOULD be columns for the frame size, the frame rate used as the throughput rate for each type of data stream tested, and for the measured recovery time for each type of data stream tested.
レポート形式：システムの回復結果は、テストされたフレームサイズごとに行を持つテーブルの形式で報告する必要があります。フレームサイズの列、テストされた各タイプのデータストリームのスループットレートとして使用されるフレームレート、およびテストされた各タイプのデータストリームの測定された回復時間の列が必要です。
Objective: To characterize the speed at which a DUT recovers from a device or software reset.
目的：DUTがデバイスまたはソフトウェアリセットから回復する速度を特徴付ける。
Procedure: First determine the throughput for the DUT for the minimum frame size on the media used in the testing.
手順：最初に、テストで使用されるメディアの最小フレームサイズのDUTのスループットを決定します。
Send a continuous stream of frames at the determined throughput rate for the minimum sized frames. Cause a reset in the DUT. Monitor the output until frames begin to be forwarded and record the time that the last frame (Timestamp A) of the initial stream and the first frame of the new stream (Timestamp B) are received. A power interruption reset test is performed as above except that the power to the DUT should be interrupted for 10 seconds in place of causing a reset.
最小サイズのフレームに対して、決定されたスループットレートで連続したフレームのストリームを送信します。DUTでリセットを引き起こします。フレームが転送され始めるまで出力を監視し、初期ストリームの最後のフレーム（タイムスタンプA）と新しいストリームの最初のフレーム（タイムスタンプB）が受信される時間を記録します。停電リセットテストは、上記のように実行されます。
This test SHOULD only be run using frames addressed to networks directly connected to the DUT so that there is no requirement to delay until a routing update is received.
このテストは、DUTに直接接続されたネットワークにアドレス指定されたフレームを使用してのみ実行する必要があるため、ルーティングアップデートが受信されるまで遅延する必要はありません。
The reset value is obtained by subtracting Timestamp A from Timestamp B.
リセット値は、タイムスタンプBからタイムスタンプAを差し引くことで取得されます。
Hardware and software resets, as well as a power interruption SHOULD be tested.
ハードウェアとソフトウェアのリセット、および停電の中断をテストする必要があります。
Reporting format: The reset value SHOULD be reported in a simple set of statements, one for each reset type.
レポート形式：リセット値は、リセットタイプごとに1つのステートメントの簡単なセットで報告する必要があります。
Security issues are not addressed in this document.
このドキュメントでは、セキュリティの問題は扱われていません。
Scott Bradner Harvard University 1350 Mass. Ave, room 813 Cambridge, MA 02138
スコットブラッドハーバード大学1350マサチューセッツ州アベニュー、ルーム813ケンブリッジ、マサチューセッツ州02138
Phone: +1 617 495-3864
Fax: +1 617 496-8500
EMail: sob@harvard.edu
Jim McQuaid NetScout Systems 4 Westford Tech Park Drive Westford, MA 01886
Jim McQuaid Netscout Systems 4 Westford Tech Park Drive Westford、MA 01886
Phone: +1 978 614-4116
Fax: +1 978 614-4004
EMail: mcquaidj@netscout.com
Appendix A: Testing Considerations
付録A：テストの考慮事項
This appendix discusses certain issues in the benchmarking methodology where experience or judgment may play a role in the tests selected to be run or in the approach to constructing the test with a particular DUT. As such, this appendix MUST not be read as an amendment to the methodology described in the body of this document but as a guide to testing practice.
この付録では、経験または判断が実行されるように選択されたテストまたは特定のDUTでテストを構築するアプローチで役割を果たす可能性があるベンチマーク方法論の特定の問題について説明します。そのため、この付録は、この文書の本文で説明されている方法論の修正としてではなく、テストの実践のガイドとして読むべきではありません。
1. Typical testing practice has been to enable all protocols to be tested and conduct all testing with no further configuration of protocols, even though a given set of trials may exercise only one protocol at a time. This minimizes the opportunities to "tune" a DUT for a single protocol.
1. 典型的なテストの練習は、すべてのプロトコルをテストし、特定の一連の試行が一度に1つのプロトコルのみを行使できる場合でも、それ以上のプロトコルの構成なしですべてのテストを実行できるようにすることでした。これにより、単一のプロトコルのDUTを「調整」する機会が最小限に抑えられます。
2. The least common denominator of the available filter functions should be used to ensure that there is a basis for comparison between vendors. Because of product differences, those conducting and evaluating tests must make a judgment about this issue.
2. 利用可能なフィルター関数の最も一般的ではない分母を使用して、ベンダー間の比較の基礎があることを確認する必要があります。製品の違いのため、テストを実施および評価する人は、この問題について判断を下す必要があります。
3. Architectural considerations may need to be considered. For example, first perform the tests with the stream going between ports on the same interface card and the repeat the tests with the stream going into a port on one interface card and out of a port on a second interface card. There will almost always be a best case and worst case configuration for a given DUT architecture.
3. 建築上の考慮事項を考慮する必要がある場合があります。たとえば、まず、同じインターフェイスカードのポート間でストリームを使用してテストを実行し、ストリームを1つのインターフェイスカードのポートに入れて、2番目のインターフェイスカードのポートからテストを繰り返します。特定のDUTアーキテクチャには、ほとんどの場合、最良のケースと最悪のケース構成があります。
4. Testing done using traffic streams consisting of mixed protocols has not shown much difference between testing with individual protocols. That is, if protocol A testing and protocol B testing give two different performance results, mixed protocol testing appears to give a result which is the average of the two.
4. 混合プロトコルで構成されるトラフィックストリームを使用して行われたテストは、個々のプロトコルでのテストの間に大きな違いを示していません。つまり、プロトコルAテストとプロトコルBテストが2つの異なるパフォーマンス結果を与えると、混合プロトコルテストが結果をもたらすように見えます。
5. Wide Area Network (WAN) performance may be tested by setting up two identical devices connected by the appropriate short- haul versions of the WAN modems. Performance is then measured between a LAN interface on one DUT to a LAN interface on the other DUT.
5. WANモデムの適切な短距離バージョンで接続された2つの同一のデバイスをセットアップすることにより、ワイドエリアネットワーク（WAN）パフォーマンスをテストできます。次に、パフォーマンスは、1つのDUTでLANインターフェイス間で、他のDUTでLANインターフェイスを測定します。
The maximum frame rate to be used for LAN-WAN-LAN configurations is a judgment that can be based on known characteristics of the overall system including compression effects, fragmentation, and gross link speeds. Practice suggests that the rate should be at least 110% of the slowest link speed. Substantive issues of testing compression itself are beyond the scope of this document.
LAN-WAN-LAN構成に使用される最大フレームレートは、圧縮効果、断片化、総リンク速度など、システム全体の既知の特性に基づいていることができる判断です。練習は、レートが最も遅いリンク速度の少なくとも110％であるべきであることを示唆しています。圧縮自体のテストの実質的な問題は、このドキュメントの範囲を超えています。
Appendix B: Maximum frame rates reference
付録B：最大フレームレート参照
(Provided by Roger Beeman, Cisco Systems)
（Cisco SystemsのRoger Beemanが提供）
Size Ethernet 16Mb Token Ring FDDI (bytes) (pps) (pps) (pps)
サイズイーサネット16MBトークンリングFDDI（バイト）（PPS）（PPS）（PPS）
64 14880 24691 152439
128 8445 13793 85616
256 4528 7326 45620
512 2349 3780 23585
768 1586 2547 15903
1024 1197 1921 11996
1280 961 1542 9630
1518 812 1302 8138
Ethernet size Preamble 64 bits Frame 8 x N bits Gap 96 bits
イーサネットサイズプリアンブル64ビットフレーム8 x nビットギャップ96ビット
16Mb Token Ring size
SD 8 bits
AC 8 bits
FC 8 bits
DA 48 bits
SA 48 bits
RI 48 bits ( 06 30 00 12 00 30 )
SNAP
DSAP 8 bits
SSAP 8 bits
Control 8 bits
Vendor 24 bits
Type 16 bits
Data 8 x ( N - 18) bits
FCS 32 bits
ED 8 bits
FS 8 bits
Tokens or idles between packets are not included
パケット間のトークンまたはアイドルは含まれていません
FDDI size
Preamble 64 bits
SD 8 bits
FC 8 bits
DA 48 bits
SA 48 bits
SNAP
DSAP 8 bits
SSAP 8 bits
Control 8 bits
Vendor 24 bits
Type 16 bits
Data 8 x ( N - 18) bits
FCS 32 bits
ED 4 bits
FS 12 bits
Appendix C: Test Frame Formats
付録C：テストフレーム形式
This appendix defines the frame formats that may be used with these tests. It also includes protocol specific parameters for TCP/IP over Ethernet to be used with the tests as an example.
この付録は、これらのテストで使用できるフレーム形式を定義しています。また、テストで使用されるイーサネット上のTCP/IPのプロトコル固有のパラメーターも含まれています。
The general logic used in the selection of the parameters and the design of the frame formats is explained for each case within the TCP/IP section. The same logic has been used in the other sections. Comments are used in these sections only if there is a protocol specific feature to be explained. Parameters and frame formats for additional protocols can be defined by the reader by using the same logic.
パラメーターの選択で使用される一般的なロジックとフレーム形式の設計は、TCP/IPセクション内の各ケースについて説明されています。同じロジックが他のセクションで使用されています。これらのセクションでは、説明するプロトコル固有の機能がある場合にのみ、コメントが使用されます。追加のプロトコルのパラメーターとフレーム形式は、同じロジックを使用してリーダーが定義できます。
The following section deals with the TCP/IP protocol suite.
次のセクションでは、TCP/IPプロトコルスイートを扱います。
C.2.1 Frame Type.
C.2.1 フレームタイプ。
An application level datagram echo request is used for the test data frame in the protocols that support such a function. A datagram protocol is used to minimize the chance that a router might expect a specific session initialization sequence, as might be the case for a reliable stream protocol. A specific defined protocol is used because some routers verify the protocol field and refuse to forward unknown protocols.
アプリケーションレベルのデータグラムエコー要求は、そのような関数をサポートするプロトコルのテストデータフレームに使用されます。データグラムプロトコルは、信頼できるストリームプロトコルの場合のように、ルーターが特定のセッションの初期化シーケンスを期待する可能性を最小限に抑えるために使用されます。一部のルーターがプロトコルフィールドを検証し、未知のプロトコルを転送することを拒否するため、特定の定義済みプロトコルが使用されます。
For TCP/IP a UDP Echo Request is used.
TCP/IPの場合、UDPエコー要求が使用されます。
Two sets of addresses must be defined: first the addresses assigned to the router ports, and second the address that are to be used in the frames themselves and in the routing updates.
2セットのアドレスを定義する必要があります。まずルーターポートに割り当てられたアドレスと、フレーム自体とルーティングアップデートで使用されるアドレスです。
The network addresses 192.18.0.0 through 198.19.255.255 are have been assigned to the BMWG by the IANA for this purpose. This assignment was made to minimize the chance of conflict in case a testing device were to be accidentally connected to part of the Internet. The specific use of the addresses is detailed below.
ネットワークは192.18.0.0から198.19.255.255から192.18.0.0から、この目的のためにIANAによってBMWGに割り当てられています。この割り当ては、テストデバイスがインターネットの一部に誤って接続される場合に備えて、競合の可能性を最小限に抑えるために行われました。アドレスの特定の使用については、以下に詳しく説明しています。
Half of the ports on a multi-port router are referred to as "input" ports and the other half as "output" ports even though some of the tests use all ports both as input and output. A contiguous series of IP Class C network addresses from 198.18.1.0 to 198.18.64.0 have been assigned for use on the "input" ports. A second series from 198.19.1.0 to 198.19.64.0 have been assigned for use on the "output" ports. In all cases the router port is node 1 on the appropriate network. For example, a two port DUT would have an IP address of 198.18.1.1 on one port and 198.19.1.1 on the other port.
マルチポートルーターのポートの半分は、「入力」ポートと呼ばれ、残りの半分は「出力」ポートと呼ばれますが、一部のテストではすべてのポートを入力と出力の両方として使用しています。198.18.1.0から198.18.64.0までの一連のIPクラスCネットワークアドレスが、「入力」ポートで使用するために割り当てられています。198.19.1.0から198.19.64.0の2番目のシリーズが、「出力」ポートで使用するために割り当てられています。すべての場合において、ルーターポートは適切なネットワーク上のノード1です。たとえば、2つのポートDUTには、1つのポートに198.18.1.1、もう1つのポートに198.19.1.1のIPアドレスがあります。
Some of the tests described in the methodology memo make use of an SNMP management connection to the DUT. The management access address for the DUT is assumed to be the first of the "input" ports (198.18.1.1).
Methodology Memoで説明されているテストの一部は、DUTへのSNMP管理接続を使用しています。DUTの管理アクセスアドレスは、「入力」ポート（198.18.1.1）の最初であると想定されています。
Some of the described tests assume adjacent network routing (the reboot time test for example). The IP address used in the test frame is that of node 2 on the appropriate Class C network. (198.19.1.2 for example)
説明されているテストの一部は、隣接するネットワークルーティングを想定しています（たとえば、再起動時間テスト）。テストフレームで使用されるIPアドレスは、適切なクラスCネットワーク上のノード2のアドレスです。（たとえば198.19.1.2）
If the test involves non-adjacent network routing the phantom routers are located at node 10 of each of the appropriate Class C networks. A series of Class C network addresses from 198.18.65.0 to 198.18.254.0 has been assigned for use as the networks accessible through the phantom routers on the "input" side of DUT. The series of Class C networks from 198.19.65.0 to 198.19.254.0 have been assigned to be used as the networks visible through the phantom routers on the "output" side of the DUT.
テストが非隣接ネットワークルーティングを伴う場合、ファントムルーターは、適切なクラスCネットワークの各ノード10にあります。198.18.65.0から198.18.254.0までの一連のクラスCネットワークアドレスは、DUTの「入力」側のファントムルーターを介してアクセス可能なネットワークとして使用するために割り当てられています。198.19.65.0から198.19.254.0までの一連のクラスCネットワークは、DUTの「出力」側のファントムルーターを介して見えるネットワークとして使用されるように割り当てられています。
The update interval for each routing protocol is may have to be determined by the specifications of the individual protocol. For IP RIP, Cisco IGRP and for OSPF a routing update frame or frames should precede each stream of test frames by 5 seconds. This frequency is sufficient for trial durations of up to 60 seconds. Routing updates must be mixed with the stream of test frames if longer trial periods are selected. The frequency of updates should be taken from the following table.
各ルーティングプロトコルの更新間隔は、個々のプロトコルの仕様によって決定する必要がある場合があります。IP RIPの場合、Cisco IGRPおよびOSPFの場合、ルーティングアップデートフレームまたはフレームは、テストフレームの各ストリームに5秒先に先行する必要があります。この頻度は、最大60秒の試行期間に十分です。ルーティングの更新は、より長い試行期間が選択されている場合、テストフレームのストリームと混合する必要があります。更新の頻度は、次の表から取得する必要があります。
IP-RIP 30 sec IGRP 90 sec OSPF 90 sec
IP-rip 30秒IGRP 90秒OSPF 90秒
In most protocols a procedure is used to determine the mapping between the protocol node address and the MAC address. The Address Resolution Protocol (ARP) is used to perform this function in TCP/IP. No such procedure is required in XNS or IPX because the MAC address is used as the protocol node address.
ほとんどのプロトコルでは、プロトコルノードアドレスとMACアドレス間のマッピングを決定するために手順が使用されます。アドレス解像度プロトコル（ARP）は、TCP/IPでこの関数を実行するために使用されます。MACアドレスがプロトコルノードアドレスとして使用されるため、XNSまたはIPXでそのような手順は必要ありません。
In the ideal case the tester would be able to respond to ARP requests from the DUT. In cases where this is not possible an ARP request should be sent to the router's "output" port. This request should be seen as coming from the immediate destination of the test frame stream. (i.e. the phantom router (Figure 2) or the end node if adjacent network routing is being used.) It is assumed that the router will cache the MAC address of the requesting device. The ARP request should be sent 5 seconds before the test frame stream starts in each trial. Trial lengths of longer than 50 seconds may require that the router be configured for an extended ARP timeout.
理想的なケースでは、テスターはDUTからのARPリクエストに応答することができます。これが不可能な場合は、ARP要求をルーターの「出力」ポートに送信する必要があります。このリクエストは、テストフレームストリームのすぐ近くの目的地から来ると見なされるべきです。（つまり、隣接するネットワークルーティングが使用されている場合は、ファントムルーター（図2）またはエンドノード。）ルーターが要求デバイスのMACアドレスをキャッシュすると想定されています。ARPリクエストは、各トライアルでテストフレームストリームが開始される前に5秒前に送信する必要があります。50秒を超える試行長は、拡張ARPタイムアウトにルーターを構成する必要がある場合があります。
+--------+ +------------+
| | | phantom |------ P LAN
A
IN A------| DUT |------------| |------ P LAN
B
| | OUT A | router |------ P LAN
C
+--------+ +------------+
Figure 2
図2
In the case where full routing is being used
完全なルーティングが使用されている場合
If the test does not involve adjacent net routing the tester must supply proper routing information using a routing update. A single routing update is used before each trial on each "destination" port (see section C.24). This update includes the network addresses that are reachable through a phantom router on the network attached to the port. For a full mesh test, one destination network address is present in the routing update for each of the "input" ports. The test stream on each "input" port consists of a repeating sequence of frames, one to each of the "output" ports.
テストに隣接するネットルーティングが含まれていない場合、テスターはルーティングアップデートを使用して適切なルーティング情報を提供する必要があります。各「宛先」ポートの各試行の前に、単一のルーティングアップデートが使用されます（セクションC.24を参照）。このアップデートには、ポートに接続されたネットワーク上のファントムルーターを介して到達可能なネットワークアドレスが含まれます。完全なメッシュテストの場合、各「入力」ポートのルーティングアップデートに1つの宛先ネットワークアドレスが存在します。各「入力」ポートのテストストリームは、それぞれの「出力」ポートの繰り返しシーケンスで構成されています。
The management overhead test uses SNMP to query a set of variables that should be present in all DUTs that support SNMP. The variables for a single interface only are read by an NMS at the appropriate intervals. The list of variables to retrieve follow:
管理オーバーヘッドテストでは、SNMPを使用して、SNMPをサポートするすべてのDUTに存在する必要がある一連の変数を照会します。単一のインターフェイスの変数は、適切な間隔でNMSによって読み取られます。取得する変数のリストは次のとおりです。
sysUpTime ifInOctets ifOutOctets ifInUcastPkts ifOutUcastPkts
sysuptime ifinoctets ifoutoctets ifinucastpkts ifoutucastpkts
The test frame is an UDP Echo Request with enough data to fill out the required frame size. The data should not be all bits off or all bits on since these patters can cause a "bit stuffing" process to be used to maintain clock synchronization on WAN links. This process will result in a longer frame than was intended.
テストフレームは、必要なフレームサイズを入力するのに十分なデータを備えたUDPエコーリクエストです。これらのパターンは、WANリンクのクロック同期を維持するために「ビットスタッフィング」プロセスを使用する可能性があるため、データはすべてオフまたはすべてのビットであるべきではありません。このプロセスは、意図したものよりも長いフレームになります。
Each of the frames below are described for the 1st pair of DUT ports, i.e. "input" port #1 and "output" port #1. Addresses must be changed if the frame is to be used for other ports.
以下の各フレームについては、DUTポートの最初のペア、つまり「入力」ポート＃1と「出力」ポート＃1について説明します。フレームを他のポートに使用する場合は、アドレスを変更する必要があります。
ARP Request on Ethernet
イーサネットでのARPリクエスト
-- DATAGRAM HEADER
offset data (hex) description
00 FF FF FF FF FF FF dest MAC address send to
broadcast address
06 xx xx xx xx xx xx set to source MAC address
12 08 06 ARP type
14 00 01 hardware type Ethernet = 1
16 08 00 protocol type IP = 800
18 06 hardware address length 48 bits
on Ethernet
19 04 protocol address length 4 octets
for IP
20 00 01 opcode request = 1
22 xx xx xx xx xx xx source MAC address
28 xx xx xx xx source IP address
32 FF FF FF FF FF FF requesting DUT's MAC address
38 xx xx xx xx DUT's IP address
-- DATAGRAM HEADER offset data (hex) description 00 FF FF FF FF FF FF dest MAC address is broadcast 06 xx xx xx xx xx xx source hardware address 12 08 00 type
- データグラムヘッダーオフセットデータ（hex）説明00 ff ff ff ff ff ff ff dest macアドレスはブロードキャスト06 xx xx xxxxxxxx xxソースハードウェアアドレス12 08 00タイプ
-- IP HEADER
14 45 IP version - 4, header length (4
byte units) - 5
15 00 service field
16 00 EE total length
18 00 00 ID
20 40 00 flags (3 bits) 4 (do not
fragment),
fragment offset-0
22 0A TTL
23 11 protocol - 17 (UDP)
24 C4 8D header checksum
26 xx xx xx xx source IP address
30 xx xx xx destination IP address
33 FF host part = FF for broadcast
-- UDP HEADER
34 02 08 source port 208 = RIP
36 02 08 destination port 208 = RIP
38 00 DA UDP message length
40 00 00 UDP checksum
-- RIP packet
42 02 command = response
43 01 version = 1
44 00 00 0
-- net 1
46 00 02 family = IP
48 00 00 0
50 xx xx xx net 1 IP address
53 00 net not node
54 00 00 00 00 0
58 00 00 00 00 0
62 00 00 00 07 metric 7
-- net 2
66 00 02 family = IP
68 00 00 0
70 xx xx xx net 2 IP address
73 00 net not node
74 00 00 00 00 0
78 00 00 00 00 0
82 00 00 00 07 metric 7
-- net 3
86 00 02 family = IP
88 00 00 0
90 xx xx xx net 3 IP address
93 00 net not node
94 00 00 00 00 0
98 00 00 00 00 0
102 00 00 00 07 metric 7
-- net 4
106 00 02 family = IP
108 00 00 0
110 xx xx xx net 4 IP address
113 00 net not node
114 00 00 00 00 0
118 00 00 00 00 0
122 00 00 00 07 metric 7
-- net 5
126 00 02 family = IP
128 00 00 0
130 00 net 5 IP address
133 00 net not node
134 00 00 00 00 0
138 00 00 00 00 0
142 00 00 00 07 metric 7
-- net 6
146 00 02 family = IP
148 00 00 0
150 xx xx xx net 6 IP address
153 00 net not node
154 00 00 00 00 0
158 00 00 00 00 0
162 00 00 00 07 metric 7
To be defined.
定義します。
UDP echo request on Ethernet
イーサネットでのUDPエコーリクエスト
-- DATAGRAM HEADER offset data (hex) description 00 xx xx xx xx xx xx set to dest MAC address 06 xx xx xx xx xx xx set to source MAC address 12 08 00 type
- データグラムヘッダーオフセットデータ（hex）説明00 xx xx xx xxxxxxxx xx dest macアドレスに設定
-- IP HEADER
14 45 IP version - 4 header length 5 4
byte units
15 00 TOS
16 00 2E total length*
18 00 00 ID
20 00 00 flags (3 bits) - 0 fragment
offset-0
22 0A TTL
23 11 protocol - 17 (UDP)
24 C4 8D header checksum*
26 xx xx xx xx set to source IP address**
30 xx xx xx xx set to destination IP address**
-- UDP HEADER
34 C0 20 source port
36 00 07 destination port 07 = Echo
38 00 1A UDP message length*
40 00 00 UDP checksum
-- UDP DATA
42 00 01 02 03 04 05 06 07 some data***
50 08 09 0A 0B 0C 0D 0E 0F
* - change for different length frames
* - 異なる長さのフレームの変更
** - change for different logical streams
*** - fill remainder of frame with incrementing octets,
repeated if required by frame length
Values to be used in Total Length and UDP message length fields:
全長およびUDPメッセージの長さフィールドで使用される値：
frame size total length UDP message length
64 00 2E 00 1A
128 00 6E 00 5A
256 00 EE 00 9A
512 01 EE 01 9A
768 02 EE 02 9A
1024 03 EE 03 9A
1280 04 EE 04 9A
1518 05 DC 05 C8
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。