rfc2285.txt

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

      Any technique used by a DUT/SUT to attempt to avoid frame loss by
      impeding external sources of traffic from transmitting frames to
      congested interfaces.

   Discussion:

      Some switches send jam signals, for example preamble bits, back to
      traffic sources when their transmit and/or receive buffers start
      to overfill.  Switches implementing full duplex Ethernet links may
      use IEEE 802.3x Flow Control for the same purpose.  Such devices
      may incur no frame loss when external sources attempt to offer
      traffic to congested or overloaded interfaces.




Mandeville                   Informational                     [Page 17]

RFC 2285                Benchmarking Terminology           February 1998


      It should be noted that jamming and other flow control methods may
      slow all traffic transmitted to congested input interfaces
      including traffic intended for uncongested output interfaces.

      A DUT/SUT applying backpressure may exhibit no frame loss when a
      tester attempts to overload one or more of its interfaces.  This
      should not be interpreted to suggest that the interfaces of the
      DUT/SUT support forwarding rates above the maximum rate allowed by
      the medium.  In these cases overloading is only apparent since
      through the application of backpressure the DUT/SUT avoids
      overloading by reducing the rate at which the tester can offer
      frames.

   Measurement units:

      frame loss on congested interface or interfaces N-octet frames per
      second between the interface applying backpressure and an
      uncongested destination interface

   Issues:

      jamming not explicitly described in standards

   See Also:

      intended load (3.5.1)
      offered load (3.5.2)
      overloading (3.5.4)
      forwarding rate (3.6.1)
      forward pressure (3.7.2)

3.7.2 Forward pressure

   Definition:

      Methods which depart from or otherwise violate a defined
      standardized protocol in an attempt to increase the forwarding
      performance of a DUT/SUT.

   Discussion:

      A DUT/SUT may be found to inhibit or abort back-off algorithms in
      order to force access to the medium when contention occurs.  It
      should be noted that the back-off algorithm should be fair whether
      the DUT/SUT is in a congested or an uncongested state.
      Transmission below the minimum inter-frame gap or the disregard of
      flow control primitives fall into this category.




Mandeville                   Informational                     [Page 18]

RFC 2285                Benchmarking Terminology           February 1998


      A DUT/SUT applying forward pressure may eliminate all or most
      frame loss when a tester attempts to overload one or more of its
      interfaces.  This should not be interpreted to suggest that the
      interfaces of the DUT/SUT can sustain forwarding rates above the
      maximum rate allowed by the medium.  Overloading in such cases is
      only apparent since the application of forward pressure by the
      DUT/SUT enables interfaces to relieve saturated output queues by
      forcing access to the medium and concomitantly inhibiting the
      tester from transmitting frames.

   Measurement units:

      intervals between frames in microseconds
      intervals in microseconds between transmission retries during
      16 successive collisions.

   Issues:

      truncated binary exponential back-off algorithm

   See Also:

      intended load (3.5.1)
      offered load (3.5.2)
      overloading (3.5.4)
      forwarding rate (3.6.1)
      backpressure (3.7.1)

3.7.3 Head of line blocking

   Definition:

      Frame loss or added delay observed on an uncongested output
      interface whenever frames are received from an input interface
      which is also attempting to forward frames to a congested output
      interface.

   Discussion:

      It is important to verify that a switch does not slow transmission
      or drop frames on interfaces which are not congested whenever
      overloading on one of its other interfaces occurs.

   Measurement units:

      forwarding rate and frame loss recorded on an uncongested
      interface when receiving frames from an interface which is also
      forwarding frames to a congested interface.



Mandeville                   Informational                     [Page 19]

RFC 2285                Benchmarking Terminology           February 1998


   Issues:

      input buffers

   See Also:

      unidirectional traffic (3.2.1)

3.8 Address handling

   This group of definitions applies to the address resolution process
   enabling a DUT/SUT to forward frames to their correct destinations.

3.8.1 Address caching capacity

   Definition:

      The number of MAC addresses per n interfaces, per module or per
      device that a DUT/SUT can cache and successfully forward frames to
      without flooding or dropping frames.

   Discussion:

      Users building networks will want to know how many nodes they can
      connect to a switch.  This makes it necessary to verify the number
      of MAC addresses that can be assigned per n interfaces, per module
      and per chassis before a DUT/SUT begins flooding frames.

   Measurement units:

      number of MAC addresses per n interfaces, modules, or chassis

   Issues:

   See Also:

      address learning rate (3.8.2)

3.8.2 Address learning rate

   Definition:

      The maximum rate at which a switch can learn new MAC addresses
      without flooding or dropping frames.







Mandeville                   Informational                     [Page 20]

RFC 2285                Benchmarking Terminology           February 1998


   Discussion:

      Users may want to know how long it takes a switch to build its
      address tables.  This information is useful to have when
      considering how long it takes a network to come up when many users
      log on in the morning or after a network crash.

   Measurement units:

      frames with different source addresses per second

   Issues:

   See Also:

      address caching capacity (3.8.1)

