1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc2285.txt b/doc/rfc/rfc2285.txt
new file mode 100644
index 0000000..da2c0f8
--- /dev/null
+++ b/doc/rfc/rfc2285.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group                                      R. Mandeville
+Request for Comments: 2285                 European Network Laboratories
+Category: Informational                                    February 1998
+
+
+           Benchmarking Terminology for LAN Switching Devices
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Table of Contents
+
+   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2. Existing definitions . . . . . . . . . . . . . . . . . . . . . . 2
+   3. Term definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
+      3.1 Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+         3.1.1 Device under test (DUT) . . . . . . . . . . . . . . . . 3
+         3.1.2 System under test (SUT) . . . . . . . . . . . . . . . . 3
+      3.2 Traffic orientation. . . . . . . . . . . . . . . . . . . . . 4
+         3.2.1 Unidirectional traffic. . . . . . . . . . . . . . . . . 4
+         3.2.2 Bidirectional traffic . . . . . . . . . . . . . . . . . 5
+      3.3 Traffic distribution . . . . . . . . . . . . . . . . . . . . 6
+         3.3.1 Non-meshed traffic. . . . . . . . . . . . . . . . . . . 6
+         3.3.2 Partially meshed traffic. . . . . . . . . . . . . . . . 7
+         3.3.3 Fully meshed traffic. . . . . . . . . . . . . . . . . . 8
+      3.4 Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+         3.4.1 Burst . . . . . . . . . . . . . . . . . . . . . . . . . 9
+         3.4.2 Burst size . . . . . . . . . . . . . . . . . . . . . . 10
+         3.4.3 Inter-burst gap (IBG). . . . . . . . . . . . . . . . . 10
+      3.5 Loads . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+         3.5.1 Intended load (Iload)  . . . . . . . . . . . . . . . . 11
+         3.5.2 Offered load (Oload) . . . . . . . . . . . . . . . . . 12
+         3.5.3 Maximum offered load (MOL) . . . . . . . . . . . . . . 13
+         3.5.4 Overloading  . . . . . . . . . . . . . . . . . . . . . 14
+      3.6 Forwarding rates  . . . . . . . . . . . . . . . . . . . . . 15
+         3.6.1 Forwarding rate (FR) . . . . . . . . . . . . . . . . . 15
+         3.6.2 Forwarding rate at maximum offered load (FRMOL). . . . 16
+         3.6.3 Maximum forwarding rate (MFR). . . . . . . . . . . . . 16
+      3.7 Congestion control  . . . . . . . . . . . . . . . . . . . . 17
+         3.7.1 Backpressure . . . . . . . . . . . . . . . . . . . . . 17
+         3.7.2 Forward pressure . . . . . . . . . . . . . . . . . . . 18
+
+
+
+Mandeville                   Informational                      [Page 1]
+
+RFC 2285                Benchmarking Terminology           February 1998
+
+
+         3.7.3 Head of line blocking  . . . . . . . . . . . . . . . . 19
+      3.8 Address handling  . . . . . . . . . . . . . . . . . . . . . 20
+         3.8.1 Address caching capacity . . . . . . . . . . . . . . . 20
+         3.8.2 Address learning rate  . . . . . . . . . . . . . . . . 20
+         3.8.3 Flood count  . . . . . . . . . . . . . . . . . . . . . 21
+      3.9 Errored frame filtering . . . . . . . . . . . . . . . . . . 21
+         3.9.1 Errored frames . . . . . . . . . . . . . . . . . . . . 22
+      3.10 Broadcasts . . . . . . . . . . . . . . . . . . . . . . . . 22
+         3.10.1 Broadcast forwarding rate at maximum load . . . . . . 22
+         3.10.2 Broadcast latency . . . . . . . . . . . . . . . . . . 23
+   4. Security Considerations . . . . . . . . . . . . . . . . . . . . 24
+   5. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+   6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 24
+   7. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . 24
+   8. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 25
+
+1. Introduction
+
+   This document is intended to provide terminology for the benchmarking
+   of local area network (LAN) switching devices.  It extends the
+   terminology already defined for benchmarking network interconnect
+   devices in RFCs 1242 and 1944 to switching devices.
+
+   Although it might be found useful to apply some of the terms defined
+   here to a broader range of network interconnect devices, this RFC
+   primarily deals with devices which switch frames at the Medium Access
+   Control (MAC) layer.  It defines terms in relation to the traffic put
+   to use when benchmarking switching devices, forwarding performance,
+   congestion control, latency, address handling and filtering.
+
+2.  Existing definitions
+
+   RFC 1242 "Benchmarking Terminology for Network Interconnect Devices"
+   should be consulted before attempting to make use of this document.
+   RFC 1944 "Benchmarking Methodology for Network Interconnect Devices"
+   contains discussions of a number of terms relevant to the
+   benchmarking of switching devices and should also be consulted.
+
+   For the sake of clarity and continuity this RFC adopts the template
+   for definitions set out in Section 2 of RFC 1242.  Definitions are
+   indexed and grouped together in sections for ease of reference.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119.
+
+
+
+
+
+
+Mandeville                   Informational                      [Page 2]
+
+RFC 2285                Benchmarking Terminology           February 1998
+
+
+3. Term definitions
+
+3.1 Devices
+
+   This group of definitions applies to all types of networking devices.
+
+3.1.1 Device under test (DUT)
+
+   Definition:
+
+      The network forwarding device to which stimulus is offered and
+      response measured.
+
+   Discussion:
+
+      A single stand-alone or modular unit which receives frames on one
+      or more of its interfaces and then forwards them to one or more
+      interfaces according to the addressing information contained in
+      the frame.
+
+   Measurement units:
+
+      n/a
+
+   Issues:
+
+   See Also:
+
+      system under test (SUT) (3.1.2)
+
+3.1.2 System Under Test (SUT)
+
+   Definition:
+
+      The collective set of network devices to which stimulus is offered
+      as a single entity and response measured.
+
+   Discussion:
+
+      A system under test may be comprised of a variety of networking
+      devices.  Some devices may be active in the forwarding decision-
+      making process, such as routers or switches; other devices may be
+      passive such as a CSU/DSU.  Regardless of constituent components,
+      the system is treated as a singular entity to which stimulus is
+      offered and response measured.
+
+
+
+
+
+
+Mandeville                   Informational                      [Page 3]
+
+RFC 2285                Benchmarking Terminology           February 1998
+
+
+   Measurement units:
+
+      n/a
+
+   Issues:
+
+   See Also:
+
+      device under test (DUT) (3.1.1)
+
+3.2 Traffic orientation
+
+   This group of definitions applies to the traffic presented to the
+   interfaces of a DUT/SUT and indicates whether the interfaces are
+   receiving only, transmitting only, or both receiving and
+   transmitting.
+
+3.2.1 Unidirectional traffic
+
+   Definition:
+
+      When all frames presented to the input interfaces of a DUT/SUT are
+      addressed to output interfaces which do not themselves receive any
+      frames.
+
+   Discussion:
+
+      This definition conforms to the discussion in section 16 of RFC
+      1944 which describes how unidirectional traffic can be offered to
+      a DUT/SUT to measure throughput.  Unidirectional traffic is also
+      appropriate for:
+
+      -the measurement of the minimum inter-frame gap -the creation of
+      many-to-one or one-to-many interface overload -the detection of
+      head of line blocking -the measurement of forwarding rates and
+      throughput when congestion control mechanisms are active.
+
+      When a tester offers unidirectional traffic to a DUT/SUT reception
+      and transmission are handled by different interfaces or sets of
+      interfaces of the DUT/SUT.  All frames received from the tester by
+      the DUT/SUT are transmitted back to the tester from interfaces
+      which do not themselves receive any frames.
+
+      It is useful to distinguish traffic orientation and traffic
+      distribution when considering traffic patterns used in device
+      testing.  Unidirectional traffic, for example, is traffic
+      orientated in a single direction between mutually exclusive sets
+      of source and destination interfaces of a DUT/SUT.  Such traffic,
+
+
+
+Mandeville                   Informational                      [Page 4]
+
+RFC 2285                Benchmarking Terminology           February 1998
+
+
+      however, can be distributed between interfaces in different ways.
+      When traffic is sent to two or more interfaces from an external
+      source and then forwarded by the DUT/SUT to a single output
+      interface the traffic orientation is unidirectional and the
+      traffic distribution between interfaces is many-to-one.  Traffic
+      can also be sent to a single input interface and forwarded by the
+      DUT/SUT to two or more output interfaces to achieve a one-to-many
+      distribution of traffic.
+
+      Such traffic distributions can also be combined to test for head
+      of line blocking or to measure forwarding rates and throughput
+      when congestion control mechanisms are active.
+
+      When a DUT/SUT is equipped with interfaces running at different
+      media rates the number of input interfaces required to load or
+      overload an output interface or interfaces will vary.
+
+      It should be noted that measurement of the minimum inter-frame gap
+      serves to detect violations of the IEEE 802.3 standard.
+
+   Issues:
+
+      half duplex / full duplex
+
+   Measurement units:
+
+      n/a
+
+   See Also:
+
+      bidirectional traffic (3.2.2)
+      non-meshed traffic (3.3.1)
+      partially meshed traffic (3.3.2)
+      fully meshed traffic (3.3.3)
+      congestion control (3.7)
+      head of line blocking (3.7.3)
+
+3.2.2 Bidirectional traffic
+
+   Definition:
+
+      Frames presented to a DUT/SUT such that every receiving interface
+      also transmits.
+
+   Discussion:
+
+      This definition conforms to the discussion in section 14 of RFC
+      1944.
+
+
+
+Mandeville                   Informational                      [Page 5]
+
+RFC 2285                Benchmarking Terminology           February 1998
+
+
+      When a tester offers bidirectional traffic to a DUT/SUT all the
+      interfaces which receive frames from the tester also transmit
+      frames back to the tester.
+
+      Bidirectional traffic MUST be offered when measuring the
+      throughput or forwarding rate of full duplex interfaces of a
+      switching device.
+
+   Issues:
+
+      truncated binary exponential back-off algorithm
+
+   Measurement units:
+
+      n/a
+
+   See Also:
+
+      unidirectional traffic (3.2.1)
+      non-meshed traffic (3.3.1)
+      partially meshed traffic (3.3.2)
+      fully meshed traffic (3.3.3)
+
+3.3 Traffic distribution
+
+   This group of definitions applies to the distribution of frames
+   forwarded by a DUT/SUT.
+
+3.3.1 Non-meshed traffic
+
+   Definition:
+
+      Frames offered to a single input interface and addressed to a
+      single output interface of a DUT/SUT where input and output
+      interfaces are grouped in mutually exclusive pairs.
+
+   Discussion:
+
+      In the simplest instance of non-meshed traffic all frames are
+      offered to a single input interface and addressed to a single
+      output interface.  The one-to-one mapping of input to output
+      interfaces required by non-meshed traffic can be extended to
+      multiple mutually exclusive pairs of input and output interfaces.
+
+   Measurement units:
+
+      n/a
+
+
+
+
+Mandeville                   Informational                      [Page 6]
+
+RFC 2285                Benchmarking Terminology           February 1998
+
+
+   Issues:
+
+      half duplex / full duplex
+
+   See Also:
+
+      unidirectional traffic (3.2.1)
+      bidirectional traffic (3.2.2)
+      partially meshed traffic (3.3.2.)
+      fully meshed traffic (3.3.3)
+      burst (3.4.1)
+
+3.3.2 Partially meshed traffic
+
+   Definition:
+
+      Frames offered to one or more input interfaces of a DUT/SUT and
+      addressed to one or more output interfaces where input and output
+      interfaces are mutually exclusive and mapped one-to-many, many-
+      to-one or many-to-many.
+
+   Discussion:
+
+      This definition follows from the discussion in section 16 of RFC
+      1944 on multi-port testing.  Partially meshed traffic allows for
+      one-to-many, many-to-one or many-to-many mappings of input to
+      output interfaces and readily extends to configurations with
+      multiple switching devices linked together over backbone
+      connections.
+
+      It should be noted that partially meshed traffic can load backbone
+      connections linking together two switching devices or systems more
+      than fully meshed traffic.  When offered partially meshed traffic
+      devices or systems can be set up to forward all of the frames they
+      receive to the opposite side of the backbone connection whereas
+      fully meshed traffic requires at least some of the offered frames
+      to be forwarded locally, that is to the interfaces of the DUT/SUT
+      receiving them.  Such frames will not traverse the backbone
+      connection.
+
+   Measurement units:
+
+      n/a
+
+   Issues:
+
+      half duplex / full duplex
+
+
+
+
+Mandeville                   Informational                      [Page 7]
+
+RFC 2285                Benchmarking Terminology           February 1998
+
+
+   See Also:
+
+      unidirectional traffic (3.2.1)
+      bidirectional traffic (3.2.2)
+      non-meshed traffic (3.3.1)
+      fully meshed traffic (3.3.3)
+      burst (3.4.1)
+
+3.3.3 Fully meshed traffic
+
+   Definition:
+
+      Frames offered to a designated number of interfaces of a DUT/SUT
+      such that each one of the interfaces under test receives frames
+      addressed to all of the other interfaces under test.
+
+   Discussion:
+
+      As with bidirectional partially meshed traffic, fully meshed
+      traffic requires each one the interfaces of a DUT/SUT to both
+      receive and transmit frames.  But since the interfaces are not
+      divided into groups as with partially meshed traffic every
+      interface forwards frames to and receives frames from every other
+      interface.  The total number of individual input/output interface
+      pairs when traffic is fully meshed over n switched interfaces
+      equals n x (n - 1).  This compares with n x (n / 2) such interface
+      pairs when traffic is partially meshed.
+
+      Fully meshed traffic on half duplex interfaces is inherently
+      bursty since interfaces must interrupt transmission whenever they
+      receive frames.  This kind of bursty meshed traffic is
+      characteristic of real network traffic and can be advantageously
+      used to diagnose a DUT/SUT by exercising many of its component
+      parts simultaneously.  Additional inspection may be warranted to
+      correlate the frame forwarding capacity of a DUT/SUT when offered
+      meshed traffic and the behavior of individual elements such as
+      input or output buffers, buffer allocation mechanisms, aggregate
+      switching capacity, processing speed or medium access control.
+
+      The analysis of forwarding rate measurements presents a challenge
+      when offering bidirectional or fully meshed traffic since the rate
+      at which the tester can be observed to transmit frames to the
+      DUT/SUT may be smaller than the rate at which it intends to
+      transmit due to collisions on half duplex media or the action of
+      congestion control mechanisms.  This makes it important to take
+      account of both the intended and offered loads defined in sections
+      3.5.1.and 3.5.2 below when reporting the results of such
+      forwarding rate measurements.
+
+
+
+Mandeville                   Informational                      [Page 8]
+
+RFC 2285                Benchmarking Terminology           February 1998
+
+
+      When offering bursty meshed traffic to a DUT/SUT a number of
+      variables have to be considered.  These include frame size, the
+      number of frames within bursts, the interval between bursts as
+      well as the distribution of load between incoming and outgoing
+      traffic.  Terms related to bursts are defined in section 3.4
+      below.
+
+   Measurement units:
+
+      n/a
+
+   Issues:
+
+      half duplex / full duplex
+
+   See Also:
+
+      unidirectional traffic (3.2.1)
+      bidirectional traffic (3.2.2)
+      non-meshed traffic (3.3.1)
+      partially meshed traffic (3.3.2)
+      burst (3.4.1)
+      intended load (3.5.1)
+      offered load (3.5.2)
+
+3.4 Bursts
+
+   This group of definitions applies to the intervals between frames or
+   groups of frames offered to the DUT/SUT.
+
+3.4.1 Burst
+
+   Definition:
+
+      A sequence of frames transmitted with the minimum legal inter-
+      frame gap.
+
+   Discussion:
+
+      This definition follows from discussions in section 3.16 of RFC
+      1242 and section 21 of RFC 1944 which describes cases where it is
+      useful to consider isolated frames as single frame bursts.
+
+   Measurement units:
+
+      n/a
+
+   Issues:
+
+
+
+Mandeville                   Informational                      [Page 9]
+
+RFC 2285                Benchmarking Terminology           February 1998
+
+
+   See Also:
+
+      burst size (3.4.2)
+      inter-burst gap (IBG) (3.4.3)
+
+3.4.2 Burst size
+
+   Definition:
+
+      The number of frames in a burst.
+
+   Discussion:
+
+      Burst size can range from one to infinity.  In unidirectional
+      traffic as well as in bidirectional or meshed traffic on full
+      duplex interfaces there is no theoretical limit to burst length.
+      When traffic is bidirectional or meshed bursts on half duplex
+      media are finite since interfaces interrupt transmission
+      intermittently to receive frames.
+
+      On real networks burst size will normally increase with window
+      size.  This makes it desirable to test devices with small as well
+      as large burst sizes.
+
+   Measurement units:
+
+      number of N-octet frames
+
+   Issues:
+
+   See Also:
+
+      burst (3.4.1)
+      inter-burst gap (IBG) (3.4.3)
+
+3.4.3 Inter-burst gap (IBG)
+
+   Definition:
+
+      The interval between two bursts.
+
+   Discussion:
+
+      This definition conforms to the discussion in section 20 of RFC
+      1944 on bursty traffic.
+
+
+
+
+
+
+Mandeville                   Informational                     [Page 10]
+
+RFC 2285                Benchmarking Terminology           February 1998
+
+
+      Bidirectional and meshed traffic are inherently bursty since
+      interfaces share their time between receiving and transmitting
+      frames.  External sources offering bursty traffic for a given
+      frame size and burst size must adjust the inter-burst gap to
+      achieve a specified average rate of frame transmission.
+
+   Measurement units:
+
+      nanoseconds
+      microseconds
+      milliseconds
+      seconds
+
+   Issues:
+
+   See Also:
+
+      burst (3.4.1)
+      burst size (3.4.2)
+
+3.5 Loads
+
+   This group of definitions applies to the rates at which traffic is
+   offered to any DUT/SUT.
+
+3.5.1 Intended load (Iload)
+
+   Definition:
+
+      The number of frames per second that an external source attempts
+      to transmit to a DUT/SUT for forwarding to a specified output
+      interface or interfaces.
+
+   Discussion:
+
+      Collisions on CSMA/CD links or the action of congestion control
+      mechanisms can effect the rate at which an external source of
+      traffic transmits frames to a DUT/SUT.  This makes it useful to
+      distinguish the load that an external source attempts to apply to
+      a DUT/SUT and the load it is observed or measured to apply.
+
+      In the case of Ethernet an external source of traffic MUST
+      implement the truncated binary exponential back-off algorithm to
+      ensure that it is accessing the medium legally
+
+
+
+
+
+
+
+Mandeville                   Informational                     [Page 11]
+
+RFC 2285                Benchmarking Terminology           February 1998
+
+
+   Measurement units:
+
+      bits per second
+      N-octets per second
+      (N-octets per second / media_maximum-octets per second) x 100
+
+   Issues:
+
+   See Also:
+
+      burst (3.4.1)
+      inter-burst gap (3.4.3)
+      offered load (3.5.2)
+
+3.5.2 Offered load (Oload)
+
+   Definition:
+
+      The number of frames per second that an external source can be
+      observed or measured to transmit to a DUT/SUT for forwarding to a
+      specified output interface or interfaces.
+
+   Discussion:
+
+      The load which an external device can be observed to apply to a
+      DUT/SUT may be less than the intended load due to collisions on
+      half duplex media or the action of congestion control mechanisms.
+      This makes it important to distinguish intended and offered load
+      when analyzing the results of forwarding rate measurements using
+      bidirectional or fully meshed traffic.
+
+      Frames which are not successfully transmitted by an external
+      source of traffic to a DUT/SUT MUST NOT be counted as transmitted
+      frames when measuring forwarding rates.
+
+      The frame count on an interface of a DUT/SUT may exceed the rate
+      at which an external device offers frames due to the presence of
+      spanning tree BPDUs (Bridge Protocol Data Units) on 802.1D-
+      compliant switches or SNMP frames.  Such frames should be treated
+      as modifiers as described in section 11 of RFC 1944.
+
+      Offered load MUST be indicated when reporting the results of
+      forwarding rate measurements.
+
+
+
+
+
+
+
+
+Mandeville                   Informational                     [Page 12]
+
+RFC 2285                Benchmarking Terminology           February 1998
+
+
+   Measurement units:
+
+      bits per second
+      N-octets per second
+      (N-octets per second / media_maximum-octets per second) x 100
+
+   Issues:
+
+      token ring
+
+   See Also:
+
+      bidirectional traffic (3.2.2)
+      fully meshed traffic (3.3.3)
+      intended load (3.5.1)
+      forwarding rate (3.6.1)
+
+3.5.3 Maximum offered load (MOL)
+
+   Definition:
+
+      The highest number of frames per second that an external source
+      can transmit to a DUT/SUT for forwarding to a specified output
+      interface or interfaces.
+
+   Discussion:
+
+      The maximum load that an external device can apply to a DUT/SUT
+      may not equal the maximum load allowed by the medium.  This
+      will be the case  when an external source lacks the resources
+      to transmit frames at the minimum legal inter-frame gap or when
+      it has sufficient resources to transmit frames below the
+      minimum legal inter-frame gap.  Moreover, maximum load may vary
+      with respect to parameters other than a medium's maximum
+      theoretical utilization.  For example, on those media employing
+      tokens, maximum load may vary as a function of Token Rotation
+      Time, Token Holding Time, or the ability to chain multiple
+      frames to a single token.  The maximum load that an external
+      device applies to a DUT/SUT MUST be specified when measuring
+      forwarding rates.
+
+   Measurement units:
+
+      bits per second
+      N-octets per second
+      (N-octets per second / media_maximum-octets per second) x 100
+
+   Issues:
+
+
+
+Mandeville                   Informational                     [Page 13]
+
+RFC 2285                Benchmarking Terminology           February 1998
+
+
+   See Also:
+
+      offered load (3.5.2)
+
+3.5.4 Overloading
+
+   Definition:
+
+      Attempting to load a DUT/SUT in excess of the maximum rate of
+      transmission allowed by the medium.
+
+   Discussion:
+
+      Overloading can serve to exercise buffers and buffer allocation
+      algorithms as well as congestion control mechanisms.  The number
+      of input interfaces required to overload one or more output
+      interfaces of a DUT/SUT will vary according to the media rates of
+      the interfaces involved.
+
+      An external source can also overload an interface by transmitting
+      frames below the minimum inter-frame gap.  A DUT/SUT MUST forward
+      such frames at intervals equal to or above the minimum gap
+      specified in standards.
+
+      A DUT/SUT using congestion control techniques such as backpressure
+      or forward pressure may exhibit no frame loss when a tester
+      attempts to overload one or more of its interfaces.  This should
+      not be exploited to suggest that the DUT/SUT supports rates of
+      transmission in excess of the maximum rate allowed by the medium
+      since both techniques reduce the rate at which the tester offers
+      frames to prevent overloading.  Backpressure achieves this purpose
+      by jamming the transmission interfaces of the tester and forward
+      pressure by hindering the tester from gaining fair access to the
+      medium.  Analysis of both cases should take the distinction
+      between intended load (3.5.1) and offered load (3.5.2) into
+      account.
+
+   Measurement units:
+
+      bits per second
+      N-octets per second
+      (N-octets per second / media_maximum-octets per second) x 100
+
+   Issues:
+
+
+
+
+
+
+
+Mandeville                   Informational                     [Page 14]
+
+RFC 2285                Benchmarking Terminology           February 1998
+
+
+   See Also:
+
+      unidirectional traffic (3.2.1)
+      intended load (3.5.1)
+      offered load (3.5.2)
+      forwarding rate (3.6.1)
+      backpressure (3.7.1)
+      forward pressure (3.7.2)
+
+3.6 Forwarding rates
+
+   This group of definitions applies to the rates at which traffic is
+   forwarded by any DUT/SUT in response to a stimulus.
+
+3.6.1 Forwarding rate (FR)
+
+   Definition:
+
+      The number of frames per second that a device can be observed to
+      successfully transmit to the correct destination interface in
+      response to a specified offered load.
+
+   Discussion:
+
+      Unlike throughput defined in section 3.17 of RFC 1242, forwarding
+      rate makes no explicit reference to frame loss.  Forwarding rate
+      refers to the number of frames per second observed on the output
+      side of the interface under test and MUST be reported in relation
+      to the offered load.  Forwarding rate can be measured with
+      different traffic orientations and distributions.
+
+      It should be noted that the forwarding rate of a DUT/SUT may be
+      sensitive to the action of congestion control mechanisms.
+
+   Measurement units:
+
+      N-octet frames per second
+
+   Issues:
+
+   See Also:
+
+      offered load (3.5.2)
+      forwarding rate at maximum offered load (3.6.2)
+      maximum forwarding rate (3.6.3)
+
+
+
+
+
+
+Mandeville                   Informational                     [Page 15]
+
+RFC 2285                Benchmarking Terminology           February 1998
+
+
+3.6.2 Forwarding rate at maximum offered load (FRMOL)
+
+   Definition:
+
+      The number of frames per second that a device can be observed to
+      successfully transmit to the correct destination interface in
+      response to the maximum offered load.
+
+   Discussion:
+
+      Forwarding rate at maximum offered load may be less than the
+      maximum rate at which a device can be observed to successfully
+      forward traffic.  This will be the case when the ability of a
+      device to forward frames degenerates when offered traffic at
+      maximum load.
+
+      Maximum offered load MUST be cited when reporting forwarding rate
+      at maximum offered load.
+
+   Measurement units:
+
+      N-octet frames per second
+
+   Issues:
+
+   See Also:
+
+      maximum offered load (3.5.3)
+      forwarding rate (3.6.1)
+      maximum forwarding rate (3.6.3)
+
+3.6.3 Maximum forwarding rate (MFR)
+
+   Definition:
+
+      The highest forwarding rate of a DUT/SUT taken from an iterative
+      set of forwarding rate measurements.
+
+   Discussion:
+
+      The forwarding rate of a device may degenerate before maximum load
+      is reached.  The load applied to a device must be cited when
+      reporting maximum forwarding rate.
+
+
+
+
+
+
+
+
+Mandeville                   Informational                     [Page 16]
+
+RFC 2285                Benchmarking Terminology           February 1998
+
+
+      The following example illustrates how the terms relative to
+      loading and forwarding rates are meant to be used.  In particular
+      it shows how the distinction between forwarding rate at maximum
+      offered load (FRMOL) and maximum forwarding rate (MFR) can be used
+      to characterize a DUT/SUT.
+
+                    (A)                          (B)
+                Test Device                     DUT/SUT
+                Offered Load                Forwarding Rate
+                ------------                ---------------
+        (1)       14,880 fps - MOL              7,400 fps - FRMOL
+        (2)       13,880 fps                    8,472 fps
+        (3)       12,880 fps                   12,880 fps  - MFR
+
+   Measurement units:
+
+      N-octet frames per second
+
+   Issues:
+
+   See Also:
+
+      offered load (3.5.2)
+      forwarding rates (3.6.1)
+      forwarding rate at maximum load (3.6.2)
+
+3.7 Congestion control
+
+   This group of definitions applies to the behavior of a DUT/SUT when
+   congestion or contention is present.
+
+3.7.1 Backpressure
+
+   Definition:
+
+      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: bob.mandeville@eunet.fr
+
+
+
+
+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]
+