この文書はRFC2544の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


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.

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アドレスの割り当てられた値を修正するRFC1944の
   再発行です。(C.2.2章参照)。このRFCはRFC1944を置換え、
   時代遅れにします。

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はあるテス
   トに使われるフレームフォーマットの例を与えます。

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.
   ベンダーがしばしば彼らのプロダクトの市場におけるもっと良いポジション
   を与える試みで「スペックマンシップ」に従事します。これはプロダクトの
   潜在的ユーザーを混乱させるためにしばしば「煙&鏡」を伴います。

   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.
   前の文書、「ネットワーク相互接続装置のためのベンチマーク用語」(RF
   C1242)、がこの文書で使われる用語の多くを定義しました。専門用語
   文書はこの文書を利用しようと試みる前に調べられるべきです。

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.

   訳注:RFC誤植情報によると上記の"nder"は"under"が正しいそうです。

   この文書に記述された多くのテストがあります。全てのテストが全てのテス
   ト対象装置(DUT)に適用されるのではありません。ベンダがそのプロダ
   クトでサポートできるテストのすべてを行うべきです。著者は推薦された全
   ての状態で推薦されたテストのすべてを実行するとかなりの期間をとるであ
   ろうことを理解します。我々は努力に値すると信じます。付録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をサポートしない(しなくてよい)環境で、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"この単語あるいは"REQUIRED"と"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"この単語あるいは"RECOMMENDED"は特定の状況でこの項目を無
         視する正当な理由が存在するかもしれないことを意味しますが、完全
         な意味を理解するべきで、他の方法を選択する前に強く慎重にすべき
         です。

       * "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項目を1つ以上満たさなければ、準拠では
   ありません。実装がプロトコル実装のすべてのMUSTとSHOULD項目を満たすな
   ら、そのプロトコルの「無条件準拠」と言います;全てのMUST項目を満たす
   が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.

   訳注:RFC誤植情報によると上記の"forwarded but the DUT"は
   "forwarded by the DUT"が正しいそうです。

   この一連のテストを実行する理想的な方法は、送信ポートと受信ポートの両
   方にテスターを使うことです。接続がテスターの送信ポートからDUTの受
   信ポートに、DUTの送信ポートからテスターの受信ポートに作られます。
   (図1参照)テスターがテストトラフィックの送信と受信の両方をするので、
   トラフィックがDUTにより転送された後、テスターは容易に伝達されたパ
   ケットのすべてを受信したか決定でき、正しいパケットが受信できたか確認
   できます。同じ機能は別々の送信装置と受信装置でもできますが(図2参照)、
   それらが1つのテスターをシミュレートする方法であるコンピュータによっ
   て遠隔制御されていないなら、あるテスト(特にスループットテスト)を正
   確に実行するのは不可能です。

                            +------------+
                            |            |
               +------------|  tester    |<-------------+
               |            |            |              |
               |            +------------+              |
               |                                        |
               |            +------------+              |
               |            |            |              |
               +----------->|    DUT     |--------------+
                            |            |
                            +------------+
                              Figure 1
                                図1

         +--------+         +------------+          +----------+
         |        |         |            |          |          |
         | sender |-------->|    DUT     |--------->| receiver |
         |        |         |            |          |          |
         +--------+         +------------+          +----------+
                              Figure 2
                                図2

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.
   実世界で異なったメディアタイプのネットワーク接続に使っているDUT、
   例えばバックボーンFDDIリングとローカルイーサネット、をテストする
   ために、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つの同一のDUTが使われます。(図3参照)多くの場
   合、この設定はより正確に実世界を真似ます。例えば、WANリンクや高速
   バックボーンを通して2つのLANを結びます。この設定はイーサーネット
   LAN上のクライアントとFDDIバックボーン上のサーバの接続の擬似設
   定にはうまくないでしょう。

                               +-----------+
                               |           |
         +---------------------|  tester   |<---------------------+
         |                     |           |                      |
         |                     +-----------+                      |
         |                                                        |
         |        +----------+               +----------+         |
         |        |          |               |          |         |
         +------->|  DUT 1   |-------------->|   DUT 2  |---------+
                  |          |               |          |
                  +----------+               +----------+

                                  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はユーザーに供給された指示
   に従って構成を設定されなくてはなりません(MUST)。特に、サポートするプ
   ロトコルのすべての構成を設定し利用可能にすることが期待されます(付録
   A参照)。実施中のテストで要求されている事以外は、すべてのテストでD
   UT設定が同じである事が期待されます。例えば、フレーム処理率のテスト
   の間にフレーム処理バッファの大きさを変えることや、プロトコル処理能力
   をテストする時に1つの転送プロトコル以外のすべてを止める事は適切であ
   りません。スループットに対するフィルター効果を決定するテストを始める
   時に設定を修正することは必要ですが、唯一の変更は特定のフィルターを利
   用可能にすることに違いありません(MUST)。DUT設定は、通常の推薦され
   たルーティング更新間隔と生存確認頻度を含むべきです(SHOULD)。ソフトウェ
   アのバージョンと、テストの間にどの機能を止めていたかを含む厳密なDU
   T設定は結果の報告の一部として含まなければなりません(MUST)。

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で使うべきテストフレームのフォーマットは
   付録Cを参照してください:テストフレームフォーマット。この文書で記述
   されたプロトコル/メディアの組合せのテストでこれらの厳密なフレーム
   フォーマットは使われるべきで、そしてこれらのフレームが他のプロトコル
   /メディアの組合せをテストする際のテンプレートとして用いられるべきで
   す(SHOULD)。特定のテストのテストフレームを定義するために使われる特定
   のフォーマットは結果の報告に含められなくてはなりません(MUST)。

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)。特に、試験プロトコルと試験で使うメディアで許される最大サイ
   ズと最小サイズと、DUT能力の完全な特徴を得ることが可能な十分な大き
   さのサイズを含むべきです(SHOULD)。注記した以外、少なくとも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エコーリクエストフレームは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のフレーム毎の処理オーバー
   ヘッドを特徴づけるのに役立つはずです。

