Network Working Group                                      R. Mandeville
INTERNET-DRAFT                             European Network Laboratories
Expiration Date: September 1997                           March
Expires in six months                                          July 1997

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

Status of this Document 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
   "work in progress.'' progress."

   To learn view the current status entire list of any Internet-Draft, current Internet-Drafts, please check
   the
``1id-abstracts.txt'' "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), nic.nordu.net
(Europe), or ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim). Coast).

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this document memo is unlimited. Please send comments to
bmwg@harvard.edu or to the editor.

Abstract

The purpose

Table of this draft 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. . . . . . . . . . . . . . . . . . . . . 3
         3.2.1 Unidirectional traffic. . . . . . . . . . . . . . . . . 4
         3.2.2 Bidirectional traffic . . . . . . . . . . . . . . . . . 5

      3.3 Traffic distribution . . . . . . . . . . . . . . . . . . . . 5
         3.3.1 One-to-one mapped traffic. .. . . . . . . . . . . . . . 5
         3.3.2 Partially meshed traffic. . . . . . . . . . . . . . . . 6
         3.3.3 Fully meshed traffic. . . . . . . . . . . . . . . . . . 6

      3.4 Bursts . . . . . . . .  . . .  . . . . . . . . . . . . . . . 8
         3.4.1 Burst . . . . . . . . . . . . . . . . . . . . . . . . . 8
         3.4.2 Burst size. . . . . . . . . . . . . . . . . . . . . . . 8
         3.4.3 Inter-burst gap (IBG) . . . . . . . . . . . . . . . . . 9

      3.5 Loads. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
         3.5.1 Intended load (Iload) . . . . . . . . . . . . . . . . . 9
         3.5.2 Offered load (Oload) . . . . . . . . . . . . . . . . . 10
         3.5.3 Maximum offered load (MOL) . . . . . . . . . . . . . . 10
         3.5.4 Overloading. . . . . . . . . . . . . . . . . . . . . . 11

      3.6 Forwarding rates. . . . . . . . . . . . . . . . . . . . . . 12
         3.6.1 Forwarding rate (FR) . . . . . . . . . . . . . . . . . 12
         3.6.2 Forwarding rate at maximum offered load (FRMOL). . . . 12
         3.6.3 Maximum forwarding rate (MFR). . . . . . . . . . . . . 13
      3.7 Congestion control. . . . . . . . . . . . . . . . . . . . . 14
         3.7.1 Backpressure . . . . . . . . . . . . . . . . . . . . . 14
         3.7.2 Forward pressure . . . . . . . . . . . . . . . . . . . 14
         3.7.3 Head of line blocking. . . . . . . . . . . . . . . . . 15
      3.8 Address handling. . . . . . . . . . . . . . . . . . . . . . 15
         3.8.1 Address caching capacity . . . . . . . . . . . . . . . 15
         3.8.2 Address learning rate. . . . . . . . . . . . . . . . . 16
         3.8.3 Flood count. . . . . . . . . . . . . . . . . . . . . . 16

      3.9 Errored frame filtering . . . . . . . . . . . . . . . . . . 17
         3.9.1 Errored frames . . . . . . . . . . . . . . . . . . . . 17

      3.10 Broadcasts . . . . . . . . . . . . . . . . . . . . . . . . 17
         3.10.1 Broadcast forwarding rate at maximum load . . . . . . 17
         3.10.2 Broadcast latency . . . . . . . . . . . . . . . . . . 18

4. Security Considerations. . . . . . . . . . . . . . . . . . . . . . 18
5. References. . . . . .  . . . . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19

1. Introduction

This document is intended to define and discuss benchmarking provide terminology for
the benchmarking of local area network (LAN) switching devices. It is meant to extend
extends the terminology already defined for benchmarking network
interconnect devices in RFCs 1242 and 1944 by the Benchmarking Methodology Working
Group (BMWG) of the Internet Engineering Task Force (IETF) and
prepare the way for a discussion on benchmarking methodology for
local area switches.

LAN switches are one of the principal sources of new bandwidth in
the local area. The multiplicity of products brought to market makes
it desirable to define a set of terms to be used when evaluating the
performance characteristics of local area switching devices. Well-
defined terminology will help in providing the user community with
complete, reliable and comparable data on LAN switches.

1. Introduction

The purpose of this draft is to discuss and define terminology for the
benchmarking of local area network switches.
Although it might be found useful to apply some of the terms defined
here to a broader range of network interconnect devices, this draft document
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. Term Existing definitions

RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" defines many of the terms that are used in this document.
The terminology document
should be consulted before attempting to make use of this document. RFC
1944 "Benchmarking Methodology for Network Interconnect Devices" defines a number
contains discussions of test
procedures which are directly applicable to switches. Since it
discusses a number of terms relevant to benchmarking switches it
should also be consulted.
A number of new terms applicable to benchmarking switches are
defined below using the format for definitions set out in Section 2 of
RFC 1242. RFCs 1242 and 1944 already contain discussions of
some of these terms. The new terms are defined in groups.

2. 1. Reminder of RFC 1242 definition format

Term to be defined. (e.g., Latency)

Definition:
The specific definition for the term.

Discussion:
A brief discussion about the term, its application
and any restrictions on measurement procedures.

Measurement units:
The units used to report measurements of this
term, if applicable.

Issues:
List of issues or conditions that effect this term.

See Also:
List of other terms that are relevant to the discussion benchmarking
of switching devices and should also be consulted.

For the sake of clarity and continuity this term.

3. Index RFC adopts the template for
definitions set out in Section 2 of terms defined

3.1 Devices
3.1.1 Device under test (DUT)
3.1.2 System under test (SUT)

3.2 Traffic patterns
3.2.1 Unidirectional traffic
3.2.2 Bidirectional traffic
3.2.3 Partially meshed traffic
3.2.4 Fully meshed traffic

3.3 Bursts
3.3.1 Burst
3.3.2 Burst size
3.3.3 Inter-burst gap (IBG)

3.4 Loads
3.4.1 Intended load
3.4.2 Offered load
3.4.3 Maximum offered load
3.4.4 Overloading

3.5 Forwarding rates
3.5.1 Forwarding rate at maximum load
3.5.2 Maximum forwarding rate

3.6 Congestion control
3.6.1 Backpressure
3.6.2 Forward pressure
3.6.3 Head RFC 1242. Definitions are indexed
and grouped together in sections for ease of line blocking

3.7 Address handling
3.7.1 Address caching capacity
3.7.2 Address learning rate
3.7.3 Flood count

3.8 Errored frame filtering
3.8.1 Errored frames

3.9 Broadcasts
3.9.1 Broadcast forwarding rate at maximum load
3.9.2 Broadcast latency reference.

3. Term definitions

3.1 Devices

This group of definitions applies to all types of networking devcies. devices.

3.1.1 Device under test (DUT)

Definition:
The network forwarding device to which stimuli stimulus is offered and response
measured.

Discussion:
A single stand-alone or modular unit generally equipped with its own
power supply.

Measurement units:
n/a

Issues:

See Also:
System
system under test (SUT) (3.1.2)

3.1.2 System Under Test (SUT).

Definition:
The collective set of network devices to which stimuli 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 decision-making process,
such as routers or switches; other devices may be passive such as CSU/DSUs. a
CSU/DSU. Regardless of constituent components, the system is treated as
a singular entity to which stimuli stimulus is offered and response measured.

Measurement units:
n/a

Issues:

See Also:
Device
device under test (DUT) (3.1.1)

3.2 Traffic patterns orientation

This group of definitions applies to the distribution traffic presented to the

interfaces of frames forwarded by any
DUT/SUT. a DUT/SUT and indicates whether the interfaces are
receiving only, transmitting only, or both receiving and transmitting.

3.2.1 Unidirectional traffic

Definition:

Single or multiple streams of frames forwarded in one direction only
from a set of input ports

Frames presented to a set of output ports. DUT/SUT such that the receiving and transmitting
interfaces are mutually exclusive.

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 ports of a device DUT/SUT to measure throughput. Unidirectional traffic is also
appropriate for:
- the

   -the measurement of the minimum inter-frame gap
- the
   -the creation of many-to-one or one-to-many port interface overload
- the
   -the detection of head of line blocking
- the
   -the measurement of throughput when congestion control
mechanisms are active

Unidirectional traffic forwarding rates and throughput when congestion
    control mechanisms are active.

When considering traffic patterns it is useful to distinguish traffic
orientation and traffic distribution. In the case of unidirectional
traffic, for example, traffic is orientated in a single direction
between mutually exclusive sets of source and destination interfaces
of a DUT/SUT. Such traffic, however, can be used to load the ports of a DUT/SUT distributed between
interfaces in different ways. For example unidirectional When traffic can be is sent to two or more input ports
interfaces from an external source and forwarded by the DUT/SUT to
a single output port (n-to-1) or such interface traffic orientation is unidirectional and
traffic distribution between interfaces is many-to-one. Traffic can
also be sent to a single input port interface and forwarded by the DUT/SUT
to two or more output ports (1-to-n). interfaces to achieve a one-to-many distribution
of traffic between interfaces.

