[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 2285

Network Working Group                                      R. Mandeville
INTERNET-DRAFT                             European Network Laboratories
Expiration Date: January 1998                                August 1997

           Benchmarking Terminology for LAN Switching Devices
                  <draft-ietf-bmwg-lanswitch-06.txt>

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

   To view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
   Coast), or ftp.isi.edu (US West Coast).

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2

   2. Existing definitions . . . . . . . . . . . . . . . . . . . . . . 3

   3. Term definitions . . . . . . . . . . . . . . . . . . . . . . . . 3

      3.1 Devices  . . . . . . . . . . . . . . . . . . . . . . . . . . 3

         3.1.1 Device under test (DUT) . . . . . . . . . . . . . . . . 3
         3.1.2 System under test (SUT) . . . . . . . . . . . . . . . . 4

      3.2 Traffic orientation  . . . . . . . . . . . . . . . . . . . . 4

         3.2.1 Unidirectional traffic  . . . . . . . . . . . . . . . . 4
         3.2.2 Bidirectional traffic . . . . . . . . . . . . . . . . . 6

      3.3 Traffic distribution . . . . . . . . . . . . . . . . . . . . 7

         3.3.1 One-to-one mapped traffic . . . . . . . . . . . . . . . 7
         3.3.2 Partially meshed traffic  . . . . . . . . . . . . . . . 7
         3.3.3 Fully meshed traffic  . . . . . . . . . . . . . . . . . 8

      3.4 Bursts  . . . . . . . . . . . . . . . . . . . . . . . . . . 10

         3.4.1 Burst  . . . . . . . . . . . . . . . . . . . . . . . . 10
         3.4.2 Burst size . . . . . . . . . . . . . . . . . . . . . . 11
         3.4.3 Inter-burst gap (IBG)  . . . . . . . . . . . . . . . . 11

Mandeville                                                      [Page 1]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      3.5 Loads . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

         3.5.1 Intended load (Iload)  . . . . . . . . . . . . . . . . 12
         3.5.2 Offered load (Oload) . . . . . . . . . . . . . . . . . 13
         3.5.3 Maximum offered load (MOL) . . . . . . . . . . . . . . 14
         3.5.4 Overloading  . . . . . . . . . . . . . . . . . . . . . 14

      3.6 Forwarding rates  . . . . . . . . . . . . . . . . . . . . . 15

         3.6.1 Forwarding rate (FR) . . . . . . . . . . . . . . . . . 16
         3.6.2 Forwarding rate at maximum offered load (FRMOL). . . . 16
         3.6.3 Maximum forwarding rate (MFR). . . . . . . . . . . . . 17

      3.7 Congestion control  . . . . . . . . . . . . . . . . . . . . 18

         3.7.1 Backpressure . . . . . . . . . . . . . . . . . . . . . 18
         3.7.2 Forward pressure . . . . . . . . . . . . . . . . . . . 19
         3.7.3 Head of line blocking  . . . . . . . . . . . . . . . . 20

      3.8 Address handling  . . . . . . . . . . . . . . . . . . . . . 20

         3.8.1 Address caching capacity . . . . . . . . . . . . . . . 21
         3.8.2 Address learning rate  . . . . . . . . . . . . . . . . 21
         3.8.3 Flood count  . . . . . . . . . . . . . . . . . . . . . 22

      3.9 Errored frame filtering . . . . . . . . . . . . . . . . . . 22

         3.9.1 Errored frames . . . . . . . . . . . . . . . . . . . . 22

      3.10 Broadcasts . . . . . . . . . . . . . . . . . . . . . . . . 23

         3.10.1 Broadcast forwarding rate at maximum load . . . . . . 23
         3.10.2 Broadcast latency . . . . . . . . . . . . . . . . . . 24

   4. Security Considerations . . . . . . . . . . . . . . . . . . . . 24

   5. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 25

   6. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 25

   7. Author's Address  . . . . . . . . . . . . . . . . . . . . . . . 25


1. Introduction

   This Request for Comments (RFC) 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.




Mandeville                                                      [Page 2]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


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


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


Mandeville                                                      [Page 3]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      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.

      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.



Mandeville                                                      [Page 4]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      Discussion:

         This definition conforms to the discussion in section 16 of RFC
         1944 on multi-port testing 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, 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 is 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






Mandeville                                                      [Page 5]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      Measurement units:

         n/a

      See Also:

         bidirectional traffic (3.2.2)
         one-to-one mapped 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 each of the interfaces
         of the DUT/SUT both receive and transmit.

      Discussion:

         This definition conforms to the discussions in sections 14 and
         16 of RFC 1944 on bidirectional traffic and multi-port testing.

         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 throughput
         on 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)
         one-to-one mapped traffic (3.3.1)
         partially meshed traffic (3.3.2)
         fully meshed traffic (3.3.3)






Mandeville                                                      [Page 6]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


   3.3 Traffic distribution

   This group of definitions applies to the distribution of frames
   forwarded by any DUT/SUT.


      3.3.1 One-to-one mapped 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 one-to-one mapped traffic
         distribution frames are forwarded between one source interface
         and one destination interface of a DUT/SUT.  One-to-one mapped
         traffic distribution extends to multiple distinct pairs of
         source and destination interfaces.

      Measurement units:

         n/a

      Issues:

         half duplex / full duplex

      See Also:

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







