rfc2889.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,697 行 · 第 1/5 页

   To determine the rate of address learning of a LAN switching device.

5.8.2 Setup Parameters

   The following parameters MUST be defined.  Each variable is
   configured with the following considerations.

      Age Time - The maximum time that a DUT/SUT will keep a learned
      address in its forwarding table.

      Initial Addresses Learning Rate - The starting rate at which new
      addresses are offered to the DUT/SUT to be learned.

      Number of Addresses - The number of addresses that the DUT/SUT
      must learn.  The number MUST be between 1 and the maximum number
      supported by the implementation.  It is recommended no to exceed
      the address caching capacity found in section 5.9

5.8.3 Procedure

   The aging time of the DUT/SUT MUST be known.  The aging time MUST be
   longer than the time necessary to produce frames at the specified
   rate.  If a low frame rate is used for the test, then it may be
   possible that sending a large amount of frames may actually take
   longer than the aging time.

   This test MUST at a minimum be performed in a three-port
   configuration in section 5.9.3.  The test MAY be expanded to fully
   utilized the DUT/SUT in increments of two or three ports.  An
   increment of two would include an additional Learning port and Test
   port.  An increment of three would include an additional Learning
   port, Test port, and Monitoring port.

   An algorithm similar to the one used to determine address caching
   capacity can be used to determine the address learning rate.  This
   test iterates the rate at which address learning frames are offered





Mandeville & Perser          Informational                     [Page 25]

RFC 2889          LAN Switch Benchmarking Methodology        August 2000


   by the test device connected to the DUT/SUT.  It is recommended to
   set the number of addresses offered to the DUT/SUT in this test to
   the maximum caching capacity.

   The address learning rate might be determined for different numbers
   of addresses but in each test run, the number MUST remain constant
   and SHOULD be equal to or less than the maximum address caching
   capacity.

5.8.4 Measurements

   Whether the offered addresses per port were successful forwarded
   without flooding at the offered learning rate.

5.8.5 Reporting format

   After the test is run, results for each iteration SHOULD be displayed
   in a table:

      The number of addresses used for each test iteration (fixed).

      The intended load used for each test iteration (varied).

      Number of test frames that were transmitted by Tport.  This SHOULD
      match the number of addresses used for the test iteration.  Test
      frames are the frames sent with varying destination addresses to
      confirm that the DUT/SUT has learned all of the addresses for each
      test iteration.

      The flood count on Tport during the test portion of each test.  If
      the number is non-zero, this is an indication of the DUT/SUT
      flooding a frame in which the destination address is not in the
      address table.

      The number of frames correctly forwarded to test Lport during the
      test portion of the test.  Received frames MUST have the correct
      destination MAC address and SHOULD match a signature field.  For a
      passing test iteration, this number should be equal to the number
      of frames transmitted by Tport.

      The flood count on Lport during the test portion of each test.  If
      the number is non-zero, this is an indication of the DUT/SUT
      flooding a frame in which the destination address is not in the
      address table.







Mandeville & Perser          Informational                     [Page 26]

RFC 2889          LAN Switch Benchmarking Methodology        August 2000


      The flood count on Mport.  If the value is not zero, then this
      indicates that for that test iteration, the DUT/SUT could not
      determine the proper destination port for that many frames.  In
      other words, the DUT/SUT flooded the frame to all ports since its
      address table was full.

5.9 Errored frames filtering

5.9.1 Objective

   The objective of the Errored frames filtering test is to determine
   the behavior of the DUT under error or abnormal frame conditions.
   The results of the test indicate if the DUT/SUT filters the errors,
   or simply propagates the errored frames along to the destination.

5.9.2 Setup Parameters

   The following parameters MUST be defined.  Each variable is
   configured with the following considerations.

      ILoad - Intended Load per port is expressed in a percentage of the
      medium's maximum theoretical load possible.  The actual
      transmitted frame per second is dependent upon half duplex or full
      duplex operation.  The test SHOULD be run multiple times with a
      different load per port in each case.

      Trial Duration - The recommended Trial Duration is 30 seconds.
      Trial duration SHOULD be adjustable between 1 and 300 seconds.

5.9.3 Procedure

   Each of the illegal frames for Ethernet MUST be checked:

   Oversize - The DUT/SUT MAY filter frames larger than 1518 bytes from
   being propagated through the DUT/SUT section 4.2.4.2.1 [4].
   Oversized frames transmitted to the DUT/SUT should not be forwarded.
   DUT/SUT supporting tagged Frames MAY forward frames up to and
   including 1522 bytes long (section 4.2.4.2.1 [5]).

   Undersize - The DUT/SUT MUST filter frames less than 64 bytes from
   being propagated through the DUT/SUT (section 4.2.4.2.2 [4]).
   Undersized frames (or collision fragments) received by the DUT/SUT
   must not be forwarded.

   CRC Errors - The DUT/SUT MUST filter frames that fail the Frame Check
   Sequence Validation (section 4.2.4.1.2 [4]) from being propagated
   through the DUT/SUT.  Frames with an invalid CRC transmitted to the
   DUT/SUT should not be forwarded.



Mandeville & Perser          Informational                     [Page 27]