Such patterns 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 is active.

When a DUT/SUT is equipped with ports interfaces running at different media
rates the number of input streams interfaces required to load or overload an
output port interface or ports 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)
one-to-one mapped traffic (3.3.1)
partially meshed traffic (3.2.3) (3.3.2)
fully meshed traffic (3.2.4) (3.3.3)

3.2.2 Bidirectional traffic

Definition:
Two or more streams of frames forwarded in opposite directions
between two or more ports of
Frames presented to a DUT/SUT. DUT/SUT such that 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. Bidirectional
traffic MUST be offered when measuring throughput on full duplex ports
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.2.3) (3.3.2)
fully meshed traffic (3.2.4)

3.2.3 Partially meshed traffic

Definition:
Streams (3.3.3)

3.3 Traffic distribution

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

3.3.1 One-to-one mapped traffic

Definition:
Frames offered to a set of single input ports interface and destined to a set of single
output ports interface of a DUT/SUT with a 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 to many, many to source interface and one or many destination

interface of a DUT/SUT. One-to-one mapped traffic distribution extends
to many mapping 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 forwarded between mutually exclusive sets of input ports to and output ports.
interfaces of a DUT/SUT.

Discussion:
This definition follows from the discussions in sections 14 and 16 of
RFC 1944 on bidirectional traffic and multi-port testing 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. Meshed traffic can be
unidirectional or bidirectional.

Measurement units:
n/a

Issues:
half duplex / full duplex

See Also:
unidrectional
unidirectional traffic (3.2.1)
bidirectional traffic (3.2.2)
one-to-one mapped traffic (3.3.1)
fully meshed traffic (3.2.4)
bursts (3.3)

3.2.4 (3.3.3)
burst (3.4.1)

3.3.3 Fully meshed traffic

Definition:
Streams of frames
Frames switched simultaneously between all of a designated number of ports

interfaces of a device such that each of the ports interfacess under test
will both send forward frames to and receive frames from all of the other ports
interfaces under test.

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

It should be noted that bidirectional multiport multi-port traffic can load
backbone connections linking together two switching devices more
than meshed traffic.
It should be noted that bidirectional

Bidirectional meshed traffic on half duplex
ports interfaces is inherently
bursty since ports 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 and or output buffers,
buffer allocation mechanisms, aggregate switching capacity, processing
speed or medium access control.

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

Issues:
half duplex / full duplex

See Also:
unidrectional
unidirectional traffic (3.2.1)
bidirectional traffic (3.2.2)
one-to-one mapped traffic (3.3.1)
partially meshed traffic (3.2.4)
bursts (3.3)

3.3 (3.3.2)
burst (3.4.1)

3.4 Bursts

This group of definitions applies to the intervals defining traffic forwarded by between frames or
groups of frames offered to the DUT/SUT.

3.3.1

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.3.2) (3.4.2)
inter-burst gap (IBG) (3.2.3)
3.2.2 (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 streams traffic
there is no theoretical limit to burst length. When traffic is
bidirectional or meshed bursts on half duplex media are finite since
ports
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.3.1) (3.4.1)
inter-burst gap (IBG) (3.2.3)

