draft-ietf-bmwg-lanswitch-05.txt   draft-ietf-bmwg-lanswitch-06.txt 
Network Working Group R. Mandeville Network Working Group R. Mandeville
INTERNET-DRAFT European Network Laboratories INTERNET-DRAFT European Network Laboratories
Expires in six months July 1997 Expiration Date: January 1998 August 1997
Benchmarking Terminology for LAN Switching Devices Benchmarking Terminology for LAN Switching Devices
<draft-ietf-bmwg-lanswitch-05.txt> <draft-ietf-bmwg-lanswitch-06.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast). Coast), or ftp.isi.edu (US West Coast).
This memo provides information for the Internet community. This memo This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of does not specify an Internet standard of any kind. Distribution of
this memo is unlimited. this memo is unlimited.
Table of Contents Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Existing definitions. . . . . . . . . . . . . . . . . . . . . . . . 2
3. Term definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Existing definitions . . . . . . . . . . . . . . . . . . . . . . 3
3. Term definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Devices .. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1 Device under test (DUT) . . . . . . . . . . . . . . . . 3 3.1.1 Device under test (DUT) . . . . . . . . . . . . . . . . 3
3.1.2 System under test (SUT). . . . . . . . . . . . . . . . 3 3.1.2 System under test (SUT) . . . . . . . . . . . . . . . . 4
3.2 Traffic orientation. . . . . . . . . . . . . . . . . . . . . 3 3.2 Traffic orientation . . . . . . . . . . . . . . . . . . . . 4
3.2.1 Unidirectional traffic. . . . . . . . . . . . . . . . . 4
3.2.2 Bidirectional traffic . . . . . . . . . . . . . . . . . 5
3.3 Traffic distribution . . . . . . . . . . . . . . . . . . . . 5 3.2.1 Unidirectional traffic . . . . . . . . . . . . . . . . 4
3.3.1 One-to-one mapped traffic. .. . . . . . . . . . . . . . 5 3.2.2 Bidirectional traffic . . . . . . . . . . . . . . . . . 6
3.3.2 Partially meshed traffic. . . . . . . . . . . . . . . . 6
3.3.3 Fully meshed traffic. . . . . . . . . . . . . . . . . . 6
3.4 Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Traffic distribution . . . . . . . . . . . . . . . . . . . . 7
3.4.1 Burst . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.2 Burst size. . . . . . . . . . . . . . . . . . . . . . . 8
3.4.3 Inter-burst gap (IBG) . . . . . . . . . . . . . . . . . 9
3.5 Loads. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1 One-to-one mapped traffic . . . . . . . . . . . . . . . 7
3.5.1 Intended load (Iload) . . . . . . . . . . . . . . . . . 9 3.3.2 Partially meshed traffic . . . . . . . . . . . . . . . 7
3.5.2 Offered load (Oload) . . . . . . . . . . . . . . . . . 10 3.3.3 Fully meshed traffic . . . . . . . . . . . . . . . . . 8
3.5.3 Maximum offered load (MOL) . . . . . . . . . . . . . . 10
3.5.4 Overloading. . . . . . . . . . . . . . . . . . . . . . 11
3.6 Forwarding rates. . . . . . . . . . . . . . . . . . . . . . 12 3.4 Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . 10
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.4.1 Burst . . . . . . . . . . . . . . . . . . . . . . . . 10
3.9.1 Errored frames . . . . . . . . . . . . . . . . . . . . 17 3.4.2 Burst size . . . . . . . . . . . . . . . . . . . . . . 11
3.4.3 Inter-burst gap (IBG) . . . . . . . . . . . . . . . . 11
3.5 Loads . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.10 Broadcasts . . . . . . . . . . . . . . . . . . . . . . . . 17 3.5.1 Intended load (Iload) . . . . . . . . . . . . . . . . 12
3.10.1 Broadcast forwarding rate at maximum load . . . . . . 17 3.5.2 Offered load (Oload) . . . . . . . . . . . . . . . . . 13
3.10.2 Broadcast latency . . . . . . . . . . . . . . . . . . 18 3.5.3 Maximum offered load (MOL) . . . . . . . . . . . . . . 14
3.5.4 Overloading . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations. . . . . . . . . . . . . . . . . . . . . . 18 3.6 Forwarding rates . . . . . . . . . . . . . . . . . . . . . 15
5. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.6.1 Forwarding rate (FR) . . . . . . . . . . . . . . . . . 16
7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 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 1. Introduction
This document is intended to provide terminology for This Request for Comments (RFC) is intended to provide terminology
the benchmarking of local area network (LAN) switching devices. It for the benchmarking of local area network (LAN) switching devices.
extends the terminology already defined for benchmarking network It extends the terminology already defined for benchmarking network
interconnect devices in RFCs 1242 and 1944 to switching devices. interconnect devices in RFCs 1242 and 1944 to switching devices.
Although it might be found useful to apply some of the terms defined Although it might be found useful to apply some of the terms defined
here to a broader range of network interconnect devices, this document here to a broader range of network interconnect devices, this RFC
primarily deals with devices which switch frames at the Medium Access primarily deals with devices which switch frames at the Medium
Control (MAC) layer. It defines terms in relation to the traffic put to Access Control (MAC) layer. It defines terms in relation to the
use when benchmarking switching devices, forwarding performance, traffic put to use when benchmarking switching devices, forwarding
latency, address handling and filtering. performance, latency, address handling and filtering.
2. Existing definitions 2. Existing definitions
RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" RFC 1242 "Benchmarking Terminology for Network Interconnect Devices"
should be consulted before attempting to make use of this document. RFC should be consulted before attempting to make use of this document.
1944 "Benchmarking Methodology for Network Interconnect Devices" RFC 1944 "Benchmarking Methodology for Network Interconnect Devices"
contains discussions of a number of terms relevant to the benchmarking contains discussions of a number of terms relevant to the
of switching devices and should also be consulted. benchmarking of switching devices and should also be consulted.
For the sake of clarity and continuity this RFC adopts the template for For the sake of clarity and continuity this RFC adopts the template
definitions set out in Section 2 of RFC 1242. Definitions are indexed for definitions set out in Section 2 of RFC 1242. Definitions are
and grouped together in sections for ease of reference. 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. Term definitions
3.1 Devices 3.1 Devices
This group of definitions applies to all types of networking devices. This group of definitions applies to all types of networking
devices.
3.1.1 Device under test (DUT) 3.1.1 Device under test (DUT)
Definition: Definition:
The network forwarding device to which stimulus is offered and response
measured. The network forwarding device to which stimulus is offered and
response measured.
Discussion: Discussion:
A single stand-alone or modular unit generally equipped with its own
power supply. 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: Measurement units:
n/a
n/a
Issues: Issues:
See Also: See Also:
system under test (SUT) (3.1.2) system under test (SUT) (3.1.2)
3.1.2 System Under Test (SUT). 3.1.2 System Under Test (SUT)
Definition: Definition:
The collective set of network devices to which stimulus is offered as a
single entity and response measured. The collective set of network devices to which stimulus is
offered as a single entity and response measured.
Discussion: 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, A system under test may be comprised of a variety of networking
such as routers or switches; other devices may be passive such as a devices. Some devices may be active in the forwarding decision-
CSU/DSU. Regardless of constituent components, the system is treated as making process, such as routers or switches; other devices may
a singular entity to which stimulus is offered and response measured. 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: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
device under test (DUT) (3.1.1) device under test (DUT) (3.1.1)
3.2 Traffic orientation 3.2 Traffic orientation
This group of definitions applies to the traffic presented to the This group of definitions applies to the traffic presented to the
interfaces of a DUT/SUT and indicates whether the interfaces are interfaces of a DUT/SUT and indicates whether the interfaces are
receiving only, transmitting only, or both receiving and transmitting. receiving only, transmitting only, or both receiving and
transmitting.
3.2.1 Unidirectional traffic 3.2.1 Unidirectional traffic
Definition: Definition:
Frames presented to a DUT/SUT such that the receiving and transmitting When all frames presented to the input interfaces of a DUT/SUT
interfaces are mutually exclusive. are addressed to output interfaces which do not themselves
receive any frames.
Discussion: Discussion:
This definition conforms to the discussion in section 16 of RFC 1944 on
multi-port testing which describes how unidirectional traffic can be This definition conforms to the discussion in section 16 of RFC
offered to a DUT/SUT to measure throughput. Unidirectional traffic is also 1944 on multi-port testing which describes how unidirectional
appropriate for: 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 measurement of the minimum inter-frame gap
-the creation of many-to-one or one-to-many interface overload -the creation of many-to-one or one-to-many interface overload
-the detection of head of line blocking -the detection of head of line blocking
-the measurement of forwarding rates and throughput when congestion -the measurement of forwarding rates and throughput when
control mechanisms are active. congestion control mechanisms are active.
When considering traffic patterns it is useful to distinguish traffic When a tester offers unidirectional traffic to a DUT/SUT
orientation and traffic distribution. In the case of unidirectional reception and transmission are handled by different interfaces
traffic, for example, traffic is orientated in a single direction or sets of interfaces of the DUT/SUT. All frames received from
between mutually exclusive sets of source and destination interfaces the tester by the DUT/SUT are transmitted back to the tester
of a DUT/SUT. Such traffic, however, can be distributed between from interfaces which do not themselves receive any frames.
interfaces in different ways. When traffic is sent to two or more
interfaces from an external source and forwarded by the DUT/SUT to
a single output interface traffic orientation is unidirectional and
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 between interfaces.
Such traffic distributions can also be combined to test for head of It is useful to distinguish traffic orientation and traffic
line blocking or to measure forwarding rates and throughput when distribution when considering traffic patterns used in device
congestion control is active. 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.
When a DUT/SUT is equipped with interfaces running at different media Such traffic distributions can also be combined to test for
rates the number of input interfaces required to load or overload an head of line blocking or to measure forwarding rates and
output interface or interfaces will vary. throughput when congestion control is active.
It should be noted that measurement of the minimum inter-frame gap When a DUT/SUT is equipped with interfaces running at different
serves to detect violations of the IEEE 802.3 standard. 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: Issues:
half duplex / full duplex
half duplex / full duplex
Measurement units: Measurement units:
n/a n/a
See Also: See Also:
bidirectional traffic (3.2.2) bidirectional traffic (3.2.2)
one-to-one mapped traffic (3.3.1) one-to-one mapped traffic (3.3.1)
partially meshed traffic (3.3.2) partially meshed traffic (3.3.2)
fully meshed traffic (3.3.3) fully meshed traffic (3.3.3)
congestion control (3.7)
head of line blocking (3.7.3)
3.2.2 Bidirectional traffic 3.2.2 Bidirectional traffic
Definition: Definition:
Frames presented to a DUT/SUT such that the interfaces of the DUT/SUT both
receive and transmit. Frames presented to a DUT/SUT such that each of the interfaces
of the DUT/SUT both receive and transmit.
Discussion: Discussion:
This definition conforms to the discussions in sections 14 and 16 of
RFC 1944 on bidirectional traffic and multi-port testing. Bidirectional This definition conforms to the discussions in sections 14 and
traffic MUST be offered when measuring throughput on full duplex 16 of RFC 1944 on bidirectional traffic and multi-port testing.
interfaces of a switching device.
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: Issues:
truncated binary exponential back-off algorithm truncated binary exponential back-off algorithm
Measurement units: Measurement units:
n/a n/a
See Also: See Also:
unidirectional traffic (3.2.1) unidirectional traffic (3.2.1)
one-to-one mapped traffic (3.3.1) one-to-one mapped traffic (3.3.1)
partially meshed traffic (3.3.2) partially meshed traffic (3.3.2)
fully meshed traffic (3.3.3) fully meshed traffic (3.3.3)
3.3 Traffic distribution 3.3 Traffic distribution
This group of definitions applies to the distribution of frames This group of definitions applies to the distribution of frames
forwarded by any DUT/SUT. forwarded by any DUT/SUT.
3.3.1 One-to-one mapped traffic 3.3.1 One-to-one mapped traffic
Definition: Definition:
Frames offered to a single input interface and destined to a single Frames offered to a single input interface and addressed to a
output interface of a DUT/SUT where input and output interfaces are single output interface of a DUT/SUT where input and output
grouped in mutually exclusive pairs. interfaces are grouped in mutually exclusive pairs.
Discussion: 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 In the simplest instance of one-to-one mapped traffic
to multiple distinct pairs of source and destination interfaces. 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: Measurement units:
n/a n/a
Issues: Issues:
half duplex / full duplex half duplex / full duplex
See Also: See Also:
unidrectional traffic (3.2.1) unidrectional traffic (3.2.1)
bidirectional traffic (3.2.2) bidirectional traffic (3.2.2)
partially meshed traffic (3.3.2.) partially meshed traffic (3.3.2.)
fully meshed traffic (3.3.3) fully meshed traffic (3.3.3)
burst (3.4.1) burst (3.4.1)
3.3.2 Partially meshed traffic 3.3.2 Partially meshed traffic
Definition: Definition:
Frames forwarded between mutually exclusive sets of input and output
interfaces of a DUT/SUT. 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: Discussion:
This definition follows from the discussions in sections 14 and 16 of This definition follows from the discussions in sections 14 and
RFC 1944 on bidirectional traffic and multi-port testing. Partially 16 of RFC 1944 on bidirectional traffic and multi-port testing.
meshed traffic allows for one-to-many, many-to-one or many-to-many Partially meshed traffic allows for one-to-many, many-to-one or
mappings of input to output interfaces and readily extends to many-to-many mappings of input to output interfaces and readily
configurations with multiple switching devices linked together over extends to configurations with multiple switching devices
backbone connections. 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: Measurement units:
n/a n/a
Issues: Issues:
half duplex / full duplex half duplex / full duplex
See Also: See Also:
unidirectional traffic (3.2.1) unidirectional traffic (3.2.1)
bidirectional traffic (3.2.2) bidirectional traffic (3.2.2)
one-to-one mapped traffic (3.3.1) one-to-one mapped traffic (3.3.1)
fully meshed traffic (3.3.3) fully meshed traffic (3.3.3)
burst (3.4.1) burst (3.4.1)
3.3.3 Fully meshed traffic 3.3.3 Fully meshed traffic
Definition: Definition:
Frames switched simultaneously between all of a designated number of
interfaces of a device such that each of the interfacess under test Frames switched simultaneously between all of a designated
will both forward frames to and receive frames from all of the other number of interfaces of a DUT/SUT such that each of the
interfaces under test. interfaces under test will both forward frames to and receive
frames from all of the other interfaces under test.
Discussion: Discussion:
As with bidirectional multi-port traffic, meshed traffic exercises both
the transmission and reception sides of the interfaces of a switching As with bidirectional multi-port traffic, meshed traffic
device. Since interfaces are not divided into two groups every exercises both the transmission and reception sides of the
interface forwards frames to and receives frames from every other interfaces of a switching device. Since interfaces are not
interface. The total number of individual input/output interface divided into two groups every interface forwards frames to and
pairs when traffic is meshed over n switched interfaces equals receives frames from every other interface. The total number
n x (n - 1). This compares with n x (n / 2) such interface pairs in a 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. bidirectional multi-port test.
It should be noted that bidirectional multi-port traffic can load It should be noted that bidirectional multi-port traffic can
backbone connections linking together two switching devices more load backbone connections linking together two switching
than meshed traffic. 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 Bidirectional meshed traffic on half duplex interfaces is
bursty since interfaces must interrupt transmission whenever they inherently bursty since interfaces must interrupt transmission
receive frames. This kind of bursty meshed traffic is characteristic whenever they receive frames. This kind of bursty meshed
of real network traffic and can be advantageously used to diagnose a traffic is characteristic of real network traffic and can be
DUT/SUT by exercising many of its component parts simultaneously. advantageously used to diagnose a DUT/SUT by exercising many of
Additional inspection may be warranted to correlate the frame its component parts simultaneously. Additional inspection may
forwarding capacity of a DUT/SUT when offered meshed traffic and be warranted to correlate the frame forwarding capacity of a
the behavior of individual elements such as input or output buffers, DUT/SUT when offered meshed traffic and the behavior of
buffer allocation mechanisms, aggregate switching capacity, processing individual elements such as input or output buffers,
speed or medium access control. 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 The analysis of forwarding rate measurements presents a
have to be considered. These include frame size, the number of frames challenge when offering bidirectional or fully meshed traffic
within bursts, the interval between bursts as well as the distribution since the rate at which the tester can be observed to transmit
of load between incoming and outgoing traffic. Terms related to bursts frames to the DUT/SUT may be smaller than the rate at which it
are defined in section 3.3 below. 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: Measurement units:
n/a
n/a
Issues: Issues:
half duplex / full duplex half duplex / full duplex
See Also: See Also:
unidirectional traffic (3.2.1) unidirectional traffic (3.2.1)
bidirectional traffic (3.2.2) bidirectional traffic (3.2.2)
one-to-one mapped traffic (3.3.1) one-to-one mapped traffic (3.3.1)
partially meshed traffic (3.3.2) partially meshed traffic (3.3.2)
burst (3.4.1) burst (3.4.1)
intended load (3.5.1)
offered load (3.5.2)
3.4 Bursts 3.4 Bursts
This group of definitions applies to the intervals between frames or This group of definitions applies to the intervals between frames or
groups of frames offered to the DUT/SUT. groups of frames offered to the DUT/SUT.
3.4.1 Burst 3.4.1 Burst
Definition: Definition:
A sequence of frames transmitted with the minimum inter-frame gap
allowed by the medium. A sequence of frames transmitted with the minimum inter-frame
gap allowed by the medium.
Discussion: 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 This definition follows from discussions in section 3.16 of RFC
consider isolated frames as single frame bursts. 1242 and section 21 of RFC 1944 which describes cases where it
is useful to consider isolated frames as single frame bursts.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
burst size (3.4.2) burst size (3.4.2)
inter-burst gap (IBG) (3.4.3) inter-burst gap (IBG) (3.4.3)
3.4.2 Burst size 3.4.2 Burst size
Definition: Definition:
The number of frames in a burst. The number of frames in a burst.
Discussion: Discussion:
Burst size can range from one to infinity. In unidirectional traffic
there is no theoretical limit to burst length. When traffic is Burst size can range from one to infinity. In unidirectional
bidirectional or meshed bursts on half duplex media are finite since traffic as well as in bidirectional or meshed traffic on full
interfaces interrupt transmission intermittently to receive frames. duplex interfaces there is no theoretical limit to burst
On real networks burst size will normally increase with window size. length. When traffic is bidirectional or meshed bursts on half
This makes it desirable to test devices with small as well as large duplex media are finite since interfaces interrupt transmission
burst sizes. 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: Measurement units:
number of N-octet frames number of N-octet frames
Issues: Issues:
See Also: See Also:
burst (3.4.1) burst (3.4.1)
inter-burst gap (IBG) (3.4.3) inter-burst gap (IBG) (3.4.3)
3.4.3 Inter-burst gap (IBG) 3.4.3 Inter-burst gap (IBG)
Definition: Definition:
The interval between two bursts. The interval between two bursts.
Discussion: 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 This definition conforms to the discussion in section 20 of RFC
share their time between receiving and transmitting frames. External 1944 on bursty traffic.
sources offering bursty traffic for a given frame size and burst size
must adjust the inter-burst gap to achieve a specified rate of Bidirectional and meshed traffic are inherently bursty since
transmission. 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: Measurement units:
nanoseconds nanoseconds
microseconds microseconds
milliseconds milliseconds
seconds seconds
Issues: Issues:
See Also: See Also:
burst (3.4.1) burst (3.4.1)
burst size (3.4.2) burst size (3.4.2)
3.5 Loads 3.5 Loads
This group of definitions applies to the rates at which traffic is This group of definitions applies to the rates at which traffic is
offered to any DUT/SUT. offered to any DUT/SUT.
3.5.1 Intended load (Iload) 3.5.1 Intended load (Iload)
skipping to change at page 9, line 40 skipping to change at page 12, line 27
burst size (3.4.2) burst size (3.4.2)
3.5 Loads 3.5 Loads
This group of definitions applies to the rates at which traffic is This group of definitions applies to the rates at which traffic is
offered to any DUT/SUT. offered to any DUT/SUT.
3.5.1 Intended load (Iload) 3.5.1 Intended load (Iload)
Definition: 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 The number of frames per second that an external source
interfaces. attempts to transmit to a DUT/SUT for forwarding to a specified
output interface or interfaces.
Discussion: Discussion:
Collisions on CSMA/CD links or the action of congestion control Collisions on CSMA/CD links or the action of congestion control
mechanisms can effect the rate at which an external source of traffic mechanisms can effect the rate at which an external source of
transmits frames to a DUT/SUT. This makes it useful to distinguish the traffic transmits frames to a DUT/SUT. This makes it useful to
load that an external source attempts to apply to a DUT/SUT and the distinguish the load that an external source attempts to apply
load it is observed or measured 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 In the case of Ethernet an external source of traffic MUST
the truncated binary exponential back-off algorithm to ensure that it Implement the truncated binary exponential back-off algorithm
is accessing the medium legally. to ensure that it is accessing the medium legally
Measurement units: Measurement units:
bits per second bits per second
N-octets per second N-octets per second
(N-octets per second / media_maximum-octets per second) x 100 (N-octets per second / media_maximum-octets per second) x 100
Issues: Issues:
See Also: See Also:
burst (3.4.1)
inter-burst gap (3.4.3)
offered load (3.5.2) offered load (3.5.2)
3.5.2 Offered load (Oload) 3.5.2 Offered load (Oload)
Definition: 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 The number of frames per second that an external source can be
output interface or interfaces. observed or measured to transmit to a DUT/SUT for forwarding to
a specified output interface or interfaces.
Discussion: 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 an interface of a DUT/SUT may exceed the rate at The load which an external device can be observed to apply to a
which an external device offers frames due to the presence of spanning DUT/SUT may be less than the intended load due to collisions on
tree BPDUs (Bridge Protocol Data Units) on 802.1D-compliant switches or half duplex media or the action of congestion control
SNMP frames. Such frames should be treated as modifiers as described in mechanisms. This makes it important to distinguish intended
section 11 of RFC 1944. 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: Measurement units:
bits per second bits per second
N-octets per second N-octets per second
(N-octets per second / media_maximum-octets per second) x 100 (N-octets per second / media_maximum-octets per second) x 100
Issues: Issues:
token ring token ring
See also: See Also:
bidirectional traffic (3.2.2)
fully meshed traffic (3.3.3)
intended load (3.5.1) intended load (3.5.1)
forwarding rate (3.6.1)
3.5.3 Maximum offered load (MOL) 3.5.3 Maximum offered load (MOL)
Definition: 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 The highest number of frames per second that an external source
or interfaces. can transmit to a DUT/SUT for forwarding to a specified output
interface or interfaces.
Discussion: 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 The maximum load that an external device can apply to a DUT/SUT
when an external source lacks the resources to transmit frames at the may not equal the maximum load allowed by the medium. This
minimum legal inter-frame gap or when it has sufficient resources to will be the case when an external source lacks the resources
transmit frames below the minimum legal inter-frame gap. Moreover, to transmit frames at the minimum legal inter-frame gap or when
maximum load may vary with respect to parameters other than a medium's it has sufficient resources to transmit frames below the
maximum theoretical utilization. For example, on those media employing minimum legal inter-frame gap. Moreover, maximum load may vary
tokens, maximum load may vary as a function of Token Rotation Time, with respect to parameters other than a medium's maximum
Token Holding Time, or the ability to chain multiple frames to a single theoretical utilization. For example, on those media employing
token. The maximum load that an external device applies to a DUT/SUT tokens, maximum load may vary as a function of Token Rotation
MUST be specified when measuring forwarding rates. 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: Measurement units:
bits per second bits per second
N-octets per second N-octets per second
(N-octets per second / media_maximum-octets per second) x 100 (N-octets per second / media_maximum-octets per second) x 100
Issues: Issues:
See Also: See Also:
offered load (3.5.2) offered load (3.5.2)
3.5.4 Overloading 3.5.4 Overloading
Definition: Definition:
Attempting to load a DUT/SUT in excess of the maximum rate of Attempting to load a DUT/SUT in excess of the maximum rate of
transmission allowed by the medium. transmission allowed by the medium.
Discussion: Discussion:
Overloading can serve to exercise buffers and buffer allocation Overloading can serve to exercise buffers and buffer allocation
algorithms as well as congestion control mechanisms. algorithms as well as congestion control mechanisms.
The number of input interfaces required to overload one or more output The number of input interfaces required to overload one or more
interfaces of a DUT/SUT will vary according to the media rates of the output interfaces of a DUT/SUT will vary according to the media
interfaces involved. An external source can also overload an interface rates of the interfaces involved.
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 An external source can also overload an interface by
meshed traffic. 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: Measurement units:
N-octets per second N-octets per second
(N-octets per second / media_maximum-octets per second) x 100 (N-octets per second / media_maximum-octets per second) x 100N-
N-octet frames per second octet
frames per second
Issues: Issues:
See Also: See Also:
unidirectional traffic (3.2.1)
intended load (3.5.1)
offered load (3.5.2) offered load (3.5.2)
forwarding rate (3.6.1)
backpressure (3.7.1)
forward pressure (3.7.2)
3.6 Forwarding rates 3.6 Forwarding rates
This group of definitions applies to the rates at which traffic is This group of definitions applies to the rates at which traffic is
forwarded by any DUT/SUT in response to a stimulus. forwarded by any DUT/SUT in response to a stimulus.
3.6.1 Forwarding rate (FR) 3.6.1 Forwarding rate (FR)
Definition: Definition:
The number of frames per second that a device can be observed to
successfully transmit to the correct destination interface in response The number of frames per second that a device can be observed
to a specified offered load. to successfully transmit to the correct destination interface
in response to a specified offered load.
Discussion: 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 Unlike throughput defined in section 3.17 of RFC 1242,
may be sensitive to the action of congestion control mechanisms. 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: Measurement units:
N-octet frames per second N-octet frames per second
Issues: Issues:
See Also: See Also:
offered load (3.5.2) offered load (3.5.2)
forwarding rate at maximum offered load (3.6.2) forwarding rate at maximum offered load (3.6.2)
maximum forwarding rate (3.6.3) maximum forwarding rate (3.6.3)
3.6.2 Forwarding rate at maximum offered load (FRMOL) 3.6.2 Forwarding rate at maximum offered load (FRMOL)
Definition: Definition:
The number of frames per second that a device can be observed to
successfully transmit to the correct destination interface in response The number of frames per second that a device can be observed
to the maximum offered load. To successfully transmit to the correct destination interface
in response to the maximum offered load.
Discussion: 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 Forwarding rate at maximum offered load may be less than the
MUST be cited when reporting forwarding rate at maximum offered load. 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: Measurement units:
N-octet frames per second N-octet frames per second
Issues: Issues:
See Also: See Also:
maximum offered load (3.5.3) maximum offered load (3.5.3)
forwarding rate (3.6.1) forwarding rate (3.6.1)
maximum forwarding rate (3.6.3) maximum forwarding rate (3.6.3)
3.6.3 Maximum forwarding rate (MFR) 3.6.3 Maximum forwarding rate (MFR)
Definition: Definition:
The highest forwarding rate of a DUT/SUT taken from an iterative set
of forwarding rate measurements. The highest forwarding rate of a DUT/SUT taken from an
iterative set of forwarding rate measurements.
Discussion: 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 The forwarding rate of a device may degenerate before maximum
forwarding rates are meant to be used. In particular it shows how the load is reached. The load applied to a device must be cited
distinction between forwarding rate at maximum offered load (FRMOL) when reporting maximum forwarding rate.
and maximum forwarding rate (MFR)can be used to characterize a DUT/SUT.
(A) (B) The following example illustrates how the terms relative to
Test Device DUT/SUT 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 Offered Rate Forwarding Rate
------------ --------------- ------------ ---------------
1. 14,880 fps 7,400 fps 1. 14,880 fps 7,400 fps Row 1, Col A - MOL
2. 13,880 fps 8,472 fps 2. 13,880 fps 8,472 fps Row 1, Col B - FRMOL
3. 12,880 fps 12,880 fps 3. 12,880 fps 12,880 fps Row 3, Col B - MFR
Column A - Oload
Column B - FR
Row 1, Col A - MOL
Row 1, Col B - FRMOL
Row 3, Col B - MFR
Measurement units: Measurement units:
N-octet frames per second
N-octet frames per second
Issues: Issues:
See Also: See Also:
offered load (3.5.2) offered load (3.5.2)
forwarding rates (3.6.1) forwarding rates (3.6.1)
forwarding rate at maximum load (3.6.2) forwarding rate at maximum load (3.6.2)
3.7 Congestion control 3.7 Congestion control
This group of definitions applies to the behavior of a DUT/SUT when This group of definitions applies to the behavior of a DUT/SUT when
congestion or contention is present. congestion or contention is present.
3.7.1 Backpressure 3.7.1 Backpressure
skipping to change at page 14, line 18 skipping to change at page 18, line 20
forwarding rate at maximum load (3.6.2) forwarding rate at maximum load (3.6.2)
3.7 Congestion control 3.7 Congestion control
This group of definitions applies to the behavior of a DUT/SUT when This group of definitions applies to the behavior of a DUT/SUT when
congestion or contention is present. congestion or contention is present.
3.7.1 Backpressure 3.7.1 Backpressure
Definition: Definition:
Any technique used by a DUT/SUT to attempt to avoid frame loss by
impeding external sources of traffic from transmitting frames to Any technique used by a DUT/SUT to attempt to avoid frame loss
congested interfaces. by impeding external sources of traffic from transmitting
frames to congested interfaces.
Discussion: 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 Some switches send jam signals, for example preamble bits, back
all traffic transmitted to congested input interfaces including traffic to traffic sources when their transmit and/or receive buffers
intended for uncongested output interfaces. 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: Measurement units:
frame loss on congested interface or interfaces
N--octet frames per second between the interface applying backpressure
and an uncongested destination interface
frame loss on congested interface or interfaces
N--octet frames per second between the interface applying
backpressure and an uncongested destination interface
Issues: Issues:
jamming not explicitly described in standards jamming not explicitly described in standards
See Also: 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) forward pressure (3.7.2)
3.7.2 Forward pressure 3.7.2 Forward pressure
Definition: Definition:
Methods which depart from or otherwise violate a defined standardized
protocol in an attempt to increase the forwarding performance of a Methods which depart from or otherwise violate a defined
DUT/SUT. standardized protocol in an attempt to increase the forwarding
performance of a DUT/SUT.
Discussion: 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 A DUT/SUT may be found to inhibit or abort back-off algorithms
noted that the back-off algorithm should be fair whether the DUT/SUT is in order to force access to the medium when contention occurs.
in a congested or an uncongested state. Transmission below the minimum It should be noted that the back-off algorithm should be fair
inter-frame gap or the disregard of flow control primitives fall into whether the DUT/SUT is in a congested or an uncongested state.
this category. 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: Measurement units:
intervals between frames in microseconds intervals between frames in microseconds
intervals in microseconds between transmission retries during 16 intervals in microseconds between transmission retries during
successive collisions. 16 successive collisions.
Issues: Issues:
truncated binary exponential back-off algorithm truncated binary exponential back-off algorithm
See Also:
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) backpressure (3.7.1)
3.7.3 Head of line blocking 3.7.3 Head of line blocking
Definition: Definition:
Frame loss observed on an uncongested output interface whenever frames
are received from an input interface which is also attempting to Frame loss or added delay observed on an uncongested output
forward frames to a congested output interface. interface whenever frames are received from an input interface
which is also attempting to forward frames to a congested
output interface.
Discussion: Discussion:
It is important to verify that a switch does not slow transmission or
drop frames on interfaces which are not congested whenever overloading It is important to verify that a switch does not slow
on one of its other interfaces occurs. transmission or drop frames on interfaces which are not
congested whenever overloading on one of its other interfaces
occurs.
Measurement units: 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 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: See Also:
unidirectional traffic (3.2.1) unidirectional traffic (3.2.1)
3.8 Address handling 3.8 Address handling
This group of definitions applies to the process of address resolution This group of definitions applies to the process of address
which enables a DUT/SUT to forward frames to the correct destination. resolution which enables a DUT/SUT to forward frames to the correct
destination.
3.8.1 Address caching capacity 3.8.1 Address caching capacity
Definition: 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 The number of MAC addresses per n interfaces, per module or per
flooding or dropping frames. device that a DUT/SUT can cache and successfully forward frames
to without flooding or dropping frames.
Discussion: Discussion:
Users building networks will want to know how many nodes they can Users building networks will want to know how many nodes they
connect to a DUT/SUT. This makes it necessary to verify the number of can connect to a DUT/SUT. This makes it necessary to verify
MAC addresses that can be assigned per n interfaces, per module and per the number of MAC addresses that can be assigned per n
chassis before a DUT/SUT begins flooding frames. interfaces, per module and per chassis before a DUT/SUT begins
flooding frames.
Measurement units: Measurement units:
number of MAC addresses per n interfaces, per module and/or per chassis
number of MAC addresses per n interfaces, per module and/or per
chassis
Issues: Issues:
See Also: See Also:
Address learning rate (3.8.2) Address learning rate (3.8.2)
3.8.2 Address learning rate 3.8.2 Address learning rate
Definition: Definition:
The maximum rate at which a switch can learn new MAC addresses before
starting to flood or drop frames. The maximum rate at which a switch can learn new MAC addresses
Before starting to flood or drop frames.
Discussion: 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 Users may want to know how long it takes a switch to build its
takes a network to come up when many users log on in the morning or address tables. This information is useful to have when
after a network crash. 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: Measurement units:
frames per second with each successive frame sent to the switch frames per second with each successive frame sent to the switch
containing a different source address. containing a different source address.
Issues: Issues:
See Also: address caching capacity (3.8.1) See Also:
address caching capacity (3.8.1)
3.8.3 Flood count 3.8.3 Flood count
Definition: Definition:
Frames forwarded to interfaces which do not correspond to the Frames forwarded to interfaces which do not correspond to the
destination MAC address information when traffic is offered to a destination MAC address information when traffic is offered to
DUT/SUT for forwarding. a DUT/SUT for forwarding.
Discussion: Discussion:
When recording throughput statistics it is important to check that
frames have been forwarded to their proper destinations. Flooded frames When recording throughput statistics it is important to check
MUST NOT be counted as received frames. Both known and unknown unicast that frames have been forwarded to their proper destinations.
frames can be flooded. Flooded frames MUST NOT be counted as received frames. Both
known and unknown unicast frames can be flooded.
Measurement units: Measurement units:
N-octet valid frames N-octet valid frames
Issues: Issues:
Spanning tree BPDUs.
spanning tree BPDUs.
See Also: See Also:
address caching capacity (3.8.1) address caching capacity (3.8.1)
3.9 Errored frame filtering 3.9 Errored frame filtering
This group of definitions applies to frames with errors which a DUT/SUT This group of definitions applies to frames with errors which a
may filter. DUT/SUT may filter.
3.9.1 Errored frames 3.9.1 Errored frames
Definition: Definition:
Frames which are over-sized, under-sized, misaligned or with an errored
Frame Check Sequence. Frames which are over-sized, under-sized, misaligned or with an
errored Frame Check Sequence.
Discussion: 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 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: Issues:
See Also: See Also:
3.10 Broadcasts 3.10 Broadcasts
This group of definitions applies to MAC layer and network layer This group of definitions applies to MAC layer and network layer
broadcast frames. broadcast frames.
3.10.1 Broadcast forwarding rate 3.10.1 Broadcast forwarding rate
Definition: 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 The number of broadcast frames per second that a DUT/SUT can be
in response to a specified offered load. 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: 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
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
Issues: Issues:
See Also: See Also:
forwarding rate at maximum load (3.6.2) forwarding rate at maximum load (3.6.2)
maximum forwarding rate (3.6.3) maximum forwarding rate (3.6.3)
broadcast latency (3.10.2) broadcast latency (3.10.2)
3.10.2 Broadcast latency 3.10.2 Broadcast latency
Definition: Definition:
The time required by a DUT/SUT to forward a broadcast frame to each
interface located within a broadcast domain. The time required by a DUT/SUT to forward a broadcast frame to
each interface located within a broadcast domain.
Discussion: Discussion:
Since there is no standard way for switches to process broadcast
frames, broadcast latency may not be the same on all receiving Since there is no standard way for switches to process
interfaces of a switching device. The latency measurements SHOULD be broadcast frames, broadcast latency may not be the same on all
bit oriented as described in 3.8 of RFC 1242. It is useful to determine receiving interfaces of a switching device. The latency
broadcast latency for frames forwarded between interfaces on the same measurements SHOULD be bit oriented as described in 3.8 of
card, interfaces on different cards in the same chassis and interfaces RFC 1242. It is useful to determine broadcast latency for
on different chassis linked together over backbone connections. 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: Measurement units:
nanoseconds nanoseconds
microseconds microseconds
milliseconds milliseconds
seconds seconds
Issues: Issues:
See Also: See Also:
broadcast forwarding rate (3.10.1) broadcast forwarding rate (3.10.1)
4. Security Considerations 4. Security Considerations
This document raises no security issues. 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: 5. References:
1. RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" 1. RFC 1242 "Benchmarking Terminology for Network Interconnect
2. RFC 1944 "Benchmarking Methodology for Network Interconnect Devices" Devices"
2. RFC 1944 "Benchmarking Methodology for Network Interconnect
Devices"
6. Acknowledgments 6. Acknowledgments
A special thanks goes to the IETF BenchMarking Methodology WorkGroup A special thanks goes to the IETF BenchMarking Methodology
for the many suggestions it collectively made to help complete this RFC. WorkGroup for the many suggestions it collectively made to help
Kevin Dubray (Bay Networks), Jean-Christophe Bestaux (ENL), Ajay Shah complete this RFC. Kevin Dubray (Bay Networks), Jean-Christophe
(WG), Henry Hamon (Netcom Systems), Stan Kopek (3Com) and Doug Ruby Bestaux (ENL), Ajay Shah (WG), Henry Hamon (Netcom Systems), Stan
(Prominet) provided valuable input at various stages of this project. Kopek (3Com) and Doug Ruby (Prominet) provided valuable input at
various stages of this project.
7. Author's Address 7. Author's Address
Robert Mandeville Robert Mandeville
European Network Laboratories (ENL) European Network Laboratories (ENL)
6, Parc Ariane "Le Mercure" 33, Boulevard Henri IV
Boulevard des Chenes 75004 Paris
78284 Guyancourt
France France
phone: + 33 1 39 44 12 05 or mobile phone + 33 6 07 47 67 10 phone: + 33 1 39 44 12 05
mobile phone + 33 6 07 47 67 10
fax: + 33 1 39 44 12 06 fax: + 33 1 39 44 12 06
email: bob.mandeville@eunet.fr email: bob.mandeville@eunet.fr
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/