rfc1944.txt

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

      too large for Ethernet should be reported as zero.

10. Verifying received frames

   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



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


   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.

   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.

11. Modifiers

   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.

   11.1 Broadcast frames

      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.

      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.

      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



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


      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.

   11.2 Management frames

      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.

      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.

   11.3 Routing update frames

      The processing of dynamic routing protocol updates could have a
      significant impact on the ability of a router to forward data
      frames.  The stream of test frames SHOULD be augmented with one
      routing update frame transmitted as the first frame transmitted
      during the trial.  Routing update frames SHOULD be sent at the
      rate specified in Appendix C for the specific routing protocol
      being used in the test. Two routing update frames are defined in
      Appendix C for the TCP/IP over Ethernet example.  The routing
      frames are designed to change the routing to a number of networks
      that are not involved in the forwarding of the test data.  The
      first frame sets the routing table state to "A", the second one
      changes the state to "B".  The frames MUST be alternated during
      the trial.

      The test SHOULD verify that the routing update was processed by
      the DUT.

   11.4 Filters

      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.





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


      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:

       forward input_protocol_address to output_protocol_address

      In bridges the filter SHOULD be of the form:

       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:

       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.

      The exact filters configuration command lines used SHOULD be
      included with the report of the results.

      11.4.1 Filter Addresses

         Two sets of filter addresses are required, one for the single
         filter case and one for the 25 filter case.

         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.

         The 25 filter case should follow the following sequence.

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



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


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

   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.

13. Route Set Up

   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.

14. Bidirectional traffic

   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.






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


15. Single stream path

   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.

16. Multi-port

   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.

   Consider the following 6 port 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:

    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



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


   the same output at the same time.

17. Multiple protocols

   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.

18. Multiple frame sizes

   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.

19. Testing performance beyond a single 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.

   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,