9.1 Frame sizes to be used on Ethernet
9.1 イーサーネットに使うフレームサイズ

       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.
   これらのサイズはイーサネット標準によって認められた最大・最小フレーム
   サイズと、これらの両極端の間で小さいフレームサイズとより高いフレーム
   レートの粒度でのサイズ選択を含みます。

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

   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フィールドはダイレクト
   ソースルートブリッジ性能試験で存在するでしょう。トークンリング上のU
   DPの最小フレームサイズは54オクテットです。多くのトークンリングイ
   ンタフェースによって課されたサイズ限界のために、17.9Kbの理論的な
   最大サイズの代わりに、4472オクテットの最大サイズが16Mbトーク
   ンリングで推薦されます。残りのサイズは他のタイプのメディアと直接比較
   を認めるよう選ばれます。(UDPではなく)IPフレームが追加で使われ
   る、もしより高いデータレートを望むなら、この場合最小フレームサイズは
   46オクテットです。

9.3 Frame sizes to be used on FDDI
9.3 FDDIで使うのフレームサイズ

       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の最大サイズが推薦されています。もしより高いデータレー
   トを望むなら、(UDPではなく)IPフレームが追加で使われるかもしれ
   ず、その場合の最小フレームサイズは45オクテットです。

9.4 Frame sizes in the presence of disparate MTUs
9.4 異なるMTUでのフレームサイズ

   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リンクをつなぐとき、*より大きい*MT
   Uのリンクのフレームサイズがを使い、プロトコル限界がテストされるべ
   きです(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.
   例えば、FDDIとイーサネットをつなぐブリッジやルーターのIP転送テ
   ストで、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
   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)。例えば、生存確認やルーティン
   グ更新フレームを受信フレームのカウントに含めるべきではありません
   (SHOULD NOT)。どんな場合ででも、テスト装置は受信フレーム長を確かめて、
   そしてそれらが予想される長さに合うことを調べるべきです(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つとして通常のテストフレーム流の中
   に含め、そして別のネットワークポート上の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.
   たいていのルータのデザインで特別な処理が、ハードウェアブロードキャス
   トアドレス宛のフレームを受信した時、必要とされます。ブリッジ(あるい
   はブリッジモードのルータ)で、これらのブロードキャストフレームは多く
   のポートに流されなくてはなりません。テストフレーム流に1%のハードウェ
   アブロードキャストアドレスフレームを追加するべきです(SHOULD)。ブロー
   ドキャストアドレスに送られたフレームはルーターが処理する必要がないタ
   イプであるべきです。このテストの目的は流れの他のデータの転送率に影響
   があるかどうかの決定です。使われる特定フレームはテストフレームフォー
   マット文書に含められます。ブロードキャストフレームはデータ流全体に均
   等に配置されるべきです(SHOULD)、例えば、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で行われるべきですが、この場合ブロー
   ドキャストパケットは処理され、すべての出力に流されるでしょう(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
   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%のブロードキャストフレームのレベルは多くのネットワークの実体より
   ずっと高いが、薬の毒性評価のように、システム能力の標準範囲内で生じる
   効果を測定することが可能なため、より高いレベルが要求されると理解され
   ます。設計要素のためにあるテスト装置が他のフレームの生成できるレベル
   が低いです。これらの場合パーセンテージは装置が供給できる程度の小ささ
   であるべきで(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つの回答フレームに入らなければなりません。
   回答フレームはテスト装置によって検証されるべきです(SHOULD)。使われる
   べき質問フレームの1つの例が付録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.
   ダイナミックルーティングプロトコル更新の処理はルーターのデータフレー
   ムを転送する能力に重要な影響を持つことがあります。試験の間の最初のフ
   レームに1つのルーティング更新を含めるべきです(SHOULD)。

   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で指定さ
   れるレートでルーティング更新フレームが送られるべきです(SHOULD)。イー
   サネット上のTCP/IPの例として2つのルーティング更新フレームが付
   録Cで定義されます。ルーティングフレームはテストデータの転送に関係し
   ていない多くのネットワークの経路を変えるよう意図されます。最初のフレー
   ムはルーティングテーブル状態を「A」に設定し、2番目が状態を「B」に
   変えます。フレームは試験の間、交互に送られます(MUST)。

   The test SHOULD verify that the routing update was processed by the
   DUT.
   テストはルーティング更新がDUTによって処理されたことを確かめるべき
   です(SHOULD)。

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.
   フィルターが通常、選択的にフレーム転送を抑制するために、ルーターとブ
   リッジに加えられます。これはあるエリアと他のエリア間で受け入れられる
   データのセキュリティ制御を実行するために通常されます。異なった製品が
   フィルターを実行する異なった能力を持っています。

   The DUT SHOULD be first configured to add one filter condition and
   the tests performed.  This filter SHOULD permit the forwarding of the
   test data stream. In routers this filter SHOULD be of the form:
   DUTは最初1つのフィルターを加えて設定されるべきで(SHOULD)、テスト
   処理が行われます。このフィルターはテストデータフローの転送を認めるべ
   きです(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は合計25のフィルターを実行する様に再設定すべきです(SHOULD)。
   最初の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.
   24の入力と出力プロトコルアドレスはテストデータ流ででてくるものでな
   いべきです(SHOULD not)。最後のフィルターはテストデータ流の転送を認め
   るべきです(SHOULD)。2番目のケースで、「最初」と「最後」によって、デー
   タフレームがフレームの転送を認める条件と一致する前に、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つのセットが必要です、1つは単体のフィルターの
   場合で、もうひとつは25のフィルターの場合です。

   The single filter case should permit traffic from IP address
   198.18.1.2 to IP address 198.19.65.2 and deny all other traffic.
   単体のフィルターの場合、IPアドレス198.18.1.2からIPアドレス
   198.19.65.2のトラフィックを認め、すべての他のトラフィックを否
   定するべきです。

   The 25 filter case should follow the following sequence.
   25のフィルターの場合は以下の通りにすべきです。

         deny aa.ba.1.1 to aa.ba.100.1
         deny aa.ba.2.2 to aa.ba.101.2
         deny aa.ba.3.3 to aa.ba.103.3
           ...
         deny aa.ba.12.12 to aa.ba.112.12
         allow aa.bc.1.2 to aa.bc.65.1
         deny aa.ba.13.13 to aa.ba.113.13
         deny aa.ba.14.14 to aa.ba.114.14
           ...
         deny aa.ba.24.24 to aa.ba.124.24
         deny all else

   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)。ルーター
   テストの間アドレスは256ネットワークの範囲で一様ランダムに分布すべ
   きで、ブリッジの場合、一様ランダムな範囲のMACアドレスに分布すべき
   です(SHOULD)。IPで使うべき特定のアドレス範囲は付録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に送られなくてはな
   りません(MUST)。このルーティング更新はテストに必要とされるであろうネッ
   トワークアドレスのすべてを含まなくてはなりません(MUST)。アドレスのす
   べてが同じ「次の転送先」に決定するべきです(SHOULD)。通常これはテスト
   装置の受信側アドレスであるでしょう。このルーティング更新はルーティン
   グプロトコルで使われることを要求された間隔で繰り返されなければならな
   いでしょう。フォーマットと更新フレームの繰り返し間隔の例が付録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)。データレートの合計はメディアの理論的な
   限界を超えるべきではありません。

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.
   テストの完全セットは、DUTのひとつの入力と出力ネットワークポートを
   使うのに関連する、修飾条件で行うべきです(SHOULD)。もし、例えば、DU
   Tの内部のデザインが多数の別個のパスを持っていて、多数のインタフェー
   スカードがそれぞれ多数のネットワークポートを持つなら、すべての可能タ
   イプのパスは個別にテストされるべきです(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.
   多くの現在のルーターとブリッジ製品が同じモジュールで多くのネットワー
   クポートを供給します。最初にこれらのテストを行う際に、ポートの2分の
   1が「入力ポート」と指名され、半分が「出力ポート」と指名されます。こ
   れらのポートはDUTアーキテクチャを通して平等に配置するべきです
   (SHOULD)。例えばもしDUTが各4ポートを持つ2枚のインタフェースカー
   ドを持っているなら、各インタフェースカード上の2つのポートが入力と指
   定され、2つが出力と指名されます。指定されたテストは入力ポートのそれ
   ぞれに提供されて同じデータレートを使って運営されます。入力データ流で
   のアドレスは、すべての「出力」ポートがこの入力からのパケットを均等に
   得るように、フレームが均等に各出力ポートに向けられるように、設定され
   るべきです(SHOULD)。同じ設定は双方向性の流れのテストを実行するために
   使われるかもしれません(MAY)。この場合ポートのすべてが入力と出力ポート
   の両方であると思われ、そして各データ流が他のポートすべてに宛てられて
   フレームから成り立たなくてはなりません(MUST)。

   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:
   入力の各データストリームのアドレス以下であるべきです(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

   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に同時に到着し、そして3パケットがYに、そして3パケットが
   Zです。この手順は、実世界のように、DUTが同時に同じ出力宛の多数の
   パケットを扱わなければならないことを保証します。

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が使われるであろ
   うネットワーク上の状態に近付けるかもしれません(MAY)。

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が使われるであろうネットワークの状態に近付けるか
   もしれません(MAY)。ある非常に特定のシミュレートされたネットワークで多
   数のDUTを直接比較する以外、著者はこのようなテストの結果を翻訳する
   考えを持っていません。

19. Testing performance beyond a single DUT.
19. 1つの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.
   1つの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フレーム
   入力;分割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−W
   AN−LANテストの設定が以下かもしれません:

   (1) 802.3-> DUT 1 -> X.25 @ 64kbps -> DUT 2 -> 802.3

   Or a mixed LAN configuration might be:
   あるいは混在LAN設定が以下かもしれません:

   (2) 802.3 -> DUT 1 -> FDDI -> DUT 2 -> FDDI -> DUT 3 -> 802.3

   In both examples 1 and 2, end-to-end benchmarks of each system could
   be empirically ascertained. Other behavior may be characterized
   through the use of intermediate devices. In example 2, the
   configuration may be used to give an indication of the FDDI to FDDI
   capability exhibited by DUT 2.
   例1と例2の両方で、各システムのエンドエンドベンチマークが経験的に確
   かめることができました。他の行動が中間装置の使用を通して記述されるか
   もしれません。例2で、設定はDUT2によって示されるFDDI−FDD
   I能力の指標を与えるために使われるかもしれません。

   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間の動
   作で必ずしも不均整を反映しないかもしれません、他の装置(例えば、CS
   U/CSUやスイッチ)による遅延が、など。

   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機
   能/設定が適切な共通因子持っている事をを確かにするさらなる注意が必要
   です。

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接続をテストする時、使われるべきである最大のフレームレートはそ
   のスピードの接続のフレームサイズのためにリストアップされた理論的最大
   レートより大きいべきです(AHOULD)。WANテストのためのより高いレート
   はあるベンダーがヘッダー圧縮の種々な形式を使用するという事実を埋め合
   わせるはずです。

   A list of maximum frame rates for LAN connections is included in
   Appendix B.
   LAN接続のための最大のフレームレートのリストが付録Bに含められます。

21. Bursty traffic
21. バーストトラヒック

   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能力を測ることは便利ですが、しかしこれは実際
   のネットワークトラフィックが通常フレームバーストから成り立つので、D
   UT能力を測定する非現実的な方法です。下に記述されたテストのいくつか
   が、一様状態トラフィックとバーストトラフィックの両方から成り立つ状態
   で、行われるべきです(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)。

22. Frames per token
22. トークン毎のフレーム数

   Although it is possible to configure some token ring and FDDI
   interfaces to transmit more than one frame each time that the token
   is received, most of the network devices currently available transmit
   only one frame per token.  These tests SHOULD first be performed
   while transmitting only one frame per token.
   あるトークンリングとFDDIインタフェースでトークン受信時に1つ以上
   のフレームを送信するように設定することが可能であるが、現在利用可能な
   ネットワーク装置の大部分がトークン毎にただ1つのフレームを伝達します。
   これらのテストは最初は、トークン毎にただ1つのフレームを伝達するよう
   に行われるべきです(SHOULD)。

   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つ以上のフレームを伝達します。これが将
   来のワークステーションとサーバーで共通の特徴であるかもしれないので、
   FDDIインタフェースを持っている相互接続装置がトークン毎に1と4と
   8と16のフレームでテストされるべきです(SHOULD)。報告するフレーム率
   は全試験時期のフレーム伝達の平均率であるべきです(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のアドレス解決テーブルの用意をするために使わ
   れます。使われるべき学習フレームのフォーマットはテストフレームフォー
   マット文書で見せられます。

   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秒待ってください。

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
   full length trials.
   これらのテストの目的はDUTが連続的にサポートできるレートを決定する
   ことです。テストトライアルの実際の持続時間はこの目的とベンチマークテ
   ストの持続時間の間の折衷に違いありません。各トライアルのテスト部の持
   続時間は少なくとも60秒であるべきです(SHOULD)。正確な結果を決定する
   ための「バイナリ探索」が必要なテスト、例えばスループットテストは、検
   索処理を最小にするために短いトライアルを使うかもしれません(MAY)が、
   最終決定は標準の長さのトライアルで行われるべきです(SHOULS)。

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は、プロトコルがこのようなプロセスを必要とする時点で、DUTが
   送ったアドレス解決要求に対して、応答を得られるべきです(SHOULD)。

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 fewer frames are received than were transmitted, the rate
   of the offered stream is reduced and the test is rerun.
   手順:DUTを通して特定の数のフレームを特定のレートで送って、次にD
   UTによって伝達されたフレームを数えます。もし供給されたフレーム数が
   受信したフレーム数と等しく、送信フレームより少ないフレームが伝達され
   たなら、供給流率は減らされ、テストは再実行されます。

   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軸はフレームサイズで、Y軸はフレー
   ム率であるべきです(SHOULD)。グラフの上に少なくとも2つの線があるべき
   です(SHOULD)。1つはメディアで様々なフレームサイズを使った場合の理論
   的なフレームレートを示す線であるべきです(SHOULD)。もう1つは試験結果
   のプロットであるべきです(SHOULD)。各データタイプでの結果報告のグラフ
   に追加の線が使われるかもしれません(MAY)。グラフに伴っているテキストは
   プロトコルとデータストリームフォーマットとテストで使われたメディアタ
   イプを示すべきです(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 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.
   もしひとつの値が広告の目的で必要なら、我々はベンダーがメディアの最小
   フレームサイズのレートを選ぶであろうと想定します。もしこれがされるな
   ら、数字は秒毎のフレーム数で表現されなくてはなりません(MUST)。もしベ
   ンダーが望むなら、そのレートは秒毎のビット数(あるいはバイト数)でも
   表現されるかもしれません(MAY)。性能記述は、a/測定された最大のフレーム
   率、b/使われたフレームサイズ、c/そのフレームサイズとメディアでの理論
   的限界、d/テストで使ったプロトコル、を含まなくてはなりません(MUST)。
   たとえひとつの値が広告のコピーの一部として用いられるとしても、結果の
   完全な表が製品データシートに含められるべきです(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を
   通して、特定の宛先に特定のフレームサイズの、フレーム流を送ります。流
   れは少なくとも120秒持続すべきです(SHOULD)。識別タグは60秒後に1
   フレーム含むべきです(SHOULD)、タグタイプは実装依存です。このフレーム
   が完全に送り出された時刻が記録されます(タイムスタンプA)。テスト装
   置の受信ロジックはフレーム流からタグ情報を認識し(MUST)、タグを付けら
   れたフレームを受信した時刻を記録します(タイムスタンプ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.
   応答時間はタイムスタンプB引くタイムスタンプAで、これがRFC124
   2の定義、すなわち蓄積転送装置かビット転送装置の応答時間が、に関連し
   ます。

   The test MUST be repeated at least 20 times with the reported value
   being the average of the recorded values.
   テストは少なくとも20回繰り返され(MUST)、報告値は記録された値の平均
   です。

   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の)いずれの応答時間の定義がこ
   のテストで使われたか述べなくてはなりません(MUST)。応答時間結果は行
   がテストされたフレームサイズのそれぞれである表のフォーマットで報告
   されるべきです(SHOULD)。各フレームサイズの列で、応答時間テストを行っ
   たレート、テストメディアタイプ、応答時間結果値の列があるべきです
   (SHOULD)。

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の入力データ率とフレームサイズの全部の範囲で,RFC12
   42で定義されるフレーム損失率を決定する。

   Procedure:  Send a specific number of frames at a specific rate
   through the DUT to be tested and count the frames that are
   transmitted by the DUT.  The frame loss rate at each point is
   calculated using the following equation:
   手順:特定の数のフレームを特定のレートでDUTを通して送り、DUTに
   よって転送されたフレームの数を数えます。各ポイントでのフレーム損失率
   は次の式を使って計算します:

          ( ( input_count - output_count ) * 100 ) / input_count


   The first trial SHOULD be run for the frame rate that corresponds to
   100% of the maximum rate for the frame size on the input media.
   Repeat the procedure for the rate that corresponds to 90% of the
   maximum rate used and then for 80% of this rate.  This sequence
   SHOULD be continued (at reducing 10% intervals) until there are two
   successive trials in which no frames are lost. The maximum
   granularity of the trials MUST be 10% of the maximum rate, a finer
   granularity is encouraged.
   最初のトライアルは入力メディアのフレームサイズに対する最大レートの1
   00%に対応するフレーム率で行うべきです(SHOULD)。最大レートの90%
   に対応する率と、次に80%に対応する率で手順を繰り返してください。こ
   の連続は、2回連続フレームが失われないトライアルがあるまで(10%づ
   つ減らしながら)続けられるべきです(SHOULD)。トライアルの最大粒度は最
   大の率の10%に違いありません(MUST)、より素晴らしい粒度が奨励されま
   す。

   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軸は、特定フレームサイ
   ズでのメディアの理論的レートのパーセントとしての、入力フレーム率であ
   るに違いありません(MUST)。Y軸は特定入力率での損失パーセントに違いあ
   りません(MUST)。X軸とY軸の底と左の終わりは0パーセントであるに違い
   ありません(MUST);X軸とY軸の最上部の正しい終わりは100パーセント
   であるに違いありません。異なったフレームサイズやプロトコルやデータ流
   のタイプの報告で、多数の線のグラフが使われます(MAY)。

   Note: See section 18 for the maximum frame rates that SHOULD be used.
   ノート:使われるべき(SHOULD)最大フレーム率は18章を見てください。

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.
   目的:RFC1242で定義される、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にバーストフレームを送り、DTUの転送
   するフレームを数えます。もし伝達されたフレーム数が送ったフレーム数と
   等しいなら、バースト長さを増やし、テストを再実行します。もし伝達され
   たフレーム数が送ったフレーム数以下なら、バースト長を減らし、テストを
   再実行します。

   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秒で(MUST)、少なくとも50回以上繰り
   返されるべきで(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)。各測定の標準偏差が報告されるかもしれません(MAY)。

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秒間、フレーム流を送ります。タイムスタンプA
   においてフレーム率を上記の率の50%に下げて、そして失われた最後のフ
   レームの時刻(タイムスタンプB)を記録します。システム回復時はタイム
   スタンプBからタイムスタンプAを引くことで決定します。テストは何度も
   繰り返されるべきです(SHOULD)、そして記録された値の平均を報告します。

   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が回復するスピードを描写する。

   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.
   このテストは、ルーティング更新の受信まで遅れが生じないように、直接D
   UTに接続したネットワーク宛のフレームを使ってだけ行うべきです(SHOULD)。

   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.
   ハードウェアとソフトウェアリセットが、電力中断と同様にテストされるべ
   きです(SHOULD)。

   Reporting format:  The reset value SHOULD be reported in a simple set
   of statements, one for each reset type.
   報告フォーマット:リセット値は各リセットタイプ毎に単純な文で報告され
   るべきです(SHOULD)。

27. Security Considerations
27. セキュリティの考察

   Security issues are not addressed in this document.
   この文書でセキュリティ問題が扱われない。

28. Editors' Addresses
28. 著者のアドレス

   Scott Bradner
   Harvard University
   1350 Mass. Ave, room 813
   Cambridge, MA 02138

   Phone: +1 617 495-3864
   Fax:   +1 617 496-8500
   EMail: sob@harvard.edu


   Jim McQuaid
   NetScout Systems
   4 Westford Tech Park Drive
   Westford, MA 01886

   Phone: +1 978 614-4116
   Fax:   +1 978 614-4004
   EMail: 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でテストを作る方法、のベンチマーク方
   法を議論します。この付録は、文書の本体での方法論の記述の改正と読んで
   ははなりません(MUST not)が、テスト実行の案内として読めます。

   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)性能が、2つの同一の装置を適切な短い距離
      のWANモデムをつなぐ設定で行われるかもしれません。能力を1つのD
      UTのLANインターフェースから、他のDUTのLANインターフェー
      ス間で測定します。

   The maximum frame rate to be used for LAN-WAN-LAN configurations is a
   judgment that can be based on known characteristics of the overall
   system including compression effects, fragmentation, and gross link
   speeds. Practice suggests that the rate should be at least 110% of
   the slowest link speed. Substantive issues of testing compression
   itself are beyond the scope of this document.
   LAN−WAN−LAN設定で使われる最大のフレーム率は圧縮効果、分割、
   総リンク速度を含めて全体的なシステムの周知の特徴に基づき得る決定です。
   実践が最も遅いリンクスピードの少なくとも110%のレートであるべきで
   あることを示唆します。それ自身圧縮をテストすることについての実質的な
   問題がこの文書の範囲外です。

Appendix B: Maximum frame rates reference
付録B:最大限フレームレートの参考文献。

      (Provided by Roger Beeman, Cisco Systems)
      (CISCOシステムズのRoger Beemanによる供給)

        Size       Ethernet    16Mb Token Ring      FDDI
      サイズ イーサーネット 16Mbトークンリング FDDI
       (bytes)       (pps)           (pps)         (pps)

       64            14880           24691         152439
       128            8445           13793          85616
       256            4528            7326          45620
       512            2349            3780          23585
       768            1586            2547          15903
       1024           1197            1921          11996
       1280            961            1542           9630
       1518            812            1302           8138

      Ethernet size
      イーサーネットサイズ
       Preamble 64 bits
       Frame 8 x N bits
       Gap  96 bits

      16Mb Token Ring size
      16Mbトークンリングサイズ
         SD               8 bits
         AC               8 bits
         FC               8 bits
         DA              48 bits
         SA              48 bits
         RI              48 bits ( 06 30 00 12 00 30 )
         SNAP
           DSAP           8 bits
           SSAP           8 bits
           Control        8 bits
           Vendor        24 bits
           Type          16 bits
         Data 8 x ( N - 18) bits
         FCS             32 bits
         ED               8 bits
         FS               8 bits

      Tokens or idles between packets are not included
      パケット間のトークンやアイドルは含まない

      FDDI size
      FDDIサイズ
         Preamble        64 bits
         SD               8 bits
         FC               8 bits
         DA              48 bits
         SA              48 bits
         SNAP
           DSAP           8 bits
           SSAP           8 bits
           Control        8 bits
           Vendor        24 bits
           Type          16 bits
         Data 8 x ( N - 18) bits
         FCS             32 bits
         ED               4 bits
         FS              12 bits


Appendix C: Test Frame Formats
付録C:テストフレームフォーマット

   This appendix defines the frame formats that may be used with these
   tests.  It also includes protocol specific parameters for TCP/IP over
   Ethernet to be used with the tests as an example.
   この付録はこれらのテストで使われるかもしれないフレームフォーマットを
   定義します。これはまた例として、イーサネット上のTCP/IPのテスト
   で使われるプロトコル特有パラメータを含みます。

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.

   訳注:RFC誤植情報によると上記の"198.19.255.255 are have been"は
   "198.19.255.255 have been"が正しいそうです。

   ネットワークアドレス192.18.0.0から198.19.255.255ま
   でがこの目的のために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までが「出力」ポー
   トで使用するために割り当てられました。例外なくルーターポートはネット
   ワーク上のノード1です。例えば、2ポートDUTは、1つのポートでIP
   アドレス198.18.1.1を、他のポートでIPアドレス198.19.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).
   方法論メモで記述されたテストのいくつかがDUTへのSNMP管理接続を
   利用します。DUTの管理アクセスアドレスは「入力」ポートの最初(19
   8.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ネットワークアドレスがD
   UTの「入力」側の幻ルータを通してアクセス可能なネットワークとして使
   用するため割り当てられます。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とCisco 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アドレスの間
   の返還を決定する手順が使われます。TCP/IPがこの機能を実行するた
   めにアドレス解決プロトコル(ARP)が使われます。XNSやIPXでは
   MACアドレスがプロトコルノードアドレスとして用いられるので、手順は
   必要ありません。

   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

           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つの宛先ネットワークアドレスが「入力」ポートの各ルー
   ティング更新で存在しています。各「入力」ポートへのテストストリームは、
   「出力」ポートそれぞれから成り立ちます。

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.
   テストフレームは必要なフレームサイズを埋めるのに十分なデータを持つU
   DPエコー要求です。データは全ビットがオフやオンのパターンは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番、のために記述されます。他のポートでフレー
   ムが使われるなら、アドレスがを変なくてはなりません。

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

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

          -- UDP HEADER
          34     02 08                 source port 208 = RIP
          36     02 08                 destination port 208 = RIP
          38     00 DA                 UDP message length
          40     00 00                 UDP checksum

          -- RIP packet

          42     02                  command = response
          43     01                  version = 1
          44     00 00               0

          -- net 1
          46     00 02               family = IP
          48     00 00               0
          50     xx xx xx            net 1 IP address
          53     00                  net not node
          54     00 00 00 00         0
          58     00 00 00 00         0
          62     00 00 00 07         metric 7

          -- net 2
          66     00 02               family = IP
          68     00 00               0
          70     xx xx xx            net 2 IP address
          73     00                  net not node
          74     00 00 00 00         0
          78     00 00 00 00         0
          82     00 00 00 07         metric 7

          -- net 3
          86     00 02               family = IP
          88     00 00               0
          90     xx xx xx            net 3 IP address
          93     00                  net not node
          94     00 00 00 00         0
          98     00 00 00 00         0
          102    00 00 00 07         metric 7

          -- net 4
          106    00 02               family = IP
          108    00 00               0
          110    xx xx xx            net 4 IP address
          113    00                  net not node
          114    00 00 00 00         0
          118    00 00 00 00         0
          122    00 00 00 07         metric 7

          -- net 5
          126    00 02               family = IP
          128    00 00               0
          130    00                  net 5 IP address
          133    00                  net not node
          134    00 00 00 00         0
          138    00 00 00 00         0
          142    00 00 00 07         metric 7

          -- net 6
          146    00 02               family = IP
          148    00 00               0
          150    xx xx xx            net 6 IP address
          153    00                  net not node
          154    00 00 00 00         0
          158    00 00 00 00         0
          162    00 00 00 07         metric 7

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**

          -- UDP HEADER

          34     C0 20                 source port
          36     00 07                 destination port 07 = Echo
          38     00 1A                 UDP message length*
          40     00 00                 UDP checksum

          -- UDP DATA
          42     00 01 02 03 04 05 06 07    some data***
          50     08 09 0A 0B 0C 0D 0E 0F

         * - change for different length frames
         * - フレームの長さが変る毎に変る

         ** - change for different logical streams
         ** - 論理流毎に変る

         *** - fill remainder of frame with incrementing octets,
         repeated if required by frame length
         *** - もしフレーム長で必要とされるまで、フレームの残りに
         オクテットを埋める。

   Values to be used in Total Length and UDP message length fields:
   合計長とUDPメッセージ長フィールドで使われるべき値:

          frame size   total length  UDP message length
        フレームサイズ    合計長     UDPメッセージ長
             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.
   この文書とここに含む情報は無保証で供給され、そしてインターネット学会
   とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
   報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、すべての保証を拒否します。

Japanese translation by Ishida So