RFC 2889          LAN Switch Benchmarking Methodology        August 2000


   Dribble Bit Errors - The DUT/SUT MUST correct and forward frames
   containing dribbling bits.  Frames transmitted to the DUT/SUT that do
   not end in an octet boundary but contain a valid frame check sequence
   MUST be accepted by the DUT/SUT (section 4.2.4.2.1 [4]) and forwarded
   to the correct receive port with the frame ending in an octet
   boundary (section 3.4 [4]).

   Alignment Errors - The DUT/SUT MUST filter frames that fail the Frame
   Check Sequence Validation AND do not end in an octet boundary.  This
   is a combination of a CRC error and a Dribble Bit error.  When both
   errors are occurring in the same frame, the DUT/SUT MUST determine
   the CRC error takes precedence and filters the frame (section
   4.2.4.1.2 [4]) from being propagated.

5.9.5 Reporting format

   For each of the error conditions in section 5.6.3, a "pass" or "fail"
   MUST be reported.  Actual frame counts MAY be reported for diagnostic
   purposes.

5.10 Broadcast frame Forwarding and Latency

5.10.1 Objective

   The objective of the Broadcast Frame Forwarding and Latency Test is
   to determine the throughput and latency of the DUT when forwarding
   broadcast traffic.  The ability to forward broadcast frames will
   depend upon a specific function built into the device for that
   purpose.  It is therefore necessary to determine the ability of
   DUT/SUT to handle broadcast frames, since there may be many different
   ways of implementing such a function.

5.10.2 Setup Parameters

   The following parameters MUST be defined.  Each variable is
   configured with the following considerations.

      Frame Size - Recommended frame sizes are 64, 128, 256, 512, 1024,
      1280 and 1518 bytes, per RFC 2544 section 9 [3].  The four CRC
      bytes are included in the frame size specified.

      Duplex mode - Half duplex or full duplex.

      ILoad - Intended Load per port is expressed in a percentage of the
      medium's maximum theoretical load, regardless of traffic
      orientation or duplex mode.  Certain test configurations will
      theoretically over-subscribe the DUT/SUT.




Mandeville & Perser          Informational                     [Page 28]

RFC 2889          LAN Switch Benchmarking Methodology        August 2000


      ILoad will not over-subscribe the DUT/SUT in this test.

      Trial Duration - The recommended Trial Duration is 30 seconds.
      Trial duration SHOULD be adjustable between 1 and 300 seconds.

5.10.3 Procedure

   For this test, there are two parts to be run.

   Broadcast Frame Throughput - This portion of the test uses a single
   source test port to transmit test frames with a broadcast address
   using the frame specified in RFC 2544 [3].  Selected receive ports
   then measure the forwarding rate and Frame loss rate.

   Broadcast Frame Latency - This test uses the same setup as the
   Broadcast Frame throughput, but instead of a large stream of test
   frames being sent, only one test frame is sent and the latency to
   each of the receive ports are measured in seconds.

5.10.4 Measurements

   Frame loss rate of the DUT/SUT SHOULD be reported as defined in
   section 26.3 [3] with the following notes: Frame loss rate SHOULD be
   measured at the end of the trial duration.  The term "rate", for this
   measurement only, does not imply the units in the fashion of "per
   second."

   Forwarding rate (FR) of the DUT/SUT SHOULD be reported as the number
   of test frames per second that the device is observed to successfully
   forward to the correct destination interface in response to a
   specified Oload.  The Oload MUST also be cited.

5.10.5 Reporting format

   The results for these tests SHOULD be reported in the form of a
   graph.  The x coordinate SHOULD be the frame size, the y coordinate
   SHOULD be the test results.  There SHOULD be at least two lines on
   the graph, one plotting the theoretical and one plotting the test
   results.

   To measure the DUT/SUT's ability to switch traffic while performing
   many different address lookups, the number of addresses per port MAY
   be increased in a series of tests.








Mandeville & Perser          Informational                     [Page 29]

RFC 2889          LAN Switch Benchmarking Methodology        August 2000


6. Security Considerations

   As this document is solely for the purpose of providing metric
   methodology and describes neither a protocol nor a protocol's
   implementation, there are no security considerations associated with
   this document.

7.  References

   [1]   Bradner, S., Editor, "Benchmarking Terminology for Network
         Interconnection Devices", RFC 1242, July 1991.

   [2]   Mandeville, R., "Benchmarking Terminology for LAN Switching
         Devices", RFC 2285, February 1998.

   [3]   Bradner, S. and J. McQuaid, "Benchmarking Methodology for
         Network Interconnect Devices", RFC 2544, March 1999.

   [4]   ANSI/IEEE, "CSMA/CD Access Method and Physical Layer
         Specifications," ISO/IEC 8802-3, ISBN 0-7381-0330-6, 1998.

   [5]   IEEE Draft, "Frame Extensions for Virtual Bridged Local Area
         Networks (VLAN) Tagging on 802.3 Networks", 802.3ac/D3.1, July
         1998.

8. Authors' Addresses

   Robert Mandeville
   CQOS Inc.
   21 Technology
   Irvine, CA 92618
   USA

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


   Jerry Perser
   Spirent Communications
   26750 Agoura Road
   Calabasas, CA 91302
   USA

   Phone: + 1 818 676 2300
   EMail: [e-mail]






Mandeville & Perser          Informational                     [Page 30]

RFC 2889          LAN Switch Benchmarking Methodology        August 2000


Appendix A:  Formulas

A.1 Calculating the InterBurst Gap

   IBG is defined in RFC 2285 [2] as the interval between two bursts.
   To achieve a desired load, the following Input Parameter need to be
   defined:

     LENGTH - Frame size in bytes including the CRC.