Mandeville                                                      [Page 7]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      Discussion:
         This definition follows from the discussions in sections 14 and
         16 of RFC 1944 on bidirectional traffic and 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.

         When partially meshed traffic is distributed in a one-to-many
         or many-to-one mapping of receiving to transmitting interfaces
         of a DUT/SUT traffic orientation will be unidirectional.  When
         traffic is partially meshed and distributed in a many-to-many
         mapping of receiving to transmitting ports which are mutually
         exclusive traffic orientation will be bidirectional.

      Measurement units:
         n/a

      Issues:

         half duplex / full duplex

      See Also:

         unidirectional traffic (3.2.1)
         bidirectional traffic (3.2.2)
         one-to-one mapped traffic (3.3.1)
         fully meshed traffic (3.3.3)
         burst (3.4.1)


      3.3.3 Fully meshed traffic

      Definition:

         Frames switched simultaneously between all of a designated
         number of interfaces of a DUT/SUT such that each of the
         interfaces under test will both forward frames to and receive
         frames from all of the other interfaces under test.

      Discussion:

         As with bidirectional multi-port traffic, meshed traffic
         exercises both the transmission and reception sides of the
         interfaces of a switching device.  Since interfaces are not
         divided into two groups every interface forwards frames to and
         receives frames from every other interface.  The total number
         of individual input/output interface pairs when traffic is
         meshed over n switched interfaces equals n x (n - 1).  This
         compares with n x (n / 2) such interface pairs in a
         bidirectional multi-port test.


Mandeville                                                      [Page 8]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


         It should be noted that bidirectional multi-port traffic can
         load backbone connections linking together two switching
         devices more than fully meshed traffic.  In a bidirectional
         multiport test each one of two devices or systems connected
         over a backbone connection can be configured to forward the
         totality of the frames they receive to the devices or systems
         placed on the opposite side of the backbone connection.  All
         frames generated during such a test will traverse the backbone
         connection.  Fully meshed traffic requires at least some of the
         frames received on the interfaces of each one of the devices or
         systems under test to be forwarded locally, that is to the
         interfaces of the receiving devices themselves.  Such frames
         will not traverse the backbone connection.

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

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

      Measurement units:

         n/a







Mandeville                                                      [Page 9]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      Issues:

         half duplex / full duplex

      See Also:

         unidirectional traffic (3.2.1)
         bidirectional traffic (3.2.2)
         one-to-one mapped 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 inter-frame
         gap allowed by the medium.

      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:

      See Also:

         burst size (3.4.2)
         inter-burst gap (IBG) (3.4.3)









Mandeville                                                     [Page 10]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      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.

         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.






Mandeville                                                     [Page 11]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      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

      Measurement units:

         bits per second
         N-octets per second
         (N-octets per second / media_maximum-octets per second) x 100

      Issues:





Mandeville                                                     [Page 12]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      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 the forwarding rate of a
         DUT/SUT.

         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

      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)


Mandeville                                                     [Page 13]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      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:

      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.




Mandeville                                                     [Page 14]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


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

         Overloading can be achieved with unidirectional, bidirectional
         and meshed traffic.

      Measurement units:

         N-octets per second
         (N-octets per second / media_maximum-octets per second) x 100N-
         octet
         frames per second

      Issues:

      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.





Mandeville                                                     [Page 15]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      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 an
         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)


      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.






Mandeville                                                     [Page 16]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


         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.

         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)            Column A      - Oload
            Test Device           DUT/SUT          Column B      - FR
            Offered Rate      Forwarding Rate
            ------------      ---------------
         1.   14,880 fps           7,400 fps       Row 1, Col A  - MOL
         2.   13,880 fps           8,472 fps       Row 1, Col B  - FRMOL
         3.   12,880 fps          12,880 fps       Row 3, Col B  - MFR


      Measurement units:

         N-octet frames per second



Mandeville                                                     [Page 17]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      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.

         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



Mandeville                                                     [Page 18]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      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.

         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




Mandeville                                                     [Page 19]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      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:

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

      Issues:

         input buffers

      See Also:

         unidirectional traffic (3.2.1)


   3.8 Address handling

   This group of definitions applies to the process of address
   resolution which enables a DUT/SUT to forward frames to the correct
   destination.








Mandeville                                                     [Page 20]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      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 DUT/SUT.  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, per module and/or per
         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
         Before starting to flood or drop frames.

      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 per second with each successive frame sent to the switch
         containing a different source address.

      Issues:





Mandeville                                                     [Page 21]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      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.


      3.9.1 Errored frames

      Definition:

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








Mandeville                                                     [Page 22]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


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




Mandeville                                                     [Page 23]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      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 3.8 of
         RFC 1242. It is useful to determine broadcast latency for
         frames forwarded between interfaces on the same card,
         interfaces on different cards in the same chassis and
         interfaces on different chassis linked together over backbone
         connections.

      Measurement units:

         nanoseconds
         microseconds
         milliseconds
         seconds

      Issues:

      See Also:

         broadcast forwarding rate (3.10.1)


   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.






Mandeville                                                     [Page 24]


INTERNET-DRAFT       Benchmarking Switching Devices          August 1997


      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. RFC 1242 "Benchmarking Terminology for Network Interconnect
         Devices"
      2. RFC 1944 "Benchmarking Methodology for Network Interconnect
         Devices"


   6. Acknowledgments

      A special thanks goes to the IETF BenchMarking Methodology
      WorkGroup for the many suggestions it collectively made to help
      complete this RFC.  Kevin Dubray (Bay Networks), Jean-Christophe
      Bestaux (ENL), Ajay Shah (WG), Henry Hamon (Netcom Systems), Stan
      Kopek (3Com) and Doug Ruby (Prominet) provided valuable input at
      various stages of this project.


   7. Author's Address

      Robert Mandeville
      European Network Laboratories (ENL)
      33, Boulevard Henri IV
      75004 Paris
      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                                                     [Page 25]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/