rfc2544.txt

著名的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

   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.

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.

1. Introduction

   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.







Bradner & McQuaid            Informational                      [Page 1]

RFC 2544                Benchmarking Methodology              March 1999


   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.

2. Real world

   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

   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.

4. Evaluating the results

   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.









Bradner & McQuaid            Informational                      [Page 2]

RFC 2544                Benchmarking Methodology              March 1999


5. Requirements

   In this document, the words that are used to define the significance
   of each particular requirement are capitalized. These words are:

      * "MUST" This word, or the words "REQUIRED" and "SHALL" mean that
         the item is an absolute requirement of the specification.

      * "SHOULD" This word or the adjective "RECOMMENDED" means that
         there may exist valid reasons in particular circumstances to
         ignore this item, but the full implications should be
         understood and the case carefully weighed before choosing a
         different course.

       * "MAY" This word or the adjective "OPTIONAL" means that this
         item is truly optional.  One vendor may choose to include the
         item because a particular marketplace requires it or because it
         enhances the product, for example; another vendor may omit the
         same item.

   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".

6. Test set up

   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.








Bradner & McQuaid            Informational                      [Page 3]

RFC 2544                Benchmarking Methodology              March 1999


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

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

6.1 Test set up for multiple media types

   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.

   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.

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

                                  Figure 3



Bradner & McQuaid            Informational                      [Page 4]

RFC 2544                Benchmarking Methodology              March 1999



7. DUT set up

   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.

8. Frame formats

   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.

9. Frame sizes

   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.

   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.




Bradner & McQuaid            Informational                      [Page 5]

RFC 2544                Benchmarking Methodology              March 1999


   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.

9.1 Frame sizes to be used on Ethernet

       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

       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.

9.3 Frame sizes to be used on 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.





Bradner & McQuaid            Informational                      [Page 6]