possible that sending a large amount of frames may actually take
longer than the aging time.
This test MUST at a minimum be performed in a three-port
configuration in section 5.9.3. The test MAY be expanded to fully
utilized the DUT/SUT in increments of two or three ports. An
increment of two would include an additional Learning port and Test
port. An increment of three would include an additional Learning
port, Test port, and Monitoring port.
An algorithm similar to the one used to determine address caching
capacity can be used to determine the address learning rate. This
test iterates the rate at which address learning frames are offered
by the test device connected to the DUT/SUT. It is recommended to
set the number of addresses offered to the DUT/SUT in this test to
the maximum caching capacity.
The address learning rate might be determined for different numbers
of addresses but in each test run, the number MUST remain constant
and SHOULD be equal to or less than the maximum address caching
capacity.
5.8.4 Measurements
Whether the offered addresses per port were successful forwarded
without flooding at the offered learning rate.
5.8.5 Reporting format
After the test is run, results for each iteration SHOULD be displayed
in a table:
The number of addresses used for each test iteration (fixed).
The intended load used for each test iteration (varied).
Number of test frames that were transmitted by Tport. This SHOULD
match the number of addresses used for the test iteration. Test
frames are the frames sent with varying destination addresses to
confirm that the DUT/SUT has learned all of the addresses for each
test iteration.
The flood count on Tport during the test portion of each test. If
the number is non-zero, this is an indication of the DUT/SUT
flooding a frame in which the destination address is not in the
address table.
The number of frames correctly forwarded to test Lport during the
test portion of the test. Received frames MUST have the correct
destination MAC address and SHOULD match a signature field. For a
passing test iteration, this number should be equal to the number
of frames transmitted by Tport.
The flood count on Lport during the test portion of each test. If
the number is non-zero, this is an indication of the DUT/SUT
flooding a frame in which the destination address is not in the
address table.
The flood count on Mport. If the value is not zero, then this
indicates that for that test iteration, the DUT/SUT could not
determine the proper destination port for that many frames. In
other words, the DUT/SUT flooded the frame to all ports since its
address table was full.
5.9 Errored frames filtering
5.9.1 Objective
The objective of the Errored frames filtering test is to determine
the behavior of the DUT under error or abnormal frame conditions.
The results of the test indicate if the DUT/SUT filters the errors,
or simply propagates the errored frames along to the destination.
5.9.2 Setup Parameters
The following parameters MUST be defined. Each variable is
configured with the following considerations.
ILoad - Intended Load per port is expressed in a percentage of the
medium's maximum theoretical load possible. The actual
transmitted frame per second is dependent upon half duplex or full
duplex operation. The test SHOULD be run multiple times with a
different load per port in each case.
Trial Duration - The recommended Trial Duration is 30 seconds.
Trial duration SHOULD be adjustable between 1 and 300 seconds.
5.9.3 Procedure
Each of the illegal frames for Ethernet MUST be checked:
Oversize - The DUT/SUT MAY filter frames larger than 1518 bytes from
being propagated through the DUT/SUT section 4.2.4.2.1 [4].
Oversized frames transmitted to the DUT/SUT should not be forwarded.
DUT/SUT supporting tagged Frames MAY forward frames up to and
including 1522 bytes long (section 4.2.4.2.1 [5]).
Undersize - The DUT/SUT MUST filter frames less than 64 bytes from
being propagated through the DUT/SUT (section 4.2.4.2.2 [4]).
Undersized frames (or collision fragments) received by the DUT/SUT
must not be forwarded.
CRC Errors - The DUT/SUT MUST filter frames that fail the Frame Check
Sequence Validation (section 4.2.4.1.2 [4]) from being propagated
through the DUT/SUT. Frames with an invalid CRC transmitted to the
DUT/SUT should not be forwarded.
Dribble Bit Errors - The DUT/SUT MUST correct and forward frames
containing dribbling bits. Frames transmitted to the DUT/SUT that do
not end in an octet boundary but contain a valid frame check sequence
MUST be accepted by the DUT/SUT (section 4.2.4.2.1 [4]) and forwarded
to the correct receive port with the frame ending in an octet
boundary (section 3.4 [4]).
Alignment Errors - The DUT/SUT MUST filter frames that fail the Frame
Check Sequence Validation AND do not end in an octet boundary. This
is a combination of a CRC error and a Dribble Bit error. When both
errors are occurring in the same frame, the DUT/SUT MUST determine
the CRC error takes precedence and filters the frame (section
4.2.4.1.2 [4]) from being propagated.
5.9.5 Reporting format
For each of the error conditions in section 5.6.3, a "pass" or "fail"
MUST be reported. Actual frame counts MAY be reported for diagnostic
purposes.
5.10 Broadcast frame Forwarding and Latency
5.10.1 Objective
The objective of the Broadcast Frame Forwarding and Latency Test is
to determine the throughput and latency of the DUT when forwarding
broadcast traffic. The ability to forward broadcast frames will
depend upon a specific function built into the device for that
purpose. It is therefore necessary to determine the ability of
DUT/SUT to handle broadcast frames, since there may be many different
ways of implementing such a function.
5.10.2 Setup Parameters
The following parameters MUST be defined. Each variable is
configured with the following considerations.
Frame Size - Recommended frame sizes are 64, 128, 256, 512, 1024,
1280 and 1518 bytes, per RFC2544 section 9 [3]. The four CRC
bytes are included in the frame size specified.
Duplex mode - Half duplex or full duplex.
ILoad - Intended Load per port is expressed in a percentage of the
medium's maximum theoretical load, regardless of traffic
orientation or duplex mode. Certain test configurations will
theoretically over-subscribe the DUT/SUT.
ILoad will not over-subscribe the DUT/SUT in this test.
Trial Duration - The recommended Trial Duration is 30 seconds.
Trial duration SHOULD be adjustable between 1 and 300 seconds.
5.10.3 Procedure
For this test, there are two parts to be run.
Broadcast Frame Throughput - This portion of the test uses a single
source test port to transmit test frames with a broadcast address
using the frame specified in RFC2544 [3]. Selected receive ports
then measure the forwarding rate and Frame loss rate.
Broadcast Frame Latency - This test uses the same setup as the
Broadcast Frame throughput, but instead of a large stream of test
frames being sent, only one test frame is sent and the latency to
each of the receive ports are measured in seconds.
5.10.4 Measurements
Frame loss rate of the DUT/SUT SHOULD be reported as defined in
section 26.3 [3] with the following notes: Frame loss rate SHOULD be
measured at the end of the trial duration. The term "rate", for this
measurement only, does not imply the units in the fashion of "per
second."
Forwarding rate (FR) of the DUT/SUT SHOULD be reported as the number
of test frames per second that the device is observed to successfully
forward to the correct destination interface in response to a
specified Oload. The Oload MUST also be cited.
5.10.5 Reporting format
The results for these tests SHOULD be reported in the form of a
graph. The x coordinate SHOULD be the frame size, the y coordinate
SHOULD be the test results. There SHOULD be at least two lines on
the graph, one plotting the theoretical and one plotting the test
results.
To measure the DUT/SUT's ability to switch traffic while performing
many different address lookups, the number of addresses per port MAY
be increased in a series of tests.
6. Security Considerations
As this document is solely for the purpose of providing metric
methodology and describes neither a protocol nor a protocol's
implementation, there are no security considerations associated with
this document.
7. References
[1] Bradner, S., Editor, "Benchmarking Terminology for Network
Interconnection Devices", RFC1242, July 1991.
[2] Mandeville, R., "Benchmarking Terminology for LAN Switching
Devices", RFC2285, February 1998.
[3] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC2544, March 1999.
[4] ANSI/IEEE, "CSMA/CD Access Method and Physical Layer
Specifications," ISO/IEC 8802-3, ISBN 0-7381-0330-6, 1998.
[5] IEEE Draft, "Frame Extensions for Virtual Bridged Local Area
Networks (VLAN) Tagging on 802.3 Networks", 802.3ac/D3.1, July
1998.
8. Authors' Addresses
Robert Mandeville
CQOS Inc.
21 Technology
Irvine, CA 92618
USA
Phone: +1 (949) 400-4444
EMail: bob@cqos.com
Jerry Perser
Spirent Communications
26750 Agoura Road
Calabasas, CA 91302
USA
Phone: + 1 818 676 2300
EMail: jerry_perser@netcomsystems.com
Appendix A: Formulas
A.1 Calculating the InterBurst Gap
IBG is defined in RFC2285 [2] as the interval between two bursts.
To achieve a desired load, the following Input Parameter need to be
defined:
LENGTH - Frame size in bytes including the CRC.
LOAD - The intended load in percent. Range is 0 to 100.
BURST - The number of frames in the burst (integer value).
SPEED - media's speed in bits/sec
Ethernet is 10,000,000 bits/sec
Fast Ethernet is 100,000,000 bits/sec
Gigabit Ethernet is 1,000,000,000 bits/sec
IFG - A constant 96 bits for the minimum interframe gap.
The IBG (in seconds) can be calculated:
[(100/LOAD - 1) * BURST * (IFG + 64 + 8*LENGTH)] + IFG
IBG = -----------------------------------------------------------
SPEED
A.2 Calculating the Number of Bursts for the Trial Duration
The number of bursts for the trial duration is rounded up to the
nearest integer number. The follow Input Parameter need to be
defined:
LENGTH - Frame size in bytes including the CRC.
BURST - The number of frames in the burst (integer value).
SPEED - media's speed in bits/sec
Ethernet is 10,000,000 bits/sec
Fast Ethernet is 100,000,000 bits/sec
Gigabit Ethernet is 1,000,000,000 bits/sec
IFG - A constant 96 bits for the minimum interframe gap.
IBG - Found in the above formula
DURATION - Trial duration in seconds.
An intermediate number of the Burst duration needs to be calculated
first:
TXTIME = -----------------------------------------
SPEED
Number of Burst for the Trial Duration (rounded up):
DURATION
#OFBURSTS = --------------
(TXTIME + IBG)
Example:
LENGTH = 64 bytes per frame
LOAD = 100 % offered load
BURST = 24 frames per burst
SPEED = 10 Mbits/sec (Ethernet)
DURATION = 10 seconds test
IBG = 1612.8 uS
TXTIME = 1603.2 uS
#OFBURSTS = 3110
Appendix B: Generating Offered Load
In testing, the traffic generator is configured with the Iload
(Intended Load) and measures the Oload (Offered Load). If the
DUT/SUT applies congestion control, then the Iload and the Oload are
not the same value. The question arises, how to generate the Oload?
This appendix will describe two different methods.
The unit of measurement for Oload is bits per second. The two
methods described here will hold one unit constant and let the
DUT/SUT vary the other unit. The traffic generator SHOULD specify
which method it uses.
B.1 Frame Based Load
Frame Based Load holds the number of bits constant. The Trial
Duration will vary based upon congestion control. Advantage is
implementation is a simple state machine (or loop). The disadvantage
is that Oload needs to be measured independently.
All ports on the traffic generator MUST transmit the exact number of
test frames. The exact number of test frames is found by multiplying
the Iload of the port by the Trial Duration. All ports MAY NOT
transmit the same number of frames if their Iload is not the same.
An example would be the Partially meshed many-to-one test.
All ports SHOULD start transmitting their frames within 1% of the
trial duration. For a trial duration of 30 seconds, all ports SHOULD
have started transmitting frames within 300 milliseconds of each
other.
The reported Oload SHOULD be the average during the Trial Duration.
If the traffic generator continues to transmit after the Trial
Duration due to congestion control, Oload MAY be averaged over the
entire transmit time. Oload for the DUT/SUT MUST be the aggregate of
all the Oloads per port. Oload per port MAY be reported.
B.2 Time Based Load
Time based load holds the Trial Duration constant, while allowing the
number of octets transmitted to vary. Advantages are an accurate
Trial Duration and integrated Oload measurement. Disadvantage is
that the starting and stopping of the traffic generator MUST be more
accurate.
All ports on the traffic generator are configured to transmit the
Iload for a finite amount of time. Each port MUST count the number
of octets successfully transmitted.
The start and stop is initiated at a layer defined by the test
parameters. The layer can be the MAC layer, IP layer, or some other
point in the protocol stack. The traffic generator MUST complete its
layer specific transmit process when the stop time is reached (i.e.
no fragments, finish the frame).
All ports MUST start transmitting their frames within 1% of the trial
duration. For a trial duration of 30 seconds, all ports SHOULD have
started transmitting frames within 300 milliseconds of each other.
All ports SHOULD stop transmitting frames after the specified trail
duration within 0.01% of the trial duration. Each port's stop time
MUST be reference to its start time. This trial duration error
controls the accuracy of the Oload measurement and SHOULD be reported
with the Oload measurement.
Each port is allowed an offset error of 0.1% and a trial duration
error of 0.01%.
Oload is found by taking the number of octets successfully
transmitted and dividing by the trial duration. Oload for the
DUT/SUT MUST be the aggregate of all the Oloads per port. Oload per
port MAY be reported for diagnostic purposes.
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.