3.8.3 Flood count

   Definition:

      Frames forwarded to interfaces which do not correspond to the
      destination MAC address information when traffic is offered to a
      DUT/SUT for forwarding.

   Discussion:

      When recording throughput statistics it is important to check that
      frames have been forwarded to their proper destinations.  Flooded
      frames MUST NOT be counted as received frames.  Both known and
      unknown unicast frames can be flooded.

   Measurement units:

      N-octet valid frames

   Issues:

      spanning tree BPDUs.

   See Also:

      address caching capacity (3.8.1)

3.9 Errored frame filtering

   This group of definitions applies to frames with errors which a
   DUT/SUT may filter.



Mandeville                   Informational                     [Page 21]

RFC 2285                Benchmarking Terminology           February 1998


3.9.1 Errored frames

   Definition:

      Frames which are over-sized, under-sized, misaligned or with an
      errored Frame Check Sequence.

   Discussion:

      Switches, unlike IEEE 802.1d compliant bridges, do not necessarily
      filter all types of illegal frames.  Some switches, for example,
      which do not store frames before forwarding them to their
      destination interfaces may not filter over-sized frames (jabbers)
      or verify the validity of the Frame Check Sequence field.  Other
      illegal frames are under-sized frames (runts) and misaligned
      frames.

   Measurement units:

      n/a

   Issues:

   See Also:

3.10 Broadcasts

   This group of definitions applies to MAC layer and network layer
   broadcast frames.

3.10.1 Broadcast forwarding rate

   Definition:

      The number of broadcast frames per second that a DUT/SUT can be
      observed to deliver to all interfaces located within a broadcast
      domain in response to a specified offered load of frames directed
      to the broadcast MAC address.

   Discussion:

      There is no standard forwarding mechanism used by switches to
      forward broadcast frames.  It is useful to determine the broadcast
      forwarding rate for frames switched between interfaces on the same
      card, interfaces on different cards in the same chassis and






Mandeville                   Informational                     [Page 22]

RFC 2285                Benchmarking Terminology           February 1998


      interfaces on different chassis linked together over backbone
      connections.  The terms maximum broadcast forwarding rate and
      broadcast forwarding rate at maximum load follow directly from the
      terms already defined for forwarding rate measurements in section
      3.6 above.

   Measurement units:

      N-octet frames per second

   Issues:

   See Also:

      forwarding rate at maximum load (3.6.2)
      maximum forwarding rate (3.6.3)
      broadcast latency (3.10.2)

3.10.2 Broadcast latency

   Definition:

      The time required by a DUT/SUT to forward a broadcast frame to
      each interface located within a broadcast domain.

   Discussion:

      Since there is no standard way for switches to process
      broadcast frames, broadcast latency may not be the same on all
      receiving interfaces of a switching device.  The latency
      measurements SHOULD be bit oriented as described in section 3.8
      of RFC 1242.  It is useful to determine broadcast latency for
      frames forwarded between interfaces on the same card, on
      different cards in the same chassis and on different chassis
      linked over backbone connections.

   Measurement units:

         nanoseconds
         microseconds
         milliseconds
         seconds

   Issues:

   See Also:

      broadcast forwarding rate (3.10.1)



Mandeville                   Informational                     [Page 23]

RFC 2285                Benchmarking Terminology           February 1998


4. Security Considerations

   Documents of this type do not directly effect the security of the
   Internet or of corporate networks as long as benchmarking is not
   performed on devices or systems connected to operating networks.

   The document points out that switching devices may violate the IEEE
   802.3 standard by transmitting frames below the minimum interframe
   gap or unfairly accessing the medium by inhibiting the backoff
   algorithm.  Although such violations do not directly engender
   breaches in security, they may perturb the normal functioning of
   other interworking devices by obstructing their access to the medium.
   Their use on the Internet or on corporate networks should be
   discouraged.

5. References

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

   [2] Bradner, S., and J. McQuaid, "Benchmarking Methodology for
       Network Interconnect Devices", RFC 1944, May 1996.

6. Acknowledgments

   The Benchmarking Methodology Working Group of the IETF and
   particularly Kevin Dubray (Bay Networks) are to be thanked for the
   many suggestions they collectively made to help complete this
   document.  Ajay Shah (WG), Jean-Christophe Bestaux (ENL), Henry Hamon
   (Netcom Systems), Stan Kopek (Digital) and Doug Ruby (Prominet) all
   provided valuable input at various stages of this project.

   Special thanks go to Scott Bradner for his seminal work in the field
   of benchmarking and his many encouraging remarks.

7. Author's Address

   Robert Mandeville
   European Network Laboratories (ENL)
   2, rue Helene Boucher
   78286 Guyancourt Cedex
   France

   Phone: + 33 1 39 44 12 05
   Mobile Phone + 33 6 07 47 67 10
   Fax: + 33 1 39 44 12 06
   EMail: [e-mail]




Mandeville                   Informational                     [Page 24]

RFC 2285                Benchmarking Terminology           February 1998


8.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Mandeville                   Informational                     [Page 25]