RFC1944 日本語訳
1944 Benchmarking Methodology for Network Interconnect Devices. S.Bradner, J. McQuaid. May 1996. (Format: TXT=66061 bytes) (Obsoleted by RFC2544) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Bradner
Request for Comments: 1944 Harvard University
Category: Informational J. McQuaid
Bay Networks
May 1996
コメントを求めるワーキンググループS.ブラドナーの要求をネットワークでつないでください: 1944年のハーバード大学カテゴリ: 情報のJ.McQuaidベイネットワークス1996年5月
Benchmarking Methodology for Network Interconnect Devices
ネットワーク内部連絡デバイスのためのベンチマーキング方法論
Status of This Memo
このメモの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
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は様々なメディアの特定のフレーム・サイズと共に使用されるべき最大のフレームレートの参照表です、そして、Appendix Cはテストで使用されるためにフレーム形式に関するいくつかの例を出します。
1. Introduction
1. 序論
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.
「ネットワーク内部連絡デバイスのためのベンチマーキング用語」(RFC1242)という前のドキュメントは本書では使用される用語の多くを定義しました。 用語ドキュメントはこのドキュメントを利用するのを試みる前に、参照されるべきです。
Bradner & McQuaid Informational [Page 1] RFC 1944 Benchmarking Methodology May 1996
[1ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
2. Real world
2. 本当の世界
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.
このドキュメントを製作する際に、作者は、実際に説明されたテストを実行する装置を組立てなければならないという要件を覚えておくのを試みました。 私たちはテストについてすべてを実装するために設備利用可能な状態で「すぐ入手できること」を知りませんが、そのような設備を構成できるのは、私たちの意見です。
3. Tests to be run
3. 実行されるべきテスト
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)で適用されるというわけではありません。 ベンダーは特定のタイプの製品で後押しされることができるテストのすべてを実行するべきです。 作者は、それが働くために、お勧めのテストのすべてがお勧めの状態のすべてをnderするかなりの期間に取るのを理解しています。 私たちは、結果が取り組みの価値があると信じています。 付録Aは含まれるべきである私たちが特定のケースのために信じているテストと状態のいくつかを記載します。
4. Evaluating the results
4. 成果の検討
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に送るレートが環境のためにルータを選択する際に役に立つようにそうしないほとんどならない、()、そのプロトコルをサポートしてくださいだろう。 特定のネットワーク施設に関連しているそのデータさえ評価するのは容易に利用可能でないかもしれない経験を必要とするでしょう。 その上、少ない数のトライアルの再現可能性、変化、および統計的な意味を見なしながら、一般に、受け入れられたテスト習慣の理解で実行されるべきテストの品揃えとテストデータの評価をしなければなりません。
5. Requirements
5. 要件
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.
* "MUST" This単語、または単語が「必要であり」、“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"This単語か形容詞がこの項目を無視する特定の事情の正当な理由を存在するかもしれない手段に「推薦しました」が、完全な含意は、理解されていて異なったコースを選ぶ前に慎重に熟慮されたケースであるべきです。
* "MAY" This word or the adjective "OPTIONAL" means that this item
is truly optional. One vendor may choose to include the item because
* 「5月」This単語か「任意である」という形容詞が、本当に、この項目が任意であることを意味します。 1つのベンダーが、項目を含んでいるのを選ぶかもしれません。
Bradner & McQuaid Informational [Page 2] RFC 1944 Benchmarking Methodology May 1996
[2ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.
特定の市場がそれを必要とする、それは例えば製品を高めます。 別のベンダーは同じ項目を省略するかもしれません。
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つか以上を満たさないなら実装が対応でない、それが実装するプロトコルのための要件はそうしなければなりません。 そして、すべてを満たす実装、プロトコルのためのすべてのSHOULD要件が「無条件に言いなりになる」と言われています;でなければならない すべてを満たすもの、プロトコルのためのすべてのSHOULD要件だけが「条件付きに言いなりになる」と言われているというわけではないという要件はそうしなければなりません。
6. Test set up
6. セットアップされたテスト
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を参照します) テスターがテストトラフィックを送って、それを受け返すので、DUTだけをトラフィックに送った後に、テスターは、伝えられたパケットのすべてが受け取られたかどうか容易に決定して、正しいパケットが受け取られたことを確かめることができます。 別々の伝えてデバイスを受けるのに同じ機能性を得ることができますが(図2を見てください)、それらが、あるコンピュータによって独身のテスターをシミュレートする方法で離れて制御されない場合、正確にテスト(特にスループットテスト)のいくつかを実行するのに必要である作業は禁止である場合があります。
+------------+
| |
+------------| tester |<-------------+
| | | |
| +------------+ |
| |
| +------------+ |
| | | |
+----------->| DUT |--------------+
| |
+------------+
Figure 1
+------------+ | | +------------| テスター| <、-、-、-、-、-、-、-、-、-、-、-、--+ | | | | | +------------+ | | | | +------------+ | | | | | +----------->| DUT|--------------+ | | +------------+ 図1
+--------+ +------------+ +----------+
| | | | | |
| sender |-------->| DUT |--------->| receiver |
| | | | | |
+--------+ +------------+ +----------+
Figure 2
+--------+ +------------+ +----------+ | | | | | | | 送付者|、-、-、-、-、-、-、--、>| DUT|、-、-、-、-、-、-、-、--、>| 受信機| | | | | | | +--------+ +------------+ +----------+ 図2
Bradner & McQuaid Informational [Page 3] RFC 1944 Benchmarking Methodology May 1996
[3ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
6.1 Test set up for multiple media types
6.1 テストはマルチメディアタイプを主張しました。
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をテストするのに2つの異なったセットアップを使用できました。 テスターは両方のメディアにタイプをサポートすることができました、その場合、図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同じDUTsがセットアップされたもう片方のテストで使用されます。 (図3を参照します) 多くの場合、セットアップされたこれは、より正確に本当の世界をシミュレートするかもしれません。 例えば、WANと共に2つのLANを接続して、バックボーンをリンクするか、または高さ、促進してください。 これほど設定している上はイーサネットLANのクライアントがFDDIバックボーンでサーバと対話していたシステムをシミュレートするのが上手でないでしょう。
+-----------+
| |
+---------------------| tester |<---------------------+
| | | |
| +-----------+ |
| |
| +----------+ +----------+ |
| | | | | |
+------->| DUT 1 |-------------->| DUT 2 |---------+
| | | |
+----------+ +----------+
+-----------+ | | +---------------------| テスター| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | | | | +-----------+ | | | | +----------+ +----------+ | | | | | | | +------->| DUT1|、-、-、-、-、-、-、-、-、-、-、-、-、--、>| DUT2|---------+ | | | | +----------+ +----------+
Figure 3
図3
7. DUT set up
7. セットアップされたDUT
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を構成しなければなりません。 明確に、サポートしているプロトコルのすべてがこのセットの間、上がった状態で構成されて、可能にされる(Appendix Aを見る)と予想されます。 特異的な試験をするのが必要であるのを除いて、テストのすべてが何らかの方法でDUTの構成かセットアップを変えないで実行されると予想されます。 そのプロトコルに関するスループットをテストするとき、例えば、フレーム取り扱い率のテストの間のフレーム取り扱いバッファのサイズを変えるか、またはほとんど1つがトランスポート・プロトコルであることを無効にするのが許容できません。 スループットへのフィルタの効果を決定するためにテストを始めるとき、構成を変更するのが必要ですが、唯一の変化が特定のフィルタを可能にすることになっていなければなりません。 SHOULDに用意ができているDUTは通常、推薦されたルーティングアップデート間隔を含んで、頻度を生かします。 結果のレポートの一部としてどんな機能が障害があるかを含むテストの間、中古のソフトウェアと正確なDUT構成の特定のバージョンを含まなければなりません。
Bradner & McQuaid Informational [Page 4] RFC 1944 Benchmarking Methodology May 1996
[4ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
8. Frame formats
8. フレーム形式
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にイーサネットの上で使用するテストフレームの書式はAppendix Cに示されます: フレーム形式をテストしてください。 これらはテストがこのプロトコル/メディア組み合わせのために本書では説明して、これらのフレームが使用される中古のコネがテスト他のプロトコル/メディア組み合わせのためのテンプレートであったならフレーム形式SHOULDを強要します。 結果のレポートに特定のテストシリーズのためにテストフレームを定義するのに使用される特定の形式を含まなければなりません。
9. Frame sizes
9. フレーム・サイズ
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.
説明のすべてがSHOULDをテストします。多くのフレーム・サイズで、実行されてください。 明確に、サイズSHOULDは、DUT性能の完全な特殊化を得ることができるように中間でテストと十分なサイズの下でメディアのテストでプロトコルのための最大の、そして、最小の正統のサイズを含んでいます。 有名であるところを除いて、少なくとも5フレームはSHOULDを大きさで分けます。各試験条件がないかどうかテストされます。
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 Echo要求フレームは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の1フレーム処理あたりのオーバーヘッドを特徴付けるのを助けることです。
9.1 Frame sizes to be used on Ethernet
9.1 イーサネットで使用されるべきフレームサイズ
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.
これらのサイズは、よりわずかなフレーム・サイズと、より高いフレームレートのための、よりすばらしい粒状でイーサネット規格によって受入れられた最大の、そして、最小のフレーム・サイズとこれらの極端の間のいくつかのサイズを含んでいます。
Bradner & McQuaid Informational [Page 5] RFC 1944 Benchmarking Methodology May 1996
[5ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
9.2 Frame sizes to be used on 4Mb and 16Mb token ring
9.2 4Mbで使用されるべきフレームサイズと16Mbのトークンリング
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の八重奏です。 4472の八重奏の最大サイズは多くのトークンリングインタフェースによって課されたサイズ制限で17.9KBの理論上のサイズの代わりに16Mbのトークンリングのために推薦されます。 サイズを思い出させるものが他のタイプのメディアで直接比較を可能にするのが選択されます。 より高いデータ信号速度が望まれているなら、IP(すなわち、UDPでない)フレームはさらに、使用されるかもしれません、その場合、最小のフレーム・サイズが46の八重奏です。
9.3 Frame sizes to be used on FDDI
9.3 FDDIで使用されるべきフレームサイズ
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の八重奏です。
9.4 Frame sizes in the presence of disparate MTUs
9.4 異種のMTUsの面前でフレームサイズ
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がいつ接続をサポートするかは異種のMTUs、使用される*より大きい*MTU SHOULDとのリンクへのフレーム・サイズにテストされるプロトコルの限界までリンクされます。 内部連絡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断片化をサポートしないなら、イーサネットには、大き過ぎるそれらのフレームの伝送速度はゼロとして報告されるべきです。
10. Verifying received frames
10. 容認されたフレームについて確かめます。
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
テスト設備SHOULDは実際の進められたテストフレームではなく、試運転の間に受け取られたどんなフレームも捨てます。 例えば、生きているままでいてください、そして、アップデートフレームSHOULD NOTを発送して、カウントで含められてください。
Bradner & McQuaid Informational [Page 6] RFC 1944 Benchmarking Methodology May 1996
[6ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
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.
容認されたフレームについて。 どのような場合でも、容認されたフレームの長さについて確かめて、テスト設備SHOULDは、予想された長さを合わせるのをチェックします。
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.
望ましくは、テスト設備SHOULDは伝えられたフレームに一連番号を含んで、これらの数がないかどうか容認されたフレームの上にチェックします。 これが完了しているなら、SHOULDが下げられたフレームの数に加えて含む報告された結果と、故障していた状態で受け取られたフレームの数と、フレームが受けた写しの数と系列に付番する容認されたフレームでギャップの数です。 この機能性が説明されたテストのいくつかに必要です。
11. Modifiers
11. 修飾語
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性能を知るのは役に立つかもしれません。 これらの状態のいくつかが以下に述べられます。 SHOULDがテスト設備ができるのと同じくらい多くをこれらの状態を含んでいるという生成する報告された結果。 テストSHOULDのスイートは、いずれも条件を変更しないで実行された1番目であり、次に、それぞれ状態の下を繰り返しました。別々に。 条件を変更が(例えば、管理質問)であると生成するのに必要であるフレームは、これらのテストの結果を比較する能力を保持するために、正常なテストフレームと同じデータ・ストリームでテストフレームの1つに代わって含められていて、別々のネットワークポートの上のDUTに供給されないでしょう。
11.1 Broadcast frames
11.1 放送フレーム
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.
ほとんどのルータデザインでは、ハードウェア放送演説に扱われたフレームが受け取られているとき、特別な処理が必要です。 ブリッジ(またはルータのブリッジモードで)では、これらの放送フレームをポートの数へあふれさせなければなりません。 テストのストリームはSHOULDを縁どっています。1%のフレームがハードウェア放送演説に扱われている状態で、増大してください。 ルータが処理する必要はないタイプには放送演説に送られたフレームがあるはずです。 このテストの目的は何かストリームにおける、他のデータの伝送速度への効果があるかどうか決定することです。 使用されるべきである特定のフレームはテストフレーム形式ドキュメントに含まれています。 例えば、あらゆる100番目が縁どるデータ・ストリームの間中分配されて、放送フレームSHOULDは均等にそうです。
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にもかかわらず、この場合実行されて、放送パケットが処理されるということであり、あふれるSHOULDをすべての出力にテストします。
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
1%の放送フレームのレベルが抵当に入れることができる経験にもかかわらず、ドラッグ毒性評価のような、より高いレベルが必要である多くのネットワークよりはるかに高いのが理解されています。
Bradner & McQuaid Informational [Page 7] RFC 1944 Benchmarking Methodology May 1996
[7ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
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.
そうでなければシステム性能の正常な可変性の中にしばしば下がる効果。 設計要素のため、何らかのテスト設備は、代替のフレームのレベルがこの安値であると生成することができないでしょう。 設備が提供されることができるのと同じくらい小さく、中に、これらは割合SHOULDをケースに入れます。実際のレベルがテストのレポートで説明されるのは結果として生じます。
11.2 Management frames
11.2 管理フレーム
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.
テストのストリームはSHOULDを縁どっています。1つの管理質問に従って、最初のフレームがそれぞれの秒にトライアルの持続時間の間発信したとき、増大してください。 質問の結果は1つのレスポンス・フレームに収まらなければなりません。 応答はSHOULDを縁どっています。テスト設備によって確かめられます。 使用されるべきである特定の質問フレームに関する1つの例がAppendix Cに示されます。
11.3 Routing update frames
11.3 ルート設定アップデートフレーム
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. 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.
ダイナミックルーティングプロトコルアップデートの処理はルータがデータフレームを進める能力で重要な影響を与えるかもしれません。 テストのストリームはSHOULDを縁どっています。1個のルーティングアップデートフレームがトライアルの間に伝えられた最初のフレームとして伝えられている状態で、増大してください。 アップデートフレームSHOULDを発送して、Appendix Cで特定のルーティング・プロトコルに指定されたレートでテストで使用されることで送ってください。 2個のルーティングアップデートフレームがイーサネットの例の上のTCP/IPのためにAppendix Cで定義されます。 ルーティングフレームは、ルーティングをテストデータの推進にかかわらない多くのネットワークに変えるように設計されています。 最初のフレームは1つが状態を「B」に変える秒に「A」に経路指定テーブル状態を設定します。 トライアルの間、フレームを交替しなければなりません。
The test SHOULD verify that the routing update was processed by
the DUT.
テストSHOULDは、ルーティングアップデートがDUTによって処理されたことを確かめます。
11.4 Filters
11.4 フィルタ
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つの領域と別のものの間に受け入れられるデータでセキュリティがコントロールであると実装するためにこれをします。 異なった製品には、フィルタを実装する異なる機能があります。
Bradner & McQuaid Informational [Page 8] RFC 1944 Benchmarking Methodology May 1996
[8ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
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 SHOULD、最初に、構成されて、1つのフィルタ状態とテストが働いたと言い足してください。 このフィルタSHOULDはテストデータストリームの推進を可能にします。 ルータでは、このフィルタSHOULDはフォームの以下の通りです。
forward input_protocol_address to output_protocol_address
入力_プロトコル_アドレスを転送して、_プロトコル_アドレスを出力してください。
In bridges the filter SHOULD be of the form:
ブリッジでは、フィルタSHOULDはフォームの以下の通りです。
forward 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 SHOULD、合計25個のフィルタを実装するために再構成されたその時はそうです。 24これらのフィルタの最初のSHOULDはフォームの以下の通りです。
block input_protocol_address to 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.
プロトコルがいずれがそれでなかったならSHOULDを扱う24の入出力がテストデータストリームで表されます。 最後のフィルタSHOULDはテストデータストリームの推進を可能にします。 2番目の場合でそれを確実にする私たちが、意図する「1番目」と「最終」で、データフレームがフレームの推進を可能にする状態に合う前に25の状態をチェックしなければなりません。 または、もちろん、DUT追加注文であるならフィルタ、フィルタが入力される系列の効果が適切に失われているというフィルタ規則の線形走査を使用しません。
The exact filters configuration command lines used SHOULD be
included with the report of the results.
含まれていて、構成コマンドが裏打ちする正確なフィルタは結果のレポートと共にSHOULDを使用しました。
11.4.1 Filter Addresses
11.4.1 フィルタアドレス
Two sets of filter addresses are required, one for the single
filter case and one for the 25 filter case.
2セットのフィルタアドレスが必要であり、ただ一つのフィルタ・ケースのためのものと25のための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.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.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
Bradner & McQuaid Informational [Page 9] RFC 1944 Benchmarking Methodology May 1996
[9ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
...
deny aa.ba.24.24 to aa.ba.124.24
deny all else
… aa.ba.24aa.ba.124.24対.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.
この系列が入れられる前に前のすべてのフィルタ状態がルータからクリアされるべきです。 系列は、ルータがフィルタ状態を分類するかどうか確認するためにテストするのが選択されるか、または入られた状態でオーダーにおけるそれらがあったそれらを受け入れます。 これらの手順の両方が性能のときに何らかのフォームのハッシュコード化をもたらすよりすばらしい影響をもたらすでしょう。
12. Protocol addresses
12. プロトコルアドレス
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つの送付先プロトコルアドレス、および上で説明されたフィルタのようないくつかの状態にデータのただ一つの論理的なストリームを使用することではこれらのテストを実装するのは、より簡単です、実際的な要件。 本当の世界のネットワークはデータのただ一つのストリームに制限されません。 ただ一つのプロトコル(または、ブリッジテストのためのハードウェア)ソースと送付先アドレスで実行された1番目が組であったならスイートSHOULDをテストしてください。 繰り返されて、無作為の送付先アドレスを使用するのはその時、SHOULDをテストします。 テストルータである間、アドレスSHOULDは無作為であり、256の範囲で一様にネットワークを分配しました。無作為でブリッジのために最大限のMAC範囲で一様に分配されています。 IPに使用する特定のアドレスの範囲はAppendix Cに示されます。
13. Route Set Up
13. セットアップされたルート
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に送らなければなりません。 このルーティングアップデートはトライアルに必要であるネットワーク・アドレスのすべてを含まなければなりません。 SHOULDが同じ「次のホップ」に決議するアドレスのすべて。 通常、これはテスト設備の受信側面のアドレスになるでしょう。 使用されるルーティング・プロトコルによって必要とされた間隔を置いて、このルーティングアップデートは繰り返されなければならないでしょう。 アップデートフレームの形式と反復間隔に関する例はAppendix Cで出されます。
14. Bidirectional traffic
14. 双方向のトラフィック
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、テストシリーズSHOULDの双方向の性能をテストするには、各指示から同じデータ信号速度を提供していて走ってください。 データ信号速度の合計はメディアのために理論上の限界を超えるべきではありません。
Bradner & McQuaid Informational [Page 10] RFC 1944 Benchmarking Methodology May 1996
[10ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
15. Single stream path
15. ただ一つの流れの経路
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.
テストSHOULDの完全なスイートは、いかなるただ一つの入力を使用することで関連している修飾語状態と共にも動かされて、DUTでネットワークポートを出力します。 複数の異なった小道がDUTの内部のデザインで例えば、複数になるなら、別々にテストされる小道SHOULDの複数のネットワークポートの、そして、次に、すべて可能なタイプにそれぞれカードを連結してください。
16. Multi-port
16. マルチポート
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構造の向こう側に分配されて、これらのポートSHOULDは均等にそうです。 例えば、DUTがそれのそれぞれには4つのポートがある2枚のインタフェースカードを持っているなら、それぞれのインタフェースカードの上の2つのポートが入力されるように指定されます、そして、2は出力されるように指定されます。 指定されたテストはそれぞれの入力ポートに提供される同じデータ信号速度を使用する走行です。 フレームがそれぞれの出力ポートに向けられるように設定されてください。そうすれば、連続してすべて「出力されている」というSHOULDポートがそうする入力データ・ストリームにおけるアドレスはこの入力からパケットの同等の分配を得ます。 同じ構成は、双方向のマルチの流れのテストを実行するのに使用されるかもしれません。 この場合、ポートのすべてが両方の入出力ポートであると考えられます、そして、各データ・ストリームは他のポートのすべてに記述されたフレームから成らなければなりません。
Consider the following 6 port DUT:
以下の6ポートがDUTであると考えてください:
--------------
---------| in A out X|--------
---------| in B out Y|--------
---------| in C out Z|--------
--------------
-------------- ---------| 出かけているXで|-------- ---------| B出かけているYで|-------- ---------| Cの出かけているZで|-------- --------------
The addressing of the data streams for each of the inputs SHOULD be:
データのアドレシングはそれぞれの入力SHOULDのために流れます。いてください:
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へのパケット、Bを入力するために送られた出ているZの流れへのパケット: 出かけているXへのパケット、出かけているYへのパケット、パケット、出ているZの流れに、出かけているXへのパケットはCを入力するために発信していました、出かけている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
したがって、これらの流れがそれぞれ同じ順序に従うという3つのパケットが同時間の出力X、Yの当時の3つのパケット、DUTが本当の世界で記述された複数のパケットに対処しなければならないとき手順がそれを確実にするZ.Thisの当時の3つのパケットに到着するメモ
Bradner & McQuaid Informational [Page 11] RFC 1944 Benchmarking Methodology May 1996
[11ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
the same output at the same time.
同時間の同じ出力。
17. Multiple protocols
17. 複数のプロトコル
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.
このドキュメントはテストプロトコルのすべての間の示す以外の分配されていて、そのようなテストがその時欲しいならSHOULDを縁どる複雑なプロトコル環境の効果をテストする問題を記述しません。 分配はDUTが使用されるネットワークに関する状態に近似するかもしれません。
18. Multiple frame sizes
18. 複数のフレーム・サイズ
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.
このドキュメントはプロトコルのための記載されたサイズのすべての間のテスト中の示す以外の分配されていて、そのようなテストがその時欲しいならSHOULDを縁どる複雑なフレーム・サイズ環境の効果をテストする問題を記述しません。 分配はDUTが使用されるネットワークに関する状態に近似するかもしれません。 作者は何らかの非常に特定のシミュレートされたネットワークで直接複数のDUTsを比較する以外に、そのようなテストの結果がどのように解釈されるかというどんな考えも持っていません。
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、802.3はDUTに縁どられます; 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テストモデルを広げることによって、複数のDUTsか異機種混在環境に関する妥当なベンチマークは集められるかもしれません。 この拡大では、独身のDUTを相互接続ネットワークDUTsのシステムに取り替えます。 このテスト方法論はさまざまな装置/メディア/サービス/プロトコル組み合わせのベンチマーキングを支持するでしょう。 例えば、LANへのWANへのLANテストのための構成は以下の通りです。
(1) 802.3-> DUT 1 -> X.25 @ 64kbps -> DUT 2 -> 802.3
(1) 802.3>のDUT1->X.25@64kbps->DUT2->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->DUT1->FDDI->DUT2->FDDI->DUT3->802.3
Bradner & McQuaid Informational [Page 12] RFC 1944 Benchmarking Methodology May 1996
[12ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
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では、構成は、DUT2によって示された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.
複数のDUTsがただ一つのシステムとして扱われるので、この方法論への制限があります。 例えば、この方法論はテストされたシステムのための集合ベンチマークをもたらすかもしれません。 しかしながら、そのベンチマークだけが必ずDUTsの間の振舞いにひずみを反映するかもしれないというわけではなくて、潜在は他の装置で(例えば、CSUs/DSUs、スイッチ)を導入しますなど。
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.
比較を許すためにDUTsのテストされたシステムの特徴/構成には適切な共通点があるのを確実にすることによって異系統のベンチマークを比較するとき、さらに、注意は働かなければなりません。
20. Maximum frame rate
20. 最大のフレームレート
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接続SHOULDをテストすると使用されているのが、記載された理論上の最大であるということであるべきである最大のフレームレートはメディアのフレーム・サイズのために評価します。
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接続SHOULDをテストするとき使用されるべきである最大のフレームレート。 WANテストの、より高い速度はいくつかの業者が様々な形式のヘッダー圧縮を使うという事実を補うことです。
A list of maximum frame rates for LAN connections is included in Appendix B.
LAN接続の最大のフレーム速度のリストはAppendix Bに含まれています。
21. Bursty traffic
21. Bursty交通
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の機能を測る非現実的な方法です。 テストのいくつかがともに安定した州の交通で実行されて、フレームの繰り返された炸裂から交通で成る以下のSHOULDについて説明しました。 炸裂の中のフレームは最小の正統のインターフレームギャップで伝えられます。
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年の放出量がある走行がフレームであったならSHOULDをテストします。
Bradner & McQuaid Informational [Page 13] RFC 1944 Benchmarking Methodology May 1996
[13ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
22. Frames per token
22. 1象徴あたりのフレーム
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.
象徴が受け取られているのが、その都度1個以上のフレームを伝えるためにいくつかのトークンリングとFDDIインタフェースを構成するのにおいて可能ですが、現在利用可能なネットワーク装置の大部分は1象徴あたり1個のフレームだけを伝えます。 これらは最初に、SHOULDをテストします。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.
いくつかの現在の高性能ワークステーションサーバが、スループットを最大にするためにFDDIで1象徴あたり1個以上のフレームを伝えます。 これが将来のワークステーションの共通点であるかもしれなく、サーバ、FDDIインタフェースがある内部連絡装置がSHOULDであるので、1、4、8、および16で、1象徴あたりのフレームにテストされてください。 報告されたフレームは合計の上のフレームトランスミッションの平均相場がトライアルの期間であったならSHOULDを評定します。
23. Trial description
23. トライアル記述
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にアドレス解決テーブルを用意するのに使用されます。 使用されるべきである学習フレームの書式はTest Frame Formatsドキュメントに示されます。
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) 少なくとも5秒間、DUTが再安定しているのを待ってください。
24. Trial duration
24. トライアル持続時間
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
これらのテストの目的は絶え間なくDUTが我慢できるレートを測定することです。 テストトライアルの実際の持続時間はベンチマーキングテストスイートのこの目的と持続時間の間の妥協であるに違いありません。 テストの持続時間は少なくとも60が秒であったなら各トライアルSHOULDを分配します。 何らかのフォームの「二分探索」にかかわるテスト、例えばスループットをテストして、正確な結果がしかし、調査方法、最終的決定SHOULDの長さを最小にするのにより短い公判の持続時間を使用するかもしれないことを決定するために、作られてください。
Bradner & McQuaid Informational [Page 14] RFC 1944 Benchmarking Methodology May 1996
[14ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
full length trials.
完全な長さのトライアル。
25. Address resolution
25. アドレス解決
The DUT SHOULD be able to respond to address resolution requests sent by the DUT wherever the protocol requires such a process.
DUT SHOULD、プロトコルがどこでそのような過程を必要としても応じることができて、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の構成への交通フィルタの添加でフレームの流れへの上の変更について言及します。
26.1 Throughput
26.1 スループット
Objective:
To determine the DUT throughput as defined in RFC 1242.
目的: RFC1242で定義されるように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 rate of the offered stream is raised and the test
rerun. If 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.
報告形式: スループットの結果は報告されたコネがグラフのフォームであったならSHOULDをテストします。 xはそれがそうなら、SHOULDを調整します。フレーム・サイズ、yがフレームがレートであったならSHOULDを調整するということになってください。 SHOULDは少なくともそこでは、そうです。グラフの2つの線。 そこ、SHOULD、様々なフレーム・サイズにメディアの理論上のフレームレートを示している1つの線になってください。 2番目はテストの陰謀が結果であったならSHOULDを裏打ちします。 追加線は、それぞれのタイプのデータ・ストリームのための結果がテストされたと報告するのにグラフで使用されるかもしれません。 SHOULDが、プロトコル、データ・ストリーム形式、およびメディアのタイプがテストで使用したのを示すグラフに伴うテキスト。
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
私たちは、ただ一つの値が広告の目的で望まれていると業者がメディアのために最小のフレーム・サイズのレートを選択すると思います。 これが完了しているなら、1秒あたりのフレームに図を表さなければなりません。 また、業者がそう望んでいるなら、1秒あたりのビット(または、バイト)でレートは表されるかもしれません。 The
Bradner & McQuaid Informational [Page 15] RFC 1944 Benchmarking Methodology May 1996
[15ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
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.
性能の声明は測定最大のフレームレート、フレームのサイズが使用したb/、理論上が制限するそのフレーム・サイズのためのメディアのc/、およびプロトコルのタイプのd/がテストで使用した/を含まなければなりません。 ただ一つの値は広告コピーの一部として使用されます、結果SHOULDの完全なテーブル。製品データシートでは、含まれています。
26.2 Latency
26.2 潜在
Objective:
To determine the latency as defined in RFC 1242.
目的: RFC1242で定義されるように潜在を決定するために。
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を通して特定のフレーム・サイズで決定している押出量でフレームの流れを特定の目的地に送ってください。 流れのSHOULDは少なくともそうです。持続時間における120秒。 含まれていて、特定はタグのタイプが実現に依存している60秒以降1個のフレームでSHOULDにタグ付けをします。 このフレームが完全に伝えられる時は記録されています(タイムスタンプ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 RFC1242、すなわち、店と定義される潜在に従ってタイムスタンプAを引いたタイムスタンプBと前進の装置か潜在です。
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.
テストフレームがデータ・ストリームの残りと同じ目的地に記述されている状態で実行されて、それぞれのテストフレームでも新しい送信先ネットワークに記述されて、これはSHOULDをテストします。
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.
報告形式: レポートは、潜在(RFC1242からの)のどの定義がこのテストに使用されたかを述べなければなりません。 潜在結果SHOULD、列があるテーブルの形式では、それぞれのテストされたフレーム・サイズには、報告されてください。 そこ、SHOULD、フレーム・サイズのためのコラムになってください、潜在テストがそのフレーム・サイズのための走行であったレート、タイプがテストして、それぞれのタイプに関するデータのための結果の潜在値流すメディアがテストされたので。
Bradner & McQuaid Informational [Page 16] RFC 1944 Benchmarking Methodology May 1996
[16ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
26.3 Frame loss rate
26.3 フレーム損失率
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.
目的: フレームの損失を決定するために、評価してください、全体の範囲の入力データレートとフレーム・サイズ中でDUTについてRFC1242で定義されるように。
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
(入力_カウント--出力_カウント)*100)/入力_カウント
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.
第一審SHOULD、入力メディアのフレーム・サイズのための最高率の100%に対応するフレームレートのための走行になってください。 使用されてそして、このレートの80%のための最高率の90%に対応するレートのために手順を繰り返してください。 フレームがないのが無くなる2つの連続したトライアルがあるまで続けられていて(10%の間隔を短縮するところの)、これはSHOULDを配列します。 トライアルの最大の粒状が最高率の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.
報告形式: フレーム損失率の結果はSHOULDをテストします。グラフとして、企まれます。 これが完了しているなら、X軸は特定のフレーム・サイズにおけるメディアの理論上のレートのパーセントとして入力フレーム率であるに違いありません。 Y軸は特定の入力率でパーセントの損失であるに違いありません。 X軸の左の端とY軸の下部は割でなければなりません。 X軸の正しい端とY軸の先端は100パーセントでなければなりません。 グラフの複数の線が以前はよく異なったフレーム・サイズ、プロトコル、およびタイプのデータ・ストリームのフレーム損失率を報告していたかもしれません。
Note: See section 18 for the maximum frame rates that SHOULD be
used.
以下に注意してください。 最大のフレームへのセクション18が、SHOULDが使用されるように評価するのを確実にしてください。
26.4 Back-to-back frames
26.4 背中合わせのフレーム
Objective:
To characterize the ability of a DUT to process back-to-back
frames as defined in RFC 1242.
目的: DUTがRFC1242で定義されるように背中合わせのフレームを処理する能力を特徴付けるために。
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
手順: 最小のインターフレームギャップがあるフレームの炸裂をDUTに送ってください、そして、DUTによって進められたフレームの数を数えてください。 伝えられたフレームのカウントが進められたフレームの数と等しいなら、炸裂の長さは増加されています、そして、テストは再放送されます。 if
Bradner & McQuaid Informational [Page 17] RFC 1944 Benchmarking Methodology May 1996
[17ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
the number of forwarded frames is less than the number
transmitted, the length of the burst is reduced and the test is
rerun.
進められたフレームの数は数が伝わったより少ないです、そして、炸裂の長さは減少します、そして、テストは再放送されます。
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がどんなフレームの損失なしでも扱う中で最も長い炸裂で、フレームの数です。 記録された値の平均が報告されている状態で少なくとも50回繰り返されて、トライアルの長さは、少なくとも2秒とSHOULDであるに違いありません。
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.
報告形式: 背中合わせの結果SHOULD、列があるテーブルの形式では、それぞれのテストされたフレーム・サイズには、報告されてください。 そこでは、SHOULDはフレーム・サイズのためのコラムであり、それぞれのタイプのデータ・ストリームのための結果の平均したフレームカウントがないかどうかテストしました。 また、各測定のための標準偏差は報告されるかもしれません。
26.5 System recovery
26.5 システムの復旧
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秒間。 Timestamp Aでは、フレームレートを最後のフレームの時間が失った上のレートと記録(タイムスタンプB)の50%まで低下させてください。 システム回復時間は報告される幾度か繰り返されて、Timestamp A.テストSHOULDからTimestamp 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.
報告形式: システムの復旧結果SHOULD、列があるテーブルの形式では、それぞれのテストされたフレーム・サイズには、報告されてください。 そこでは、SHOULDはフレーム・サイズ、それぞれのタイプのデータ・ストリームのための押出量がテストされたので使用されるフレームレートのためのコラムであり、それぞれのタイプのデータ・ストリームのための測定回復時間の間、テストしました。
26.6 Reset
26.6 リセット
Objective:
To characterize the speed at which a DUT recovers from a device or
software reset.
目的: DUTが装置かソフトウェアリセットから回復する速度を特徴付けるために。
Bradner & McQuaid Informational [Page 18] RFC 1944 Benchmarking Methodology May 1996
[18ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
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)が受け取られていることの時に進められて、記録し始めるまで、出力をモニターしてください。 リセットを引き起こすことに代わって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に接続されていたなら、これは、ルーティングアップデートが受け取られているまで延着するという要件が全くないように、SHOULDだけをテストします。
The reset value is obtained by subtracting Timestamp A from
Timestamp B.
Timestamp BからTimestamp Aを引き算することによって、リセット値を得ます。
Hardware and software resets, as well as a power interruption
SHOULD be tested.
ハードウェアとソフトウェアは停電と同様にSHOULDをリセットします。テストされます。
Reporting format:
The reset value SHOULD be reported in a simple set of statements,
one for each reset type.
報告形式: リセット価値のSHOULDが簡単な声明で報告されて、それぞれのための1つはタイプをリセットしました。
27. Security Considerations
27. セキュリティ問題
Security issues are not addressed in this document.
安全保障問題は本書では記述されません。
Bradner & McQuaid Informational [Page 19] RFC 1944 Benchmarking Methodology May 1996
[19ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
28. Editors' Addresses
28. エディタのアドレス
Scott Bradner Harvard University 1350 Mass. Ave, room 813 Cambridge, MA 02138
スコットブラドナーハーバード大学1350マサチューセッツ州 Ave、部屋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メールに電話をしてください: sob@harvard.edu
Jim McQuaid Bay Networks 3 Federal Street Billerica, MA 01821
ビルリカ、ジムMcQuaidベイネットワークス3の連邦政府の通りMA 01821
Phone +1 508 436-3915 Fax: +1 508 670-8145 EMail: jmcquaid@baynetworks.com
+1 508 436-3915Fax:に電話をしてください。 +1 508 670-8145 メールしてください: jmcquaid@baynetworks.com
Bradner & McQuaid Informational [Page 20] RFC 1944 Benchmarking Methodology May 1996
[20ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
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. 典型的なテスト習慣は、すべてのプロトコルがプロトコルについてさらなる構成なしでテストされて、すべてのテストを行うのを可能にすることになっていました、与えられたセットのトライアルは一度に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つの異なった性能結果を与えるなら、混ぜられたプロトコルテストは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)性能は、WANモデムの適切な短い貨物量バージョンによって接続された2台の同じ装置をセットアップすることによって、テストされるかもしれません。次に、パフォーマンスはもう片方のDUTで1DUTでLANインタフェースの間で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%であるべきであると示唆します。 テスト圧縮自体の重要な問題はこのドキュメントの範囲を超えています。
Bradner & McQuaid Informational [Page 21] RFC 1944 Benchmarking Methodology May 1996
[21ページ]RFC1944ベンチマーキング方法論1996年5月の情報のブラドナーとMcQuaid
Appendix B: Maximum frame rates reference
付録B: 最大のフレームは参照を評定します。
(Provided by Roger Beeman, Cisco Systems)
(ロジャー・ビーマン、シスコシステムズによって提供されます)
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
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
NビットのイーサネットサイズPreamble64ビットFrame8x Gap96ビット
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 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
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 size Preamble 64 bits SD 8 bits FC 8 bits DA 48 bits SA 48 bits SNAP
Bradner & McQuaid Informational [Page 22] RFC 1944 Benchmarking Methodology May 1996
Bradner & McQuaid Informational [Page 22] RFC 1944 Benchmarking Methodology May 1996
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 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
Appendix C: Test Frame Formats
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.
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.
C.1. Introduction
C.1. Introduction
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.
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.
C.2. TCP/IP Information
C.2. TCP/IP Information
The following section deals with the TCP/IP protocol suite.
The following section deals with the TCP/IP protocol suite.
C.2.1 Frame Type.
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.
C.2.1 Frame Type. 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.
For TCP/IP a UDP Echo Request is used.
C.2.2 Protocol Addresses
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.
C.2.2 Protocol Addresses 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.
The network addresses 192.18.0.0 through 192.19.255.255 are have
been assigned to the BMWG by the IANA for this purpose. This
The network addresses 192.18.0.0 through 192.19.255.255 are have been assigned to the BMWG by the IANA for this purpose. This
Bradner & McQuaid Informational [Page 23] RFC 1944 Benchmarking Methodology May 1996
Bradner & McQuaid Informational [Page 23] RFC 1944 Benchmarking Methodology May 1996
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.
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.
C.2.2.1 Router port protocol addresses
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.
C.2.2.1 Router port protocol addresses 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.
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).
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).
C.2.2.2 Frame addresses
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)
C.2.2.2 Frame addresses 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)
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.
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.2.3 Routing Update Frequency
C.2.3 Routing Update Frequency
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.
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.
Bradner & McQuaid Informational [Page 24] RFC 1944 Benchmarking Methodology May 1996
Bradner & McQuaid Informational [Page 24] RFC 1944 Benchmarking Methodology May 1996
IP-RIP 30 sec
IGRP 90 sec
OSPF 90 sec
IP-RIP 30 sec IGRP 90 sec OSPF 90 sec
C.2.4 Frame Formats - detailed discussion
C.2.4 Frame Formats - detailed discussion
C.2.4.1 Learning Frame
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.
C.2.4.1 Learning Frame 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.
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.
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.
+--------+ +------------+
| | | phantom |------ P LAN
A
IN A------| DUT |------------| |------ P LAN
B
| | OUT A | router |------ P LAN
C
+--------+ +------------+
+--------+ +------------+ | | | phantom |------ P LAN A IN A------| DUT |------------| |------ P LAN B | | OUT A | router |------ P LAN C +--------+ +------------+
Figure 2
Figure 2
In the case where full routing is being used
In the case where full routing is being used
C.2.4.2 Routing Update Frame
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
C.2.4.2 Routing Update Frame 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
Bradner & McQuaid Informational [Page 25] RFC 1944 Benchmarking Methodology May 1996
Bradner & McQuaid Informational [Page 25] RFC 1944 Benchmarking Methodology May 1996
"input" port consists of a repeating sequence of frames, one to
each of the "output" ports.
"input" port consists of a repeating sequence of frames, one to each of the "output" ports.
C.2.4.3 Management Query Frame
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:
C.2.4.3 Management Query Frame 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:
sysUpTime
ifInOctets
ifOutOctets
ifInUcastPkts
ifOutUcastPkts
sysUpTime ifInOctets ifOutOctets ifInUcastPkts ifOutUcastPkts
C.2.4.4 Test Frames
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.
C.2.4.4 Test Frames 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.
C.2.4.5 Frame Formats - TCP/IP on Ethernet
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.
C.2.4.5 Frame Formats - TCP/IP on Ethernet 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.
C.2.6.1 Learning Frame
C.2.6.1 Learning Frame
ARP Request on Ethernet
ARP Request on Ethernet
-- 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
-- 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
Bradner & McQuaid Informational [Page 26] RFC 1944 Benchmarking Methodology May 1996
Bradner & McQuaid Informational [Page 26] RFC 1944 Benchmarking Methodology May 1996
32 FF FF FF FF FF FF requesting DUT's MAC address
38 xx xx xx xx DUT's IP address
32 FF FF FF FF FF FF requesting DUT's MAC address 38 xx xx xx xx DUT's IP address
C.2.6.2 Routing Update Frame
C.2.6.2 Routing Update Frame
-- 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
-- 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 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
-- 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
-- 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 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
-- net 2
Bradner & McQuaid Informational [Page 27] RFC 1944 Benchmarking Methodology May 1996
Bradner & McQuaid Informational [Page 27] RFC 1944 Benchmarking Methodology May 1996
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
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 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 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 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
-- 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
C.2.4.6 Management Query Frame
C.2.4.6 Management Query Frame
To be defined.
To be defined.
Bradner & McQuaid Informational [Page 28] RFC 1944 Benchmarking Methodology May 1996
Bradner & McQuaid Informational [Page 28] RFC 1944 Benchmarking Methodology May 1996
C.2.6.4 Test Frames
UDP echo request on Ethernet
C.2.6.4 Test Frames UDP echo request on Ethernet
-- 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
-- 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 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 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
-- 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 length frames
** - change for different logical streams
** - change for different logical streams
*** - fill remainder of frame with incrementing octets,
repeated if required by frame length
*** - fill remainder of frame with incrementing octets, repeated if required by frame length
Bradner & McQuaid Informational [Page 29] RFC 1944 Benchmarking Methodology May 1996
Bradner & McQuaid Informational [Page 29] RFC 1944 Benchmarking Methodology May 1996
Values to be used in Total Length and UDP message length fields:
Values to be used in Total Length and UDP message length fields:
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
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
Bradner & McQuaid Informational [Page 30]
Bradner & McQuaid Informational [Page 30]
一覧
スポンサーリンク
