rfc1944.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

      Procedure:
      First determine the throughput for a DUT at each of the listed
      frame sizes.

      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.

      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.

   26.6 Reset

      Objective:
      To characterize the speed at which a DUT recovers from a device or
      software reset.



Bradner & McQuaid            Informational                     [Page 18]

RFC 1944                Benchmarking Methodology                May 1996


      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 1944                Benchmarking Methodology                May 1996


28. Editors' Addresses

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

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


   Jim McQuaid
   Bay Networks
   3 Federal Street
   Billerica, MA 01821

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































Bradner & McQuaid            Informational                     [Page 20]

RFC 1944                Benchmarking Methodology                May 1996


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 1944                Benchmarking Methodology                May 1996


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 1944                Benchmarking Methodology                May 1996


        DSAP           8 bits
        SSAP           8 bits
        Control        8 bits
        Vendor        24 bits
        Type          16 bits
      Data 8 x ( N - 18) bits
      FCS             32 bits
      ED               4 bits
      FS              12 bits

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 192.19.255.255 are have
      been assigned to the BMWG by the IANA for this purpose.  This



Bradner & McQuaid            Informational                     [Page 23]

RFC 1944                Benchmarking Methodology                May 1996


      assignment was made to minimize the chance of conflict in case a
      testing device were to be accidentally connected to part of the
      Internet.  The specific use of the addresses is detailed below.

      C.2.2.1 Router port protocol addresses
         Half of the ports on a multi-port router are referred to as
         "input" ports and the other half as "output" ports even though
         some of the tests use all ports both as input and output.  A
         contiguous series of IP Class C network addresses from
         198.18.1.0 to 198.18.64.0 have been assigned for use on the
         "input" ports.  A second series from 198.19.1.0 to 198.19.64.0
         have been assigned for use on the "output" ports. In all cases
         the router port is node 1 on the appropriate network.  For
         example, a two port DUT would have an IP address of 198.18.1.1