3.2.3 (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 streams of traffic are inherently bursty since ports 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 rate of
transmission.

Measurement units:
nanoseconds
microseconds
milliseconds
seconds

Issues:

See Also:
burst (3.3.1) (3.4.1)
burst size (3.2.2)

3.4 (3.4.2)

3.5 Loads

This group of definitions applies to the rates that at which traffic is
offered to any DUT/SUT.

3.4.1

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 port interface or
ports.
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:

See Also:
offered load (3.4.2)

3.4.2 (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 port interface or ports. interfaces.

Discussion:
The load which an external device can be observed to apply to a DUT/SUT
may be less than the load the external device attempts to apply due to
collisions or the action of congestion control mechanisms. 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 a port 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 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:

intended load (3.4.1)

3.4.3 (3.5.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 port interface
or
ports. 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.4.2)

3.4.4 (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 port or ports interfaces required to overload one or more output ports
interfaces of a DUT/SUT will vary according to the media rates of the ports
interfaces involved. An external source can also overload a port an interface
by transmitting frames below the minimum inter-frame gap. This can
serve to determine whether a device respects the minimum inter-frame
gap.

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 100
N-octet frames per second

Issues:

See Also:
offered load (3.4.2)

3.5 (3.5.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.5.1

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 port 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,
which must only be sampled rate refers to
the number of frames per second observed on the output side of the ports
interface under
test, test and MUST be reported in relation to the offered
load. Forwarding rate can be measured for unidirectional, bidirectional or meshed with different traffic
orientations and should be sampled in fixed time intervals of one second. If
longer or shorter intervals are used they should be cited when
reporting a device's forwarding rate. 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.4.2) (3.5.2)
forwarding rate at maximum offered load (3.5.2) (3.6.2)
maximum forwarding rate (3.5.3)

3.5.2 (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 port 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
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.4.3) (3.5.3)
forwarding rate (3.5.1) (3.6.1)
maximum forwarding rate (3.5.3)

3.5.3 (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)
               Test Device           DUT/SUT
               Offered Rate      Forwarding Rate
               ------------      ---------------
            1.  14,880 fps           7,400 fps
            2.  13,880 fps           8,472 fps
            3.  12,880 fps          12,880 fps

  Column A      - Oload
  Column B      - FR
  Row 1, Col A  - MOL
  Row 1, Col B  - FRMOL
  Row 3, Col B  - MFR

Measurement units:
N-octet frames per second

Issues:

See Also:
offered load (3.4.2) (3.5.2)
forwarding rates (3.5.1) (3.6.1)
forwarding rate at maximum load (3.5.2)

3.6 (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.6.1

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

Discussion:
Some switches send jam signals, for example preamble bits, back to
traffic sources when their transmit amd/or 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 ports. interfaces.

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

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

Issues:
jamming not explicitly described in standards

See Also:
forward pressure (3.6.2)

3.6.2 (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 backoff back-off algorithms in order
to force access to the medium when contention occurs. It should be
noted that the backoff 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.

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

Issues:
truncated binary exponential backoff back-off algorithm

See also:
backpressure (3.6.1)

3.6.3 (3.7.1)

3.7.3 Head of line blocking

Definition:
Frame loss observed on an uncongested output port interface whenever frames
are received from an input port interface which is also attempting to
forward frames to a congested output port. interface.

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

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

Issues:
input
interface.

Issues:input buffers

See Also:
unidirectional traffic (3.2.1)

3.7

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.

3.7.1

3.8.1 Address caching capacity

Definition:
The number of MAC addresses per n ports, 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 ports, interfaces, per module and per
chassis before a DUT/SUT begins flooding frames.

Measurement units:
number of MAC addresses per n ports, interfaces, per module and/or per chassis

Issues:

See Also:
Address learning rate (3.7.2)

3.7.2 (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:

See Also: address caching capacity (3.7.1)

3.7.3 (3.8.1)

3.8.3 Flood count

Definition:
Frames forwarded to ports 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.7.1)

3.8 (3.8.1)

3.9 Errored frame filtering

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

3.8.1

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 ports
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 units:n/a

Issues:

See Also:

3.9

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

3.9.1

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 ports interfaces located within a broadcast domain
in response to a specified offered load.

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 ports interfaces on the same card,
ports interfaces
on different cards in the same chassis and ports 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.5 above.

Measurement 3.6 above.Measurement units:
N-octet frames per second

Issues:

See Also:
forwarding rate at maximum load (3.5.2) (3.6.2)
maximum forwarding rate (3.5.3) (3.6.3)
broadcast latency (3.9.2)

3.9.2 (3.10.2)

3.10.2 Broadcast latency

Definition:
The time required by a DUT/SUT to forward a broadcast frame to each port
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 ports
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 ports interfaces on the same
card, ports interfaces on different cards in the same chassis and ports interfaces
on different chassis linked together over backbone connections.

Measurement units:
nanoseconds
microseconds
milliseconds
seconds

Issues:

See Also:
broadcast forwarding rate (3.9.1) (3.10.1)

4. Security Considerations

This document raises no security issues.

5. References:

1. RFC 1242 "Benchmarking Terminology for Network Interconnect Devices"
2. RFC 1944 "Benchmarking Methodology for Network Interconnect Devices"

5.

6. Acknowledgments

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

The editor
Bob Mandeville

5. Editor's

7. Author's Address

Robert Mandeville
ENL (European
European Network Laboratories)
35, rue Beaubourg
75003 Paris Laboratories (ENL)
6, Parc Ariane "Le Mercure"
Boulevard des Chenes
78284 Guyancourt
France
mobile phone: +33 6 07 47 67 10

phone: +33 + 33 1 39 44 12 05 or mobile phone + 33 6 07 47 67 10
fax: + 33 1 39 44 12 06
email: bob.mandeville@eunet.fr