rfc2544.txt

<VC++网络游戏建摸与实现>源代码

   device or software reset.

   Procedure:  First determine the throughput for the DUT for the
   minimum frame size on the media used in the testing.

   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.

   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.

   The reset value is obtained by subtracting Timestamp A from Timestamp
   B.

   Hardware and software resets, as well as a power interruption SHOULD
   be tested.

   Reporting format:  The reset value SHOULD be reported in a simple set
   of statements, one for each reset type.

27. Security Considerations

   Security issues are not addressed in this document.


















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


28. Editors' Addresses

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

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


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

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]































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


Appendix A: Testing Considerations

A.1 Scope Of This Appendix

   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.

   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.

   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.

   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.

   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.

   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.

   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.





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


Appendix B: Maximum frame rates reference

      (Provided by Roger Beeman, Cisco Systems)

        Size       Ethernet    16Mb Token Ring      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
         SD               8 bits
         AC               8 bits
         FC               8 bits
         DA              48 bits
         SA              48 bits
         RI              48 bits ( 06 30 00 12 00 30 )
         SNAP
           DSAP           8 bits
           SSAP           8 bits
           Control        8 bits
           Vendor        24 bits
           Type          16 bits
         Data 8 x ( N - 18) bits
         FCS             32 bits
         ED               8 bits
         FS               8 bits

      Tokens or idles between packets are not included

      FDDI size
         Preamble        64 bits
         SD               8 bits
         FC               8 bits
         DA              48 bits
         SA              48 bits
         SNAP



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


           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










































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


Appendix C: Test Frame Formats

   This appendix defines the frame formats that may be used with these
   tests.  It also includes protocol specific parameters for TCP/IP over
   Ethernet to be used with the tests as an example.

C.1. Introduction

   The general logic used in the selection of the parameters and the
   design of the frame formats is explained for each case within the
   TCP/IP section.  The same logic has been used in the other sections.
   Comments are used in these sections only if there is a protocol
   specific feature to be explained.  Parameters and frame formats for
   additional protocols can be defined by the reader by using the same
   logic.

C.2. TCP/IP Information

   The following section deals with the TCP/IP protocol suite.

C.2.1 Frame Type.

   An application level datagram echo request is used for the test data
   frame in the protocols that support such a function.  A datagram
   protocol is used to minimize the chance that a router might expect a
   specific session initialization sequence, as might be the case for a
   reliable stream protocol. A specific defined protocol is used because
   some routers verify the protocol field and refuse to forward unknown
   protocols.

   For TCP/IP a UDP Echo Request is used.

C.2.2 Protocol Addresses

   Two sets of addresses must be defined: first the addresses assigned
   to the router ports, and second the address that are to be used in
   the frames themselves and in the routing updates.

   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.








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


C.2.2.1 Router port protocol addresses

   Half of the ports on a multi-port router are referred to as "input"
   ports and the other half as "output" ports even though some of the
   tests use all ports both as input and output.  A contiguous series of
   IP Class C network addresses from 198.18.1.0 to 198.18.64.0 have been