As per Relevance of the word forwarding, we have this rfc below:











Network Working Group R.
Request for Comments: 2285 European Network
Category: Informational February 1998


Benchmarking Terminology for LAN Switching

Status of this

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

Copyright

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

Table of

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Existing definitions . . . . . . . . . . . . . . . . . . . . . . 2
3. Term definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1 Device under test (DUT) . . . . . . . . . . . . . . . . 3
3.1.2 System under test (SUT) . . . . . . . . . . . . . . . . 3
3.2 Traffic orientation. . . . . . . . . . . . . . . . . . . . . 4
3.2.1 Unidirectional traffic. . . . . . . . . . . . . . . . . 4
3.2.2 Bidirectional traffic . . . . . . . . . . . . . . . . . 5
3.3 Traffic distribution . . . . . . . . . . . . . . . . . . . . 6
3.3.1 Non-meshed traffic. . . . . . . . . . . . . . . . . . . 6
3.3.2 Partially meshed traffic. . . . . . . . . . . . . . . . 7
3.3.3 Fully meshed traffic. . . . . . . . . . . . . . . . . . 8
3.4 Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1 Burst . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.2 Burst size . . . . . . . . . . . . . . . . . . . . . . 10
3.4.3 Inter-burst gap (IBG). . . . . . . . . . . . . . . . . 10
3.5 Loads . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5.1 Intended load (Iload) . . . . . . . . . . . . . . . . 11
3.5.2 Offered load (Oload) . . . . . . . . . . . . . . . . . 12
3.5.3 Maximum offered load (MOL) . . . . . . . . . . . . . . 13
3.5.4 Overloading . . . . . . . . . . . . . . . . . . . . . 14
3.6 Forwarding rates . . . . . . . . . . . . . . . . . . . . . 15
3.6.1 Forwarding rate (FR) . . . . . . . . . . . . . . . . . 15
3.6.2 Forwarding rate at maximum offered load (FRMOL). . . . 16
3.6.3 Maximum forwarding rate (MFR). . . . . . . . . . . . . 16
3.7 Congestion control . . . . . . . . . . . . . . . . . . . . 17
3.7.1 Backpressure . . . . . . . . . . . . . . . . . . . . . 17
3.7.2 Forward pressure . . . . . . . . . . . . . . . . . . . 18



Mandeville Informational [Page 1]

RFC 2285 Benchmarking Terminology February 1998


3.7.3 Head of line blocking . . . . . . . . . . . . . . . . 19
3.8 Address handling . . . . . . . . . . . . . . . . . . . . . 20
3.8.1 Address caching capacity . . . . . . . . . . . . . . . 20
3.8.2 Address learning rate . . . . . . . . . . . . . . . . 20
3.8.3 Flood count . . . . . . . . . . . . . . . . . . . . . 21
3.9 Errored frame filtering . . . . . . . . . . . . . . . . . . 21
3.9.1 Errored frames . . . . . . . . . . . . . . . . . . . . 22
3.10 Broadcasts . . . . . . . . . . . . . . . . . . . . . . . . 22
3.10.1 Broadcast forwarding rate at maximum load . . . . . . 22
3.10.2 Broadcast latency . . . . . . . . . . . . . . . . . . 23
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 24
5. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 24
7. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . 24
8. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 25

1.

This document is intended to provide terminology for the
of local area network (LAN) switching devices. It extends
terminology already defined for benchmarking network
devices in RFCs 1242 and 1944 to switching devices

Although it might be found useful to apply some of the terms
here to a broader range of network interconnect devices, this
primarily deals with devices which switch frames at the Medium
Control (MAC) layer. It defines terms in relation to the traffic
to use when benchmarking switching devices, forwarding performance
congestion control, latency, address handling and filtering

2. Existing

RFC 1242 "Benchmarking Terminology for Network Interconnect Devices
should be consulted before attempting to make use of this document
RFC 1944 "Benchmarking Methodology for Network Interconnect Devices
contains discussions of a number of terms relevant to
benchmarking of switching devices and should also be consulted

For the sake of clarity and continuity this RFC adopts the
for definitions set out in Section 2 of RFC 1242. Definitions
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
document are to be interpreted as described in RFC 2119.






Mandeville Informational [Page 2]

RFC 2285 Benchmarking Terminology February 1998


3. Term

3.1

This group of definitions applies to all types of networking devices

3.1.1 Device under test (DUT

Definition

The network forwarding device to which stimulus is offered
response measured

Discussion

A single stand-alone or modular unit which receives frames on
or more of its interfaces and then forwards them to one or
interfaces according to the addressing information contained
the frame

Measurement units

n/

Issues

See Also

system under test (SUT) (3.1.2)

3.1.2 System Under Test (SUT

Definition

The collective set of network devices to which stimulus is
as a single entity and response measured

Discussion

A system under test may be comprised of a variety of
devices. Some devices may be active in the forwarding decision
making process, such as routers or switches; other devices may
passive such as a CSU/DSU. Regardless of constituent components
the system is treated as a singular entity to which stimulus
offered and response measured






Mandeville Informational [Page 3]

RFC 2285 Benchmarking Terminology February 1998


Measurement units

n/

Issues

See Also

device under test (DUT) (3.1.1)

3.2 Traffic

This group of definitions applies to the traffic presented to
interfaces of a DUT/SUT and indicates whether the interfaces
receiving only, transmitting only, or both receiving
transmitting

3.2.1 Unidirectional

Definition

When all frames presented to the input interfaces of a DUT/SUT
addressed to output interfaces which do not themselves receive
frames

Discussion

This definition conforms to the discussion in section 16 of
1944 which describes how unidirectional traffic can be offered
a DUT/SUT to measure throughput. Unidirectional traffic is
appropriate for

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

When a tester offers unidirectional traffic to a DUT/SUT
and transmission are handled by different interfaces or sets
interfaces of the DUT/SUT. All frames received from the tester
the DUT/SUT are transmitted back to the tester from
which do not themselves receive any frames

It is useful to distinguish traffic orientation and
distribution when considering traffic patterns used in
testing. Unidirectional traffic, for example, is
orientated in a single direction between mutually exclusive
of source and destination interfaces of a DUT/SUT. Such traffic



Mandeville Informational [Page 4]

RFC 2285 Benchmarking Terminology February 1998


however, can be distributed between interfaces in different ways
When traffic is sent to two or more interfaces from an
source and then forwarded by the DUT/SUT to a single
interface the traffic orientation is unidirectional and
traffic distribution between interfaces is many-to-one.
can also be sent to a single input interface and forwarded by
DUT/SUT to two or more output interfaces to achieve a one-to-
distribution of traffic

Such traffic distributions can also be combined to test for
of line blocking or to measure forwarding rates and
when congestion control mechanisms are active

When a DUT/SUT is equipped with interfaces running at
media rates the number of input interfaces required to load
overload an output interface or interfaces will vary

It should be noted that measurement of the minimum inter-frame
serves to detect violations of the IEEE 802.3 standard

Issues

half duplex / full

Measurement units

n/

See Also

bidirectional traffic (3.2.2)
non-meshed traffic (3.3.1)
partially meshed traffic (3.3.2)
fully meshed traffic (3.3.3)
congestion control (3.7)
head of line blocking (3.7.3)

3.2.2 Bidirectional

Definition

Frames presented to a DUT/SUT such that every receiving
also transmits

Discussion

This definition conforms to the discussion in section 14 of
1944.



Mandeville Informational [Page 5]

RFC 2285 Benchmarking Terminology February 1998


When a tester offers bidirectional traffic to a DUT/SUT all
interfaces which receive frames from the tester also
frames back to the tester

Bidirectional traffic MUST be offered when measuring
throughput or forwarding rate of full duplex interfaces of
switching device

Issues

truncated binary exponential back-off

Measurement units

n/

See Also

unidirectional traffic (3.2.1)
non-meshed traffic (3.3.1)
partially meshed traffic (3.3.2)
fully meshed traffic (3.3.3)

3.3 Traffic

This group of definitions applies to the distribution of
forwarded by a DUT/SUT

3.3.1 Non-meshed

Definition

Frames offered to a single input interface and addressed to
single output interface of a DUT/SUT where input and
interfaces are grouped in mutually exclusive pairs

Discussion

In the simplest instance of non-meshed traffic all frames
offered to a single input interface and addressed to a
output interface. The one-to-one mapping of input to
interfaces required by non-meshed traffic can be extended
multiple mutually exclusive pairs of input and output interfaces

Measurement units

n/




Mandeville Informational [Page 6]

RFC 2285 Benchmarking Terminology February 1998


Issues

half duplex / full

See Also

unidirectional traffic (3.2.1)
bidirectional traffic (3.2.2)
partially meshed traffic (3.3.2.)
fully meshed traffic (3.3.3)
burst (3.4.1)

3.3.2 Partially meshed

Definition

Frames offered to one or more input interfaces of a DUT/SUT
addressed to one or more output interfaces where input and
interfaces are mutually exclusive and mapped one-to-many, many
to-one or many-to-many

Discussion

This definition follows from the discussion in section 16 of
1944 on multi-port testing. Partially meshed traffic allows
one-to-many, many-to-one or many-to-many mappings of input
output interfaces and readily extends to configurations
multiple switching devices linked together over
connections

It should be noted that partially meshed traffic can load
connections linking together two switching devices or systems
than fully meshed traffic. When offered partially meshed
devices or systems can be set up to forward all of the frames
receive to the opposite side of the backbone connection
fully meshed traffic requires at least some of the offered
to be forwarded locally, that is to the interfaces of the DUT/
receiving them. Such frames will not traverse the
connection

Measurement units

n/

Issues

half duplex / full




Mandeville Informational [Page 7]

RFC 2285 Benchmarking Terminology February 1998


See Also

unidirectional traffic (3.2.1)
bidirectional traffic (3.2.2)
non-meshed traffic (3.3.1)
fully meshed traffic (3.3.3)
burst (3.4.1)

3.3.3 Fully meshed

Definition

Frames offered to a designated number of interfaces of a DUT/
such that each one of the interfaces under test receives
addressed to all of the other interfaces under test

Discussion

As with bidirectional partially meshed traffic, fully
traffic requires each one the interfaces of a DUT/SUT to
receive and transmit frames. But since the interfaces are
divided into groups as with partially meshed traffic
interface forwards frames to and receives frames from every
interface. The total number of individual input/output
pairs when traffic is fully meshed over n switched
equals n x (n - 1). This compares with n x (n / 2) such
pairs when traffic is partially meshed

Fully meshed traffic on half duplex interfaces is
bursty since interfaces must interrupt transmission whenever
receive frames. This kind of bursty meshed traffic
characteristic of real network traffic and can be
used to diagnose a DUT/SUT by exercising many of its
parts simultaneously. Additional inspection may be warranted
correlate the frame forwarding capacity of a DUT/SUT when
meshed traffic and the behavior of individual elements such
input or output buffers, buffer allocation mechanisms,
switching capacity, processing speed or medium access control

The analysis of forwarding rate measurements presents a
when offering bidirectional or fully meshed traffic since the
at which the tester can be observed to transmit frames to
DUT/SUT may be smaller than the rate at which it intends
transmit due to collisions on half duplex media or the action
congestion control mechanisms. This makes it important to
account of both the intended and offered loads defined in
3.5.1.and 3.5.2 below when reporting the results of
forwarding rate measurements



Mandeville Informational [Page 8]

RFC 2285 Benchmarking Terminology February 1998


When offering bursty meshed traffic to a DUT/SUT a number
variables have to be considered. These include frame size,
number of frames within bursts, the interval between bursts
well as the distribution of load between incoming and
traffic. Terms related to bursts are defined in section 3.4
below

Measurement units

n/

Issues

half duplex / full

See Also

unidirectional traffic (3.2.1)
bidirectional traffic (3.2.2)
non-meshed traffic (3.3.1)
partially meshed traffic (3.3.2)
burst (3.4.1)
intended load (3.5.1)
offered load (3.5.2)

3.4

This group of definitions applies to the intervals between frames
groups of frames offered to the DUT/SUT

3.4.1

Definition

A sequence of frames transmitted with the minimum legal inter
frame gap

Discussion

This definition follows from discussions in section 3.16 of
1242 and section 21 of RFC 1944 which describes cases where it
useful to consider isolated frames as single frame bursts

Measurement units

n/

Issues



Mandeville Informational [Page 9]

RFC 2285 Benchmarking Terminology February 1998


See Also

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

3.4.2 Burst

Definition

The number of frames in a burst

Discussion

Burst size can range from one to infinity. In
traffic as well as in bidirectional or meshed traffic on
duplex interfaces there is no theoretical limit to burst length
When traffic is bidirectional or meshed bursts on half
media are finite since interfaces interrupt
intermittently to receive frames

On real networks burst size will normally increase with
size. This makes it desirable to test devices with small as
as large burst sizes

Measurement units

number of N-octet

Issues

See Also

burst (3.4.1)
inter-burst gap (IBG) (3.4.3)

3.4.3 Inter-burst gap (IBG

Definition

The interval between two bursts

Discussion

This definition conforms to the discussion in section 20 of
1944 on bursty traffic






Mandeville Informational [Page 10]

RFC 2285 Benchmarking Terminology February 1998


Bidirectional and meshed traffic are inherently bursty
interfaces share their time between receiving and
frames. External sources offering bursty traffic for a
frame size and burst size must adjust the inter-burst gap
achieve a specified average rate of frame transmission

Measurement units






Issues

See Also

burst (3.4.1)
burst size (3.4.2)

3.5

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

3.5.1 Intended load (Iload

Definition

The number of frames per second that an external source
to transmit to a DUT/SUT for forwarding to a specified
interface or interfaces

Discussion

Collisions on CSMA/CD links or the action of congestion
mechanisms can effect the rate at which an external source
traffic transmits frames to a DUT/SUT. This makes it useful
distinguish the load that an external source attempts to apply
a DUT/SUT and the load it is observed or measured to apply

In the case of Ethernet an external source of traffic
implement the truncated binary exponential back-off algorithm
ensure that it is accessing the medium







Mandeville Informational [Page 11]

RFC 2285 Benchmarking Terminology February 1998


Measurement units

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

Issues

See Also

burst (3.4.1)
inter-burst gap (3.4.3)
offered load (3.5.2)

3.5.2 Offered load (Oload

Definition

The number of frames per second that an external source can
observed or measured to transmit to a DUT/SUT for forwarding to
specified output interface or interfaces

Discussion

The load which an external device can be observed to apply to
DUT/SUT may be less than the intended load due to collisions
half duplex media or the action of congestion control mechanisms
This makes it important to distinguish intended and offered
when analyzing the results of forwarding rate measurements
bidirectional or fully meshed traffic

Frames which are not successfully transmitted by an
source of traffic to a DUT/SUT MUST NOT be counted as
frames when measuring forwarding rates

The frame count on an interface of a DUT/SUT may exceed the
at which an external device offers frames due to the presence
spanning tree BPDUs (Bridge Protocol Data Units) on 802.1D
compliant switches or SNMP frames. Such frames should be
as modifiers as described in section 11 of RFC 1944.

Offered load MUST be indicated when reporting the results
forwarding rate measurements








Mandeville Informational [Page 12]

RFC 2285 Benchmarking Terminology February 1998


Measurement units

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

Issues

token

See Also

bidirectional traffic (3.2.2)
fully meshed traffic (3.3.3)
intended load (3.5.1)
forwarding rate (3.6.1)

3.5.3 Maximum offered load (MOL

Definition

The highest number of frames per second that an external
can transmit to a DUT/SUT for forwarding to a specified
interface or interfaces

Discussion

The maximum load that an external device can apply to a DUT/
may not equal the maximum load allowed by the medium.
will be the case when an external source lacks the
to transmit frames at the minimum legal inter-frame gap or
it has sufficient resources to transmit frames below
minimum legal inter-frame gap. Moreover, maximum load may
with respect to parameters other than a medium's
theoretical utilization. For example, on those media
tokens, maximum load may vary as a function of Token
Time, Token Holding Time, or the ability to chain
frames to a single token. The maximum load that an
device applies to a DUT/SUT MUST be specified when
forwarding rates

Measurement units

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

Issues



Mandeville Informational [Page 13]

RFC 2285 Benchmarking Terminology February 1998


See Also

offered load (3.5.2)

3.5.4

Definition

Attempting to load a DUT/SUT in excess of the maximum rate
transmission allowed by the medium

Discussion

Overloading can serve to exercise buffers and buffer
algorithms as well as congestion control mechanisms. The
of input interfaces required to overload one or more
interfaces of a DUT/SUT will vary according to the media rates
the interfaces involved

An external source can also overload an interface by
frames below the minimum inter-frame gap. A DUT/SUT MUST
such frames at intervals equal to or above the minimum
specified in standards

A DUT/SUT using congestion control techniques such as
or forward pressure may exhibit no frame loss when a
attempts to overload one or more of its interfaces. This
not be exploited to suggest that the DUT/SUT supports rates
transmission in excess of the maximum rate allowed by the
since both techniques reduce the rate at which the tester
frames to prevent overloading. Backpressure achieves this
by jamming the transmission interfaces of the tester and
pressure by hindering the tester from gaining fair access to
medium. Analysis of both cases should take the
between intended load (3.5.1) and offered load (3.5.2)
account

Measurement units

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

Issues







Mandeville Informational [Page 14]

RFC 2285 Benchmarking Terminology February 1998


See Also

unidirectional traffic (3.2.1)
intended load (3.5.1)
offered load (3.5.2)
forwarding rate (3.6.1)
backpressure (3.7.1)
forward pressure (3.7.2)

3.6 Forwarding

This group of definitions applies to the rates at which traffic
forwarded by any DUT/SUT in response to a stimulus

3.6.1 Forwarding rate (FR

Definition

The number of frames per second that a device can be observed
successfully transmit to the correct destination interface
response to a specified offered load

Discussion

Unlike throughput defined in section 3.17 of RFC 1242,
rate makes no explicit reference to frame loss. Forwarding
refers to the number of frames per second observed on the
side of the interface under test and MUST be reported in
to the offered load. Forwarding rate can be measured
different traffic orientations and distributions

It should be noted that the forwarding rate of a DUT/SUT may
sensitive to the action of congestion control mechanisms

Measurement units

N-octet frames per

Issues

See Also

offered load (3.5.2)
forwarding rate at maximum offered load (3.6.2)
maximum forwarding rate (3.6.3)






Mandeville Informational [Page 15]

RFC 2285 Benchmarking Terminology February 1998


3.6.2 Forwarding rate at maximum offered load (FRMOL

Definition

The number of frames per second that a device can be observed
successfully transmit to the correct destination interface
response to the maximum offered load

Discussion

Forwarding rate at maximum offered load may be less than
maximum rate at which a device can be observed to
forward traffic. This will be the case when the ability of
device to forward frames degenerates when offered traffic
maximum load

Maximum offered load MUST be cited when reporting forwarding
at maximum offered load

Measurement units

N-octet frames per

Issues

See Also

maximum offered load (3.5.3)
forwarding rate (3.6.1)
maximum forwarding rate (3.6.3)

3.6.3 Maximum forwarding rate (MFR

Definition

The highest forwarding rate of a DUT/SUT taken from an
set of forwarding rate measurements

Discussion

The forwarding rate of a device may degenerate before maximum
is reached. The load applied to a device must be cited
reporting maximum forwarding rate








Mandeville Informational [Page 16]

RFC 2285 Benchmarking Terminology February 1998


The following example illustrates how the terms relative
loading and forwarding rates are meant to be used. In
it shows how the distinction between forwarding rate at
offered load (FRMOL) and maximum forwarding rate (MFR) can be
to characterize a DUT/SUT

(A) (B
Test Device DUT/
Offered Load Forwarding
------------ ---------------
(1) 14,880 fps - MOL 7,400 fps -
(2) 13,880 fps 8,472
(3) 12,880 fps 12,880 fps -

Measurement units

N-octet frames per

Issues

See Also

offered load (3.5.2)
forwarding rates (3.6.1)
forwarding rate at maximum load (3.6.2)

3.7 Congestion

This group of definitions applies to the behavior of a DUT/SUT
congestion or contention is present

3.7.1

Definition

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

Discussion

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




Mandeville Informational [Page 17]

RFC 2285 Benchmarking Terminology February 1998


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

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

Measurement units

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

Issues

jamming not explicitly described in

See Also

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

3.7.2 Forward

Definition

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

Discussion

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




Mandeville Informational [Page 18]

RFC 2285 Benchmarking Terminology February 1998


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

Measurement units

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

Issues

truncated binary exponential back-off

See Also

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

3.7.3 Head of line

Definition

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

Discussion

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

Measurement units

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



Mandeville Informational [Page 19]

RFC 2285 Benchmarking Terminology February 1998


Issues

input

See Also

unidirectional traffic (3.2.1)

3.8 Address

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

3.8.1 Address caching

Definition

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

Discussion

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

Measurement units

number of MAC addresses per n interfaces, modules, or

Issues

See Also

address learning rate (3.8.2)

3.8.2 Address learning

Definition

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







Mandeville Informational [Page 20]

RFC 2285 Benchmarking Terminology February 1998


Discussion

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

Measurement units

frames with different source addresses per

Issues

See Also

address caching capacity (3.8.1)

3.8.3 Flood

Definition

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

Discussion

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

Measurement units

N-octet valid

Issues

spanning tree BPDUs

See Also

address caching capacity (3.8.1)

3.9 Errored frame

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



Mandeville Informational [Page 21]

RFC 2285 Benchmarking Terminology February 1998


3.9.1 Errored

Definition

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

Discussion

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

Measurement units

n/

Issues

See Also

3.10

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

3.10.1 Broadcast forwarding

Definition

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

Discussion

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






Mandeville Informational [Page 22]

RFC 2285 Benchmarking Terminology February 1998


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

Measurement units

N-octet frames per

Issues

See Also

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

3.10.2 Broadcast

Definition

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

Discussion

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

Measurement units






Issues

See Also

broadcast forwarding rate (3.10.1)



Mandeville Informational [Page 23]

RFC 2285 Benchmarking Terminology February 1998


4. Security

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

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

5.

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

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

6.

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

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

7. Author's

Robert
European Network Laboratories (ENL
2, rue Helene
78286 Guyancourt


Phone: + 33 1 39 44 12 05
Mobile Phone + 33 6 07 47 67 10
Fax: + 33 1 39 44 12 06
EMail: bob.mandeville@eunet.




Mandeville Informational [Page 24]

RFC 2285 Benchmarking Terminology February 1998


8. Full Copyright

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

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

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

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
























Mandeville Informational [Page 25]








if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.




RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX







Spectrum