RFC 2889 (rfc2889) - Page 2 of 35
Benchmarking Methodology for LAN Switching Devices
Alternative Format: Original Text Document
RFC 2889 LAN Switch Benchmarking Methodology August 2000
1. Introduction
This document is intended to provide methodology for the benchmarking
of local area network (LAN) switching devices. It extends the
methodology already defined for benchmarking network interconnecting
devices in RFC 2544 [3] to switching devices.
This RFC primarily deals with devices which switch frames at the
Medium Access Control (MAC) layer. It provides a methodology for
benchmarking switching devices, forwarding performance, congestion
control, latency, address handling and filtering. In addition to
defining the tests, this document also describes specific formats for
reporting the results of the tests.
A previous document, "Benchmarking Terminology for LAN Switching
Devices" [2], defined many of the terms that are used in this
document. The terminology document SHOULD be consulted before
attempting to make use of this document.
2. Requirements
The following RFCs SHOULD be consulted before attempting to make use
of this document: RFC 1242 [1], RFC 2285 [2], and RFC 2544 [3].
For the sake of clarity and continuity, this RFC adopts the template
for benchmarking tests set out in Section 26 of RFC 2544.
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. Test setup
This document extends the general test setup described in section 6
of RFC 2544 [3] to the benchmarking of LAN switching devices. RFC
2544 [3] primarily describes non-meshed traffic where input and
output interfaces are grouped in mutually exclusive sending and
receiving pairs. In fully meshed traffic, each interface of a
DUT/SUT is set up to both receive and transmit frames to all the
other interfaces under test.
Prior to each test run, the DUT/SUT MUST learn the MAC addresses used
in the test and the address learning SHOULD be verified. Addresses
not learned will be forwarded as flooded frames and reduce the amount
of correctly forwarded frames. The rate at which address learning
frames are offered may have to be adjusted to be as low as 50 frames
per second or even less, to guarantee successful learning. The
DUT/SUT address aging time SHOULD be configured to be greater than
Mandeville & Perser Informational