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.
著作権（C）インターネット協会（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.
ベンダーは、多くの場合、彼らの製品市場で有利な立場を与える試みで「specsmanship」に取り組んでいます。これは、多くの場合、製品の潜在的なユーザーを混乱させるために、「煙＆ミラー」が含まれます。
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.
この文書で説明したテストの数があります。いないすべてのテストのは、テスト対象のデバイスのすべてのタイプ（のDUT）に適用されます。ベンダーは、製品の特定の種類によってサポートできるすべてのテストを実行する必要があります。著者は、それが推奨される条件のすべてNDER推奨すべてのテストを実行するためにかなりの時間がかかりますことを理解しています。私たちは、結果は努力の価値があると信じています。付録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.
*この単語、または単語「必須」とは、項目が仕様の絶対的な要件であることを意味し、「SHALL」、「しなければなりません」。
* "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.
*「SHOULD」この単語、あるいは「推奨」形容詞がこの項目を無視する特定の事情の正当な理由が存在することを意味するが、完全な意味合いを理解すべきであるとする場合は慎重に別のコースを選択する前に秤量しました。
* "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.
*「MAY」この単語または形容詞「OPTIONAL」は、この項目が本当に任意であることを意味しています。それは、製品を強化するため、特定の市場には、例えば、それを必要とするか、またはので、一つのベンダーは、アイテムを含めることを選択してもよいです。別のベンダは同じ項目を省略することができます。
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".
それが実装されたプロトコルのためのMUST要件の一つ以上を満たすために失敗した場合、実装は準拠していません。すべてのMUSTとそのプロトコルのためのすべてのSHOULD要件を満たす実装は「無条件に準拠した」と言われて。すべてのMUST要件ではなく、そのプロトコルのためのすべてのSHOULD要件を満たすものは、「条件付き準拠した」と言われています。
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の送信ポートから受信ポートへのテスターの送信ポートから作られます。テスタの両方がテストトラフィックを送信し、トラフィックが転送された後、戻ってそれを受信するが、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.
二つの異なる設定は、例えばバックボーンFDDIリングに異なるメディアタイプ、ローカル・イーサネットのネットワークを接続するために、現実世界のネットワークで使用されているDUTをテストするために使用することができます。テスタはセットアップが使用される図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.
二つの同一のDUTを設定し、他のテストで使用されています。より正確に現実の世界をシミュレートすることができる。多くの場合、この設定（図3参照）。たとえば、WANリンクまたは高速バックボーンと一緒に2つのLANを接続します。これは、イーサネット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の構成や設定を変更せずに実行されることが期待されます。例えば、フレーム処理レートのテストの間にフレーム処理バッファのサイズを変更するか、そのプロトコルのスループットをテストするときつのトランスポートプロトコルが、すべてを無効にすることは受け入れられません。スループットにフィルタの効果を決定するために試験を開始するときに設定を変更する必要があるが、唯一の変更は、特定のフィルタを有効にすることでなければなりません。設定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
６４、 １２８、 ２５６、 ５１２、 １０２４、 １２８０、 １５１８
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
５４、 ６４、 １２８、 ２５６、 １０２４、 １５１８、 ２０４８、 ４４７２
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オクテットです。 4472オクテットの最大サイズは、16MBトークンリングの代わりに、なぜなら多くのトークンリングインタフェースによって課されるサイズ制限の17.9Kbの理論的なサイズのために推奨されています。サイズのリマインダーは、他のタイプのメディアとの直接比較を可能にするように選択されています。より高いデータレートが望まれる場合、IP（すなわちないUDP）フレームは最小フレームサイズが46オクテットである場合には、加えて使用することができます。
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の最小サイズのフレームは54の最小サイズは、リング性能をトークンに直接比較を可能にするために推奨され、53オクテットです。 4472の最大サイズは、比較の同じタイプを許可する代わりに、4500オクテットの理論上の最大サイズのお勧めします。より高いデータレートが望まれる場合、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.
相互接続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.
たとえば、IPのテストは、イーサネットリンクにFDDIから行くとき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.
同じ試験は、ブリッジ状のDUTに対して実行されるべきであるが、この場合、ブロードキャストパケットが処理され、すべての出力に浸水します。
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つの応答フレームに収まらなければなりません。応答フレームは、テスト装置によって検証されるべきです。使用されるべき特定のクエリフレームの一例は、付録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」へのルーティングテーブルの状態を設定し、もう一つは「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.
フィルタは、選択的正常に転送されるフレームの転送を阻害するルータとブリッジに追加されます。これは通常、1つの領域と他の間で受け入れられているデータのセキュリティ制御を実装するために行われます。異なる製品は、フィルタを実装するためのさまざまな機能を持っています。
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は、最初のフィルタ条件を追加するように構成され、テストが行われるべきです。このフィルタは、テスト・データ・ストリームの転送を可能にするはずです。ルータでは、このフィルタは、次の形式になります
forward input_protocol_address to output_protocol_address
output_protocol_addressへ前進input_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
output_protocol_addressにブロックinput_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.
フィルタアドレスの二つのセットが、単一のフィルタケース25のフィルタケースのための1つに1つ必要です。
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.19.65.2にIPアドレス198.18.1.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
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つの宛先プロトコルアドレスと、上述したフィルタのようないくつかの条件のために、実用的な要件を、データの単一の論理的なストリームを使用してこれらの試験を実施することが容易です。現実の世界でのネットワークは、データの単一のストリームに限定されるものではありません。テストスイートは、送信元と宛先アドレスのペア（ブリッジ試験用またはハードウェア）は、単一のプロトコルで最初に実行する必要があります。テストは、ランダム宛先アドレスを使用して繰り返されるべきです。ルータをテストしながら、アドレスがランダムかつ均一にランダムかつ均一ブリッジの完全なMAC範囲にわたって分布し、256のネットワークの範囲に亘って分配されなければなりません。特定のアドレスは、付録Cに示されているIPに使用する範囲
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に送信：パケットをXに、パケットアウトにY、アウトZストリームにパケットが入力Bに送信される：パケットをXに、パケットアウトにY、アウトXへの入力Cパケットに送られたパケットのうち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つのパケット、Z.で、その後3つのパケットこの手順では、現実の世界のように、DUTが持っているだろうことを保証することに注意してください複数のパケットに対処するために、同時に同じ出力に宛て。
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を比較する以外に解釈されるか任意のアイデアを持っていません。
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.)
（DUTに例えば、64バイトのIP、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は、相互接続ネットワークのDUTのシステムによって置き換えられます。このテスト方法は、デバイス/メディア/サービス/プロトコルの組み合わせの様々なベンチマークをサポートしています。例えば、LAN-に-WAN-to-LANのテストのための構成は次のようになります。
(1) 802.3-> DUT 1 -> X.25 @ 64kbps -> DUT 2 -> 802.3
（1）802.3-> I 1 - > X.25 @ 64kbpsの - > I 2 - > 802.3
Or a mixed LAN configuration might be:
または混合LANの設定は次のようになります。
(2) 802.3 -> DUT 1 -> FDDI -> DUT 2 -> FDDI -> DUT 3 -> 802.3
（2）802.3 - >被測定物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を単一のシステムとして扱われるため、この方法には限界があります。例えば、この方法は、試験システムの集計ベンチマークを得ることができます。そのベンチマークを単独で、しかし、必ずしもDUTの間の挙動の非対称性を反映しない場合があり、待ち時間は、他の装置（例えば、のCSU / 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つだけのフレームを送信しながら、これらのテストは、最初に行われるべきです。
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.
いくつかの現在の高性能ワークステーション・サーバは、スループットを最大化するために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:
特定のテストは、複数の試験から構成されています。各試験は、特定の入力フレーム速度で、例えば、損失率情報の一つを返します。各試験では、相の数で構成されています。
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により送信された解像度の要求に対処するために応答することができるべきです。
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.
私たちは、単一の値が広告目的のために望まれる場合、ベンダーがメディアの最小フレームサイズのレートを選択することを前提としています。これが行われる場合、図は、秒あたりのフレーム数で表現されなければなりません。レートはまた、毎秒ビット（又はバイト）であればベンダー望むように表すことができます。性能のステートメントは、テストで使用されるプロトコルのフレームサイズ、及びD / Aタイプのメディアの理論的限界/ C、使用されるフレームのサイズ/ B、/測定された最大フレームレートを含まなければなりません。単一の値は広告コピーの一部として使用されている場合でも、結果の完全なテーブルは製品データシートに含まれるべきです。
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秒依存実装された後、一つのフレームに含まれるべきです。このフレームが完全に送信された時刻が記録されている（タイムスタンプ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に従ってタイムスタンプBマイナスタイムスタンプAです。
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
（（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％に相当するフレームレートのために実行する必要があります。このレートの80％を、次に使用された最大速度の90％に相当する速度で作業を繰り返して。この配列にはフレームが失われないされた二つの連続試験が存在するまで（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％でなければなりません。グラフ上に複数のラインがMAYは、異なるフレームサイズ、プロトコル、及びデータストリームのタイプのフレーム損失率を報告するために使用されます。
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.
少なくとも60秒間、記録されたスループットレートまたは低い方メディアの最大速度、速度110％でフレームのストリームを送信します。タイムスタンプでAは、上記の速度の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.
手順：第1の試験で使用されるメディア上の最小フレームサイズの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でリセットを引き起こします。フレームが転送され、最初のストリームと新しいストリーム（タイムスタンプB）の最初のフレームの最後のフレーム（タイムスタンプA）が受信された時間を記録することを開始するまで、出力を監視します。停電リセット試験は、DUTへの電力がリセットを引き起こすの代わりに10秒間中断されるべきであること以外は、上記のように行われます。
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ケンブリッジ、MA 02138
Phone: +1 617 495-3864 Fax: +1 617 496-8500 EMail: sob@harvard.edu
電話：+1 617 495-3864ファックス：+1 617 496-8500 Eメール：sob@harvard.edu
Jim McQuaid NetScout Systems 4 Westford Tech Park Drive Westford, MA 01886
ジムMcQuaid NetScoutのシステム4ウェストフォードテックパークドライブウェストフォード、MA 01886
Phone: +1 978 614-4116 Fax: +1 978 614-4004 EMail: mcquaidj@netscout.com
電話：+1 978 614-4116ファックス：+1 978 614-4004 Eメール：mcquaidj@netscout.com
Appendix A: Testing Considerations
付録A：テストの注意事項
A.1 Scope Of This Appendix
この付録のA.1スコープ
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.典型的なテストの練習試行の所定のセットは、同時に複数のプロトコルを行使することができるにもかかわらず、試験されるすべてのプロトコルを有効にし、プロトコルのさらなる構成ですべてのテストを実施することでした。これは、「調整」とは、単一のプロトコルのための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.混合したプロトコルからなるトラフィックストリームを使用して行うテストは、個々のプロトコルと試験との間の大きな違いを示しませんでした。プロトコルテストとプロトコル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.
前記ワイドエリアネットワーク（WAN）のパフォーマンスは、WANモデムの適切な短期運搬バージョンによって接続された2つの同一のデバイスを設定することによって試験することができます。パフォーマンスは、他のDUT上のLANインターフェイスに1つの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)
（ロジャー・Beemanが提供する、シスコシステムズ）
Size Ethernet 16Mb Token Ring FDDI (bytes) (pps) (pps) (pps)
サイズイーサネット16Mビットトークンリング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
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×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
16MBトークンリングサイズSD 8ビットAC 8ビットFC 8ビットDA SA 48ビットRI 48ビット（06 30 00 12 00 30）SNAP DSAP 8ビットSSAP 8ビットは8ビットベンダーを制御装置24ビットが16ビットデータ8 Xを（タイプ48ビットN - 18）FCS、32ビットED 8ビットFS 8ビットをビット
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
FDDIサイズプリアンブル64ビットSD 8ビットFC 8ビットDA SA 48ビットスナップ48ビット
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
DSAP 8ビットは、8ビット、24ビット、16ビットデータの8×8型ビットベンダーを制御SSAP（N - 18）ビットFCS 32ビットED 4ビットFS 12ビット
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のプロトコル固有のパラメータを含みます。
C.1. Introduction
C.1。前書き
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部内の各場合について説明します。同じロジックは、他のセクションで使用されてきました。コメントを説明するためのプロトコル固有の機能がある場合にのみ、これらのセクションで使用されています。追加のプロトコルのパラメータとフレームフォーマットは同じロジックを使用して、リーダによって定義することができます。
C.2. TCP/IP Information
C.2。 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エコー要求が使用されています。
C.2.2 Protocol Addresses
C.2.2プロトコル・アドレス
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.
198.19.255.255を介してネットワークアドレス192.18.0.0は、この目的のためにIANAによってBMWGに割り当てられています。この割り当ては、試験装置が誤ってインターネットの一部に接続されていた場合には、競合の可能性を最小限にするために作られました。アドレスの特定の使用は、以下に説明されます。
C.2.2.1 Router port protocol addresses
C.2.2.1ルーターのポート・プロトコル・アドレス
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.19.1.1に198.18.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).
方法論のメモで記述されたテストのいくつかは、DUTへのSNMP管理接続を使用しています。 DUTの管理アクセスアドレスは、「入力」ポート（198.18.1.1）の最初であると仮定されます。
C.2.2.2 Frame addresses
C.2.2.2フレームアドレス
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の「出力」側の仮想ルータを通して見えるネットワークとして使用されるように割り当てられています。
C.2.3 Routing Update Frequency
C.2.3ルーティング更新頻度
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、シスコIGRPおよびOSPFのためのルーティング更新フレームまたはフレームのために5秒テストフレームの各ストリームに先行しなければなりません。この周波数は最大60秒の試用期間には十分です。長い試用期間が選択されている場合、ルーティングアップデートは、テストフレームのストリームと混合されなければなりません。更新の頻度は、以下の表から取られるべきです。
IP-RIP 30 sec
IGRP 90 sec
OSPF 90 sec
C.2.4 Frame Formats - detailed discussion
C.2.4フレームフォーマット - 詳細な議論
C.2.4.1 Learning Frame
C.2.4.1ラーニングフレーム
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
完全なルーティングが使用されている場合に
C.2.4.2 Routing Update Frame
C.2.4.2ルーティング更新フレーム
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つの宛先ネットワークアドレスは、「入力」ポートの各々のルーティングアップデート中に存在します。各「入力」ポートでテストストリームは、フレームの繰り返しシーケンス、「出力」ポートのそれぞれ1つから成ります。
C.2.4.3 Management Query Frame
C.2.4.3管理クエリフレーム
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をサポートしているすべてのDUT中に存在すべき変数のセットを照会するためにSNMPを使用しています。単一のインターフェイスのための変数は、唯一の適切な間隔でNMSによって読み取られます。フォローを取得する変数のリスト：
sysUpTime
ifInOctets
ifOutOctets
ifInUcastPkts
ifOutUcastPkts
C.2.4.4 Test Frames
C.2.4.4テストフレーム
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エコー要求です。これらpattersは、WANリンク上のクロック同期を維持するために使用される「ビットスタッフィング」プロセスを引き起こす可能性がありますので、データはすべてのビットオフまたは全てのビットであってはなりません。このプロセスは、意図していたよりも長いフレームになります。
C.2.4.5 Frame Formats - TCP/IP on Ethernet
C.2.4.5フレームフォーマット - イーサネット上のTCP / IP
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の1対について記載されています。フレームは、他のポートに使用される場合のアドレスが変更されなければなりません。
C.2.6.1 Learning Frame
C.2.6.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
- データグラムヘッダのオフセットデータ（16進数）説明00 FF FF FF FF FF FF DEST MACアドレスはアドレス06をブロードキャストする送信XX XX XX XX XX XX MACが12 08 06 ARPタイプ14 00 01ハードウェアタイプのイーサネットアドレスソースに設定= 1~16 IP 20 00 01オペコード要求の08 00プロトコルタイプIP = 800 18 06ハードウェアアドレス長は、イーサネット（登録商標）19 04プロトコルアドレス長で48ビット4つのオクテット= 1 22のXX XX XX XX XX XX MACアドレス源28 XX XX XX XX元IPアドレス32 FF FF FF FF FF FF要求DUTのMACは38 XX XX XX XX DUTのIPアドレスに対応します
C.2.6.2 Routing Update Frame
C.2.6.2ルーティング更新フレーム
-- 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
-- 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
- IPヘッダ14 45 IPバージョン - 4、ヘッダ長（4バイト単位） - 5 15 00、サービスフィールド16 00 EE全長18 00 00 ID 20 40 00フラグ（3ビット）4（断片化していない）、フラグメントオフセット-0 22 0A TTL 23 11プロトコル - 放送用17（UDP）24 C4 8Dヘッダチェックサム26 XX XX XX XX送信元IPアドレス30 XX XX XX宛先IPアドレス33 FFホスト部FF =
-- 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
- UDPヘッダ34 02 08ソースポート208 = RIP 36 02 08宛先ポート208 = RIP 38 00 DA UDPメッセージ長40 00 00 UDPチェックサム
-- RIP packet 42 02 command = response 43 01 version = 1 44 00 00 0
- RIPパケット42 02コマンド応答= 43 01バージョン= 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
- ネット1 46 00 02ファミリー= IP 48 00 00 0 50 XX XX XXネット1のIPアドレス53 00ネットは、54 00 00 00 00 0 58 00 00 00 00 0 62 00 00 00 07メトリック7ノードではありません
-- net 2 66 00 02 family = IP 68 00 00 0 70 xx xx xx net 2 IP address
- ネット2 66 00 02家族= IP 68 00 00 0 70 XX XX XXネット2 IPアドレス
73 00 net not node 74 00 00 00 00 0 78 00 00 00 00 0 82 00 00 00 07 metric 7
73 00ネットないノード74 00 00 00 00 0 78 00 00 00 00 0 82 00 00 00 07メトリック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
- ネット3 86 00 02ファミリー= IP 88 00 00 0 90 XX XX XX正味3のIPアドレス93 00ネットないノード94 00 00 00 00 0 98 00 00 00 00 0 102 00 00 00 07メトリック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
- ネット4 106 00 02ファミリー= IP 108 00 00 0 110 XX XX XXネット4 IPアドレス113 00ネット114 00 00 00 00 0 118 00 00 00 00 0 122 00 00 00 07メトリック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
- ネット5 126 00 02ファミリー= IP 128 00 00 0 130 00ネット5 IPアドレス133 00ネット134 00 00 00 00 0 138 00 00 00 00 0 142 00 00 00 07メトリック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
- ネット6 146 00 02ファミリー= IP 148 00 00 0 150 XX XX XX正味6 IPアドレス153 00ネット154 00 00 00 00 0 158 00 00 00 00 0 162 00 00 00 07メトリック7ノードではありません
C.2.4.6 Management Query Frame
C.2.4.6管理クエリフレーム
To be defined.
定義します。
C.2.6.4 Test Frames
C.2.6.4テストフレーム
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
-- 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**
- IPヘッダ14 45 IPバージョン4 - ヘッダ長5つの4バイト単位15 00 TOS 16 00 2E全長* 18 00 00 ID 20の00 00フラグ（3ビット） - オフセット0 22 0A TTL 23 11プロトコルを0断片 - 17（UDP）24 C4 8Dヘッダチェックサム* 26 XX XX XX XX送信元IPアドレスに設定** 30 XX XX XX XX宛先IPアドレスに設定**
-- 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ヘッダ34 C0 20ソースポート36 00 07宛先ポート07 =エコー38 00 1A UDPメッセージ長* 40 00 00 UDPチェックサム
-- UDP DATA 42 00 01 02 03 04 05 06 07 some data*** 50 08 09 0A 0B 0C 0D 0E 0F
- UDPデータ42 00 01 02 03 04 05 06 07いくつかのデータ*** 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.
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。