RFC 2889
Benchmarking Methodology for LAN Switching Devices
RFC 2889 💖 Benchmarking Methodology for LAN Switching Devices
Network Working Group · Request for Comments: 2889 · August 2000 🎀
Authors: R. Mandeville (CQOS Inc.) and J. Perser (Spirent Communications) 👯♀️
Category: Informational 📚 This one gives info to the Internet community. It doesn't set an Internet standard.
Obsoletes / Updates: This title block doesn't list any RFCs that it obsoletes or updates. 🌸
Status of this Memo ✨
okay so this memo is informational, lowkey a reference doc, not a standard 🧚 Anyone can read it and it's unlimited to distribute. no cap 💅
Copyright Notice 🔒
Copyright (C) The Internet Society (2000). All Rights Reserved. 💜
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Test setup . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Frame formats and sizes . . . . . . . . . . . . . . . . . . . 3
5. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . . 3
5.1 Fully meshed throughput, frame loss and forwarding rates 4
5.2 Partially meshed one-to-many/many-to-one . . . . . . . . 7
5.3 Partially meshed multiple devices . . . . . . . . . . . . 10
5.4 Partially meshed unidirectional traffic . . . . . . . . . 13
5.5 Congestion Control . . . . . . . . . . . . . . . . . . . 16
5.6 Forward Pressure and Maximum Forwarding Rate . . . . . . 19
5.7 Address caching capacity . . . . . . . . . . . . . . . . 22
5.8 Address learning rate . . . . . . . . . . . . . . . . . . 25
5.9 Errored frames filtering. . . . . . . . . . . . . . . . . 27
5.10 Broadcast frame Forwarding and Latency . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
Appendix A: Formulas . . . . . . . . . . . . . . . . . . . . . 31
Appendix B: Generating Offered Load . . . . . . . . . . . . . 32
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 351. Introduction 🌈
okay bestie, this doc is basically the methodology for benchmarking LAN switching devices 🍓 It takes the playbook from RFC 2544 [3] and extends it to switches.
This RFC is mostly about devices that switch frames at the Medium Access Control (MAC) layer. It covers how to benchmark forwarding performance, congestion control, latency, address handling and filtering. It also explains how to report the test results in specific formats. 📊
There's a companion doc, "Benchmarking Terminology for LAN Switching Devices" [2], that defines a lot of the terms used here. You SHOULD read the terminology doc before you try to use this one. 📖✨
2. Requirements 🎀
Before you use this doc, you SHOULD check out RFC 1242 [1], RFC 2285 [2], and RFC 2544 [3]. 🧠
For clarity and continuity, this RFC uses the template for benchmarking tests from 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 doc extends the general test setup from section 6 of RFC 2544 [3] so it works for LAN switches. 🛠️ RFC 2544 mostly covers non-meshed traffic, where the input and output interfaces are split into mutually exclusive sending and receiving pairs. With fully meshed traffic, though, every interface on the DUT/SUT is set up to both receive and transmit frames to all the other interfaces under test. it's giving full mesh energy 🕸️✨
Before each test run, the DUT/SUT MUST learn the MAC addresses used in the test, and address learning SHOULD be verified. Addresses that aren't learned get forwarded as flooded frames, and that cuts down on the number of correctly forwarded frames 😭 The rate at which address learning frames are offered may need to drop to 50 frames per second or even lower so the learning actually succeeds. The DUT/SUT address aging time SHOULD be set to something greater than the learning phase of the test, plus the trial duration, plus any configuration time the testing device needs. Addresses SHOULD NOT age out until the trial duration is finished. It can take more than one learning trial before an address gets associated with a port. 🫶
If a DUT/SUT uses a hashing algorithm with address learning, it may not learn the addresses it needs to run the tests. 🙈 The format of the MAC addresses MUST be adjustable, so the address mapping can be rearranged and the DUT/SUT learns all of the addresses. 🔥
4. Frame formats and sizes 💅
The test frame format is defined in section 8 of RFC 2544 [3]. The frame MUST contain a unique signature field in the UDP DATA area of the Test Frame (see Appendix C [3]). The signature field's whole job is to filter out frames that aren't part of the offered load. 🗑️
The signature field MUST be unique enough to identify frames that didn't come from the DUT/SUT. It SHOULD be located after byte 56 (collision window [4]) or at the end of the frame. The length, contents and detection method are not defined in this memo. 🤷♀️
The signature field MAY have a unique identifier per port. That helps filter out misforwarded frames. It's possible for a DUT/SUT to strip off the MAC layer, send the frame through its switching matrix, and transmit it with the correct destination MAC address but the wrong payload. 😳
For frame sizes, check section 9 of RFC 2544 [3]. 📏
There are three possible frame formats for layer 2 Ethernet switches: standard MAC Ethernet frames, standard MAC Ethernet frames with vendor-specific tags added, and IEEE 802.3ac frames tagged to accommodate 802.1p&Q. 🏷️ The two types of tagged frames can go over the standard maximum length of 1518 bytes, and some DUT/SUT interface controllers might not accept them. It's recommended to check that the DUT/SUT is compatible with tagged frames before you start testing. ✅
Devices switching tagged frames over 1518 bytes will have a different maximum forwarding rate than they do with untagged frames. 📉
5. Benchmarking Tests 🎯
These tests offer objectives, procedures, and reporting formats for benchmarking LAN switching devices. 💜
5.1. Fully meshed throughput, frame loss and forwarding rates 🕸️
5.1.1. Objective 🎯
The goal is to determine the throughput, frame loss and forwarding rates of DUT/SUTs that get fully meshed traffic, as defined in RFC 2285 [2]. 💖
5.1.2. Setup Parameters 🎛️
When you offer full meshed traffic, the following parameters MUST be defined. Each one gets configured with these considerations:
- Frame Size: The recommended frame sizes are 64, 128, 256, 512, 1024, 1280 and 1518 bytes, per section 9 of RFC 2544 [3]. The four CRC bytes are included in the frame size you specify. 📦
- Interframe Gap (IFG): The IFG between frames inside a burst MUST be at the minimum the standard specifies for the medium being tested: 9.6 us for 10Mbps Ethernet, 960 ns for 100Mbps Ethernet, and 96 ns for 1 Gbps Ethernet. ⏱️
- Duplex mode: Half duplex or full duplex. 🔁
- ILoad: The intended load per port is expressed as a percentage of the medium's maximum theoretical load, no matter the traffic orientation or duplex mode. Some test configurations will theoretically over-subscribe the DUT/SUT. 📈
- In half duplex, an ILoad over 50% will over-subscribe the DUT/SUT. 🚨
- Burst Size: The burst size is the number of frames sent back-to-back at the minimum legal IFG [4] before transmission pauses to receive frames. Burst sizes SHOULD vary between 1 and 930 frames. A burst size of 1 will simulate constant load [1]. 🌊
- Addresses per port: This is how many addresses are being tested for each port. The number of addresses SHOULD be a binary exponential (i.e. 1, 2, 4, 8, 16, 32, 64, 128, 256, ...). The recommended value is 1. 🔢
- Trial Duration: The recommended trial duration is 30 seconds. The trial duration SHOULD be adjustable between 1 and 300 seconds. ⏳
5.1.3. Procedure 🧩
All ports on the tester MUST transmit test frames in either a Frame Based or Time Based mode (Appendix B). All ports SHOULD start transmitting within 1% of the trial duration. For a 30-second trial duration, all ports SHOULD have started transmitting frames within 300 milliseconds of each other. 🚦
Each port in the test MUST send test frames to all other ports in a round robin type fashion. The sequence of addresses MUST NOT change when congestion control is applied. The table below shows how each port in a test MUST transmit test frames to all the other ports in the test. In this example there are six ports with 1 address per port: 🔄
Source Port Destination Ports (in order of transmission)
Port #1 2 3 4 5 6 2...
Port #2 3 4 5 6 1 3...
Port #3 4 5 6 1 2 4...
Port #4 5 6 1 2 3 5...
Port #5 6 1 2 3 4 6...
Port #6 1 2 3 4 5 1...As the table shows, every transmit opportunity has an equal distribution of destination addresses. That keeps the test balanced, so no destination port gets overloaded by the test algorithm, and all the ports stay equally and fully loaded the whole time. Not following this algorithm exactly will produce inconsistent results. ⚖️
For tests using multiple addresses per port, the actual port destinations are the same as above, and the actual source/destination address pairs SHOULD be chosen randomly to exercise the DUT/SUT's ability to do address lookups. 🎲
For every address, learning frames MUST be sent to the DUT/SUT so it can update its address tables properly. 📝
5.1.4. Measurements 📐
Each port should receive the same number of test frames that it transmitted. Each receiving port MUST categorize the frames, then count them into one of two groups:
- 1.) Received Frames: received frames MUST have the correct destination MAC address and SHOULD match a signature field. 📥
- 2.) Flood count [2]. 🌊
Any frame that originates from the DUT/SUT (spanning tree, SNMP, RIP, ...) MUST not be counted as a received frame. Frames originating from the DUT/SUT MAY be counted as flooded frames or not counted at all. 🙅♀️
Frame loss rate of the DUT/SUT SHOULD be reported as defined in section 26.3 [3], with these notes: frame loss rate SHOULD be measured at the end of the trail duration. For this measurement only, the term "rate" doesn't imply units like "per second." 🧾
5.1.4.1. Throughput 🏆
Throughput measurement is defined in section 26.1 [3]. A search algorithm is used to find the maximum Oload [2] with a zero frame loss rate [1]. The algorithm MUST adjust Iload to find the throughput. 💜✨
5.1.4.2. Forwarding Rate
okay so 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 ✨
Forwarding rate at maximum offered load (FRMOL) MUST be reported as the number of test frames per second that a device can successfully transmit to the correct destination interface in response to the MOL, as defined in section 3.6 [2] 🎀 The MOL MUST also be cited 💖
Maximum forwarding rate (MFR) MUST be reported as the highest forwarding rate of a DUT/SUT taken from an iterative set of forwarding rate measurements 🔥 That iterative set is made by adjusting Iload, and the Oload applied to the device MUST also be cited 🫶
5.1.5. Reporting format
the results for these tests SHOULD be shown in a graph 📊 The x coordinate SHOULD be the frame size and the y coordinate SHOULD be the test results ✨ There SHOULD be at least two lines on the graph, one plotting the theoretical results and one plotting the test results 🦋
to check how well the DUT/SUT can switch traffic while doing lots of different address lookups, the number of addresses per port MAY be increased across a series of tests 🧚
5.2. Partially meshed one-to-many/many-to-one
5.2.1. Objective
this test is all about throughput when transmitting from and to multiple ports and to or from one port 🌸 Just like the fully meshed throughput test, it measures how well the DUT can switch frames without frame loss 💜 The results can show how well the DUT uses an Ethernet port when it's switching traffic that comes in from multiple Ethernet ports 👑
5.2.2. Setup Parameters
when offering bursty meshed traffic, the following parameters MUST be defined 📝 Each parameter gets configured with the following considerations:
- Frame Size: the recommended frame sizes are 64, 128, 256, 512, 1024, 1280 and 1518 bytes, per RFC 2544 section 9 [3] 🍓 The four CRC bytes are included in the frame size specified.
- Traffic Direction: traffic can be generated in one direction, the reverse direction, or both directions ↔️
- Interframe Gap (IFG): the IFG between frames inside a burst MUST be at the minimum specified by the standard of the medium being tested: 9.6 us for 10Mbps Ethernet, 960 ns for 100Mbps Ethernet, and 96 ns for 1 Gbps Ethernet 🌈
- Duplex mode: half duplex or full duplex 🎀
- ILoad: the intended load per port is expressed as a percentage of the medium's maximum theoretical load, no matter the traffic orientation or duplex mode 💅 Certain test configurations will theoretically over-subscribe the DUT/SUT 😭
- In half duplex bidirectional traffic, an ILoad over 50% will over-subscribe the DUT/SUT 💀
- Burst Size: the burst size is how many frames get sent back-to-back at the minimum legal IFG [4] before transmission pauses to receive frames 🦋 Burst sizes SHOULD vary between 1 and 930 frames 🔥 A burst size of 1 will simulate constant load [1] ✨
- Addresses per port: this is how many addresses are being tested for each port 🌸 The number of addresses SHOULD be a binary exponential (i.e. 1, 2, 4, 8, 16, 32, 64, 128, 256, ...) 💜 The recommended value is 1 💖
- Trial Duration: the recommended Trial Duration is 30 seconds ⏱️ The Trial duration SHOULD be adjustable between 1 and 300 seconds 🫶
5.2.3. Procedure
okay the procedure: all ports on the tester MUST transmit test frames in either a Frame Based or Time Based mode (Appendix B) 🧚 Depending on the traffic direction, some or all of the ports will be transmitting 🌈 All ports SHOULD start transmitting their frames within 1% of the trial duration 🫶 For a 30 second trial duration, all ports SHOULD have started transmitting frames within 300 milliseconds of each other ⏱️
test frames sent from the Many Ports MUST be destined for the One port 💅 Test frames sent from the One Port MUST be destined for the Many ports in a round robin type fashion 🎀 See section 5.1.3 for a description of the round robin fashion 🦋
for tests using multiple addresses per port, the actual port destinations are the same as described above 🌸 The actual source/destination address pairs SHOULD be chosen randomly so the DUT/SUT's ability to perform address lookups gets a real workout 💜
+----------+
| |
| Many | <--------
| | \
+----------+ \
\
+----------+ \ +-------------+
| | ------------> | |
| Many | <-----------------------> | One |
| | ------------> | |
+----------+ / +-------------+
/
+----------+ /
| | /
| Many | <-------
| |
+----------+for every address, the testing device MUST send learning frames so the DUT/SUT can update its address tables properly 🧠
5.2.4. Measurements
each receiving port MUST sort, then count, the frames into one of two groups 📊
- Received Frames: received frames MUST have the correct destination MAC address and SHOULD match a signature field ✨
- Flood count [2] 🌊
any frame originating from the DUT/SUT MUST not be counted as a received frame 🙈 Frames originating from the DUT/SUT MAY be counted as flooded frames or not counted at all 🫶
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 transmit to the correct destination interface in response to a specified Oload 💅 The Oload MUST also be cited ✨
Forwarding rate at maximum offered load (FRMOL) MUST be reported as the number of test frames per second that a device can successfully transmit to the correct destination interface in response to the MOL, as defined in section 3.6 [2] 🎀 The MOL MUST also be cited 💖
Maximum forwarding rate (MFR) MUST be reported as the highest forwarding rate of a DUT/SUT taken from an iterative set of forwarding rate measurements 🔥 That iterative set is made by adjusting Iload, and the Oload applied to the device MUST also be cited 🫶
5.2.5. Reporting Format
the results for these tests SHOULD be shown in a graph 📊 The x coordinate SHOULD be the frame size and the y coordinate SHOULD be the test results ✨ There SHOULD be at least two lines on the graph, one plotting the theoretical results and one plotting the test results 🦋
to check how well the DUT/SUT can switch traffic while doing lots of different address lookups, the number of addresses per port MAY be increased across a series of tests 🧚
5.3. Partially meshed multiple devices
5.3.1. Objective
this one checks throughput, frame loss and forwarding rates for two switching devices with multiple ports and one high speed backbone uplink (Gigabit Ethernet, ATM, SONET) 🚀
5.3.2. Setup Parameters
when offering bursty partially meshed traffic, the following parameters MUST be defined 📝 Each variable gets configured with the following considerations:
- Frame Size: the recommended frame sizes are 64, 128, 256, 512, 1024, 1280 and 1518 bytes, per RFC 2544 section 9 [3] 🍓 The four CRC bytes are included in the frame size specified.
- Interframe Gap (IFG): the IFG between frames inside a burst MUST be at the minimum specified by the standard of the medium being tested: 9.6 us for 10Mbps Ethernet, 960 ns for 100Mbps Ethernet, and 96 ns for 1 Gbps Ethernet 🌈
- Duplex mode: half duplex or full duplex 🎀
- ILoad: the intended load per port is expressed as a percentage of the medium's maximum theoretical load, no matter the traffic orientation or duplex mode 💅 Certain test configurations will theoretically over-subscribe the DUT/SUT 😭
- In half duplex, an ILoad over 50% will over-subscribe the DUT/SUT 💀
- Burst Size: the burst size is how many frames get sent back-to-back at the minimum legal IFG [4] before transmission pauses to receive frames 🦋 Burst sizes SHOULD vary between 1 and 930 frames 🔥 A burst size of 1 will simulate constant load [1] ✨
- Addresses per port: this is how many addresses are being tested for each port 🌸 The number of addresses SHOULD be a binary exponential (i.e. 1, 2, 4, 8, 16, 32, 64, 128, 256, ...) 💜 The recommended value is 1 💖
- Trial Duration: the recommended Trial Duration is 30 seconds ⏱️ The Trial duration SHOULD be adjustable between 1 and 300 seconds 🫶
- Local Traffic: a Boolean value of ON or OFF 🔀 The frame sequence algorithm MAY be altered to remove local traffic 🙌 With local traffic ON, the algorithm is exactly the same as a fully meshed throughput test 💖 With local traffic OFF, the port sends frames to all other ports on the other side of the backbone uplink in a round robin type fashion 🧚
5.3.3. Procedure
all ports on the tester MUST transmit test frames in either a Frame Based or Time Based mode (Appendix B) 🧚 All ports SHOULD start transmitting their frames within 1% of the trial duration 🫶 For a 30 second trial duration, all ports SHOULD have started transmitting frames within 300 milliseconds of each other ⏱️
each port in the test MUST send test frames to all other ports in a round robin type fashion, as defined in section 5.1.3 🎀 Local traffic MAY be removed from the round robin list so the entire load goes across the backbone uplink 🚀
for tests using multiple addresses per port, the actual port destinations are the same as described above 🌸 The actual source/destination address pairs SHOULD be chosen randomly so the DUT/SUT's ability to perform address lookups gets tested properly 💜
for every address, the testing device MUST send learning frames so the DUT/SUT can update its address tables properly 🧠
to check how well the DUT/SUT can switch traffic while doing lots of different address lookups, the number of addresses per port MAY be increased across a series of tests 🧚
5.3.4. Measurements
each receiving port MUST sort, then count, the frames into one of two groups 📊
- Received frames: received frames MUST have the correct destination MAC address and SHOULD match a signature field ✨
- Flood count [2] 🌊
any frame originating from the DUT/SUT MUST not be counted as a received frame 🙈 Frames originating from the DUT/SUT MAY be counted as flooded frames or not counted at all 🫶
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 units in the fashion of "per second" 💅
5.3.4.1. Throughput
throughput measurement is defined in section 26.1 [3] 🌟 A search algorithm is used to find the maximum Oload [2] with a zero Frame loss rate [1] 🔍 The algorithm MUST adjust Iload to find the throughput 👑
5.3.4.2 Forwarding rate
okay so forwarding rate (FR) is basically how many test frames per second the DUT/SUT actually forwards to the correct destination interface for a given Oload 💖 this SHOULD get reported, and you MUST also cite the Oload you used. no skipping that part bestie 🫶
forwarding rate at maximum offered load (FRMOL) is the frames-per-second number a device can successfully push out to the correct destination in response to the MOL from section 3.6 [2] ✨ the MOL MUST be cited too, obvi.
maximum forwarding rate (MFR) is the highest forwarding rate you get from a whole bunch of forwarding rate measurements 🦋 to build that set, you keep adjusting Iload, and the Oload applied to the device MUST also be cited. main character energy for sure 👑
5.3.5 Reporting format
these results SHOULD be shown as a graph 📊 the x coordinate SHOULD be the frame size and the y coordinate SHOULD be the test results. there SHOULD be at least two lines on that graph: one for the theoretical numbers and one for the actual test results 🌈
and if you wanna check how well the DUT/SUT switches traffic while it's doing a ton of different address lookups 🧚 the number of addresses per port MAY be increased across a series of tests. iykyk 💜
5.4 Partially meshed unidirectional traffic
5.4.1 Objective
this one is about finding the throughput of the DUT/SUT when it's hit with a bunch of unidirectional streams 🌸 like, half the ports are sending frames to the other half of the ports. it's giving traffic jam but make it organized 💅
5.4.2 Setup Parameters
okay so these parameters MUST be defined 📋 each variable has its own little rules, so read carefully bestie 🎀
- Frame Size: recommended frame sizes are 64, 128, 256, 512, 1024, 1280 and 1518 bytes, per RFC 2544 section 9 [3]. the four CRC bytes are counted inside the frame size you pick ✨
- Interframe Gap (IFG): the IFG between frames inside a burst MUST be the minimum the standard says for the medium being tested. that's 9.6 us for 10Mbps Ethernet, 960 ns for 100Mbps Ethernet, and 96 ns for 1 Gbps Ethernet 🍓
- Duplex mode: half duplex or full duplex 🦋
- ILoad: the intended load per port, written as a percentage of the medium's maximum theoretical load, no matter the traffic orientation or duplex mode 💖 some test setups will theoretically over-subscribe the DUT/SUT, but ILoad will not over-subscribe the DUT/SUT in this test 🙈
- Burst Size: this is how many frames get sent back-to-back at the minimum legal IFG [4] before the transmitter pauses to receive frames 🍭 burst sizes SHOULD vary between 1 and 930 frames. a burst size of 1 will simulate constant load [1] 💜
- Addresses per port: how many addresses are being tested for each port 🌈 the number of addresses SHOULD be a binary exponential (like 1, 2, 4, 8, 16, 32, 64, 128, 256, ...). the recommended value is 1 🎀
- Trial Duration: the recommended Trial Duration is 30 seconds ⏱️ the trial duration SHOULD be adjustable between 1 and 300 seconds ✨
5.4.3 Procedure
so ports don't send and receive test frames at the same time 🙌 that means there should be no collisions unless the DUT is misforwarding frames, generating flooded or Spanning-Tree frames, or is enabling some flow control mechanism 🚦 each port is either transmitting or receiving, never both. the transmitting ports send test frames to addresses that belong to each of the receiving ports, and boom, you've got a unidirectional mesh 🕸️✨
all ports on the tester MUST transmit test frames in either a Frame Based or Time Based mode (Appendix B) 💅 all ports SHOULD start transmitting within 1% of the trial duration. for a 30 second trial duration, all ports SHOULD have started transmitting frames within 300 milliseconds of each other ⏰
each transmitting port MUST send frames to all of the receiving ports in a round robin kind of way 🔁 the sequence of addresses MUST NOT change when congestion control is applied. here's the table showing how each port has to send test frames to all the other ports. in this 8 port example, ports 1 through 4 are transmitting and ports 5 through 8 are receiving, with 1 address per port 🫶
Source Port, then Destination Ports (in order of transmission)
Port #1 5 6 7 8 5 6...
Port #2 6 7 8 5 6 7...
Port #3 7 8 5 6 7 8...
Port #4 8 5 6 7 8 5...see how every transmit opportunity gives each destination an equal share? 💖 that keeps things balanced, so no single destination port gets overloaded by the algorithm and all the receiving ports are equally and fully loaded the whole time. if you don't follow this algorithm exactly, you'll product inconsistent results 💀
for tests with multiple addresses per port, the actual port destinations stay the same as above, but the source/destination address pairs SHOULD be picked randomly to really test the DUT/SUT's address lookups 🎲
for every address, the testing device MUST send learning frames so the DUT/SUT can load its address tables properly 🧠 the address table's aging time SHOULD be set way longer than the learning time and trial duration combined ⏳ if the address table ages out mid-test, the results will show a lower performing DUT/SUT, so don't let that happen bestie 😭
and again, to measure how well the DUT/SUT switches while doing many different address lookups 🧚 the number of addresses per port MAY be increased in a series of tests 💜
5.4.4 Measurements
each receiving port MUST sort and then count frames into one of two groups 🗂️
- Received Frames: received frames MUST have the correct destination MAC address and SHOULD match a signature field ✨
- Flood count [2].
any frame that comes from the DUT/SUT MUST not be counted as a received frame 🙅♀️ frames originating from the DUT/SUT MAY be counted as flooded frames, or not counted at all 🌸
the frame loss rate of the DUT/SUT SHOULD be reported as defined in section 26.3 [3], with a couple of notes 📝 the frame loss rate SHOULD be measured at the end of the trial duration. and the word "rate" here, just for this measurement, doesn't mean "per second" 🙈
5.4.4.1 Throughput
throughput is defined in section 26.1 [3] 🦋 a search algorithm finds the maximum Oload [2] with a zero frame loss rate [1]. the algorithm MUST adjust Iload to find the throughput 💖
5.4.4.2 Forwarding rate
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.
forwarding rate at maximum offered load (FRMOL) MUST be reported as the number of test frames per second that a device can successfully transmit to the correct destination interface in response to the MOL as defined in section 3.6 [2] ✨ the MOL MUST also be cited.
maximum forwarding rate (MFR) MUST be reported as the highest forwarding rate of a DUT/SUT taken from an iterative set of forwarding rate measurements 👑 those measurements are made by adjusting Iload, and the Oload applied to the device MUST also be cited.
5.4.5 Reporting format
these results SHOULD be reported as a graph 📊 the x coordinate SHOULD be the frame size and the y coordinate SHOULD be the test results. there SHOULD be at least two lines on the graph, one for the theoretical numbers and one for the test results 🌈
and once more, to measure the DUT/SUT's ability to switch traffic while doing lots of different address lookups 🧚 the number of addresses per port MAY be increased in a series of tests 💜
5.5 Congestion Control
5.5.1 Objective
this one is all about how a DUT handles congestion 🚨 does the device actually implement congestion control? and does congestion on one port spill over and mess with a port that's totally fine? this procedure figures out if Head of Line Blocking and/or Backpressure are showing up 😭🔥
5.5.2 Setup Parameters
the following parameters MUST be defined 📋 each variable comes with its own considerations, so pay attention bestie 🎀
- Frame Size: recommended frame sizes are 64, 128, 256, 512, 1024, 1280 and 1518 bytes, per RFC 2544 section 9 [3]. the four CRC bytes are included in the frame size specified ✨
- Interframe Gap (IFG): the IFG between frames inside a burst MUST be the minimum the standard specifies for the medium being tested: 9.6 us for 10Mbps Ethernet, 960 ns for 100Mbps Ethernet, and 96 ns for 1 Gbps Ethernet 🍓
- Duplex mode: half duplex or full duplex 🦋
- Addresses per port: how many addresses are being tested for each port 🌈 the number of addresses SHOULD be a binary exponential (like 1, 2, 4, 8, 16, 32, 64, 128, 256, ...). the recommended value is 1 🎀
- Trial Duration: the recommended Trial Duration is 30 seconds ⏱️ the trial duration SHOULD be adjustable between 1 and 300 seconds ✨
that's the whole vibe for this part bestie, more to come 🦋💜
5.5.3 Procedure
okay so bestie, this test MUST consist of a multiple of four ports, all with the same MOL 💅✨ Four ports are REQUIRED, and you MAY expand in increments of four to fully flex on the DUT/SUT 🦋 Each group of four is a test block with two source transmitters and two receivers. Here's the traffic flow, and it's giving main character energy:
+----------+ 50 % MOL +-------------+
| | ------------------------> | |
| | 50 % MOL | uncongested |
| | --------- | |
+----------+ \ +-------------+
\
\
\
+----------+ \ +-------------+
| | ---------> | |
| | 100 % MOL | congested |
| | ------------------------> | |
+----------+ +-------------+Both source transmitters MUST send the exact same number of test frames 🎀 The first source MUST send test frames at the MOL, alternating the destination between the two receive ports. So one goes to the uncongested receive port, the next goes to the congested one, and then it repeats 🔁 The second source transmitter MUST send test frames at the MOL, but only to the congested receive port. Very focused, very intentional 😤
Both receive ports SHOULD tell apart test frames coming from the source ports and frames coming from the DUT/SUT 🧚 Only the test frames from the source ports SHOULD be counted, because we only want our girls in the count 💖
Here's the vibe check for the numbers. The uncongested receive port should be receiving at half the MOL 🌸 The number of test frames received on the uncongested port SHOULD be 50% of the test frames the first source transmitter sent. The congested receive port should be receiving at the MOL 🔥 The number of test frames received on the congested port should be between 100% and 150% of the test frames sent by one source transmitter. Iconic range, no notes ✨
Test frames headed for uncongested ports in a switch device should not get dropped just because other ports are congested 😭 That's true even when the source is sending to both the congested and the uncongested ports. Protect the uncongested ones at all costs 🫶
5.5.4 Measurements
Any frame received without the correct destination address MUST not be counted as a received frame 🙈 It SHOULD be counted as part of a flood count instead, bye bye 👋
Any frame coming from the DUT/SUT MUST not be counted as a received frame 💅 Frames from the DUT/SUT MAY be counted as flooded frames, or they may not be counted at all. Totally your call, babe 🌈
The frame loss rate of the DUT/SUT's congested and uncongested ports MUST be reported as defined in section 26.3 [3], with a few extra notes 📝 The frame loss rate SHOULD be measured at the end of the trial duration. And for this measurement only, the word "rate" does not mean units "per second," so don't let your brain go there 🧠💀
The Offered Load to the DUT/SUT MUST be reported as the number of test frames per second that the DUT/SUT was observed to accept 🍓 This may be different from the MOL, so don't panic if the numbers don't match 🥰
The forwarding rate (FR) of the DUT/SUT's congested and uncongested ports MUST be reported as the number of test frames per second that the device is observed to successfully transmit to the correct destination interface, in response to a specified offered load ✨ The offered load MUST also be cited. Receipts, please 🧾
5.5.5 Reporting format
This test MUST report the frame lost rate at the uncongested port, the forwarding rate (at 50% offered load) at the uncongested port, and the frame lost rate at the congested port 📊 This test MAY report the frame counts transmitted and the frame counts received by the DUT/SUT. Extra receipts are optional but cute 💜
5.5.5.1 HOLB
If there's frame loss at the uncongested port, then "Head of Line" blocking is present 😩 The DUT can't forward the traffic going to the congested port, so it ends up losing frames meant for the uncongested port too. Not the vibe 💔
5.5.5.2 Back Pressure
If there's no frame loss on the congested port, then backpressure is present 🌬️ It's worth noting that this test expects the overall load to the congested port to be greater than 100%. So if the load is greater than 100% and no frame loss is detected, then the DUT must be implementing a flow control mechanism 🦋 The type of flow control mechanism used is beyond the scope of this memo, so we're not going there today 🙅♀️
Also, some DUTs might not be able to handle the 100% load presented at the input port 😵 In that case, there may be frame loss reported at the uncongested port, and it comes from the load at the input port rather than the congested port's load. Not the congested port's fault, tea ☕
If the uncongested frame loss is reported as zero, but the maximum forwarding rate is less than 7440 (for 10Mbps Ethernet), then this may be an indication of congestion control being enforced by the DUT 🧐 In that case, the congestion control is affecting the throughput of the uncongested port. Sneaky 👀
If no congestion control is detected, the expected percentage frame loss for the congested port is 33% at 150% overload 🍰 It's receiving 100% load from one port and 50% from another, and it can only get 100% possible throughput. So the frame loss rate is 33% (150%-50%/150%). Math is mathing 🧮✨
5.6 Forward Pressure and Maximum Forwarding Rate 🌸
5.6.1 Objective
The Forward Pressure test overloads a DUT/SUT port and measures the output for forward pressure [2] 💥 If the DUT/SUT transmits frames with an interframe gap less than 96 bits (section 4.2.3.2.2 [4]), then forward pressure is detected 🚨
The objective of the Maximum Forwarding Rate test is to measure the peak value of the Forwarding Rate when the Offered Load is varied between the throughput [1] and the Maximum Offered Load [2] 📈 Peak performance era 🏆
5.6.2 Setup Parameters
The following parameters MUST be defined 📋 Each variable is configured with the considerations below.
- Frame Size: Recommended frame sizes are 64, 128, 256, 512, 1024, 1280 and 1518 bytes, per RFC 2544 section 9 [3]. The four CRC bytes are included in the frame size specified 🎀
- Duplex mode: Half duplex or full duplex 🔁
- Trial Duration: The recommended Trial Duration is 30 seconds ⏱️ Trial duration SHOULD be adjustable between 1 and 300 seconds 💅
- Step Size: The minimum incremental resolution that the Iload will be incremented in frames per second 🪜 The smaller the step size, the more accurate the measurement and the more iterations required. As the Iload approaches the MOL, the minimum step size will increase because of gap resolution on the testing device 🤓
5.6.3 Procedure
5.6.3.1 Maximum forwarding rate
If the Throughput [1] and the MOL [2] are the same, then MFR [2] is equal to the MOL [2] 👑
This test MUST at a minimum be performed in a two-port configuration, as described below 🦋 Learning frames MUST be sent so the DUT/SUT can update its address tables properly 📚
Test frames are transmitted to the first port (port 1) of the DUT/SUT at the Iload 🚀 The FR [2] on the second port (port 2) of the DUT/SUT is measured. The Iload is incremented by each Step Size to find the MFR 🔍 Here's the algorithm, bestie:
CONSTANT
MOL = ... frames/sec; {Maximum Offered Load}
VARIABLE
MFR := 0 frames/sec; {Maximum Forwarding Rate}
ILOAD := starting throughput in frames/sec; {offered load}
STEP := ... frames/sec; {Step Size}
BEGIN
ILOAD := ILOAD - STEP;
DO
BEGIN
ILOAD := ILOAD + STEP
IF (ILOAD > MOL) THEN
BEGIN
ILOAD := MOL
END
AddressLearning; {Port 2 broadcasts with its source address}
Transmit(ILOAD); {Port 1 sends frames to Port 2 at Offered load}
IF (Port 2 Forwarding Rate > MFR) THEN
BEGIN
MFR := Port 2 Forwarding Rate; {A higher value than before}
END
END
WHILE (ILOAD < MOL); {ILOAD has reached the MOL value}
DONE5.6.3.2 Minimum Interframe Gap
The Minimum Interframe gap test SHOULD, at a minimum, be performed in a two-port configuration as described below 🧪 Learning frames MUST be sent so the DUT/SUT can update its address tables properly 🗂️
Test frames SHOULD be transmitted to the first port (port 1) of the DUT/SUT with an interframe gap of 88 bits 💨 This applies forward pressure to the DUT/SUT and overloads it at a rate of one byte per frame 😤 The test frames MUST be constructed with a source address of port 1 and a destination address of port 2 🎯
The FR on the second port (port 2) of the DUT/SUT is measured 📏 The measured Forwarding Rate should not exceed the medium's maximum theoretical utilization (MOL) 🙅♀️
5.6.4 Measurements
Port 2 MUST categorize, then count the frames into one of two groups 🗂️
- Received Frames: received frames MUST have the correct destination MAC address and SHOULD match a signature field 💖
- Flood count [2] 🌊
Any frame coming from the DUT/SUT MUST not be counted as a received frame 🙈 Frames from the DUT/SUT MAY be counted as flooded frames, or they may not be counted at all 🤷♀️
5.6.5 Reporting format
MFR MUST be reported as the highest forwarding rate of a DUT/SUT, taken from an iterative set of forwarding rate measurements 🏆 The Iload applied to the device MUST also be cited.
The forwarding rate (FR) of the DUT/SUT SHOULD be reported as the number of frames per second that the device is observed to successfully transmit to the correct destination interface in response to a specified Oload 💫 The Iload MUST be cited, and the Oload MAY be recorded 📝
If the FR exceeds the MOL during the Minimum Interframe gap test, this MUST be highlighted with the expression "Forward Pressure detected" 🚨🚨
5.7 Address Caching Capacity 🧚
5.7.1 Objective
The goal is to determine the address caching capacity of a LAN switching device, as defined in RFC 2285, section 3.8.1 [2] 🎯
5.7.2 Setup Parameters
The following parameters MUST be defined 📋 Each variable is configured with the considerations below.
- Age Time: The maximum time that a DUT/SUT will keep a learned address in its forwarding table ⏳
- Addresses Learning Rate: The rate at which new addresses are offered to the DUT/SUT to be learned. 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 🐢
- Initial Addresses: The initial number of addresses to start the test with. The number MUST be between 1 and the maximum number supported by the implementation 🔢
5.7.3 Procedure ✨
Okay bestie, first things first 💅 The DUT/SUT's aging time has to be known, because that's the timer that wipes out learned addresses 🕰️. The aging time MUST be longer than the time it takes to produce frames at the specified rate. If you go with a low frame rate, sending a huge pile of frames could actually take longer than the aging time, which is kinda sneaky 🙈
This test MUST at a minimum be run in the three-port setup below 🎀 You MAY grow it to fully utilize the DUT/SUT in steps of two or three ports. A step of two adds one extra Learning port and one extra Test port. A step of three adds one extra Learning port, one extra Test port, and one extra Monitoring port 🦋
Now the ports, bestie 🧚
- The Learning port (Lport) sends learning frames to the DUT/SUT. Each frame has a different source address, and they all have one fixed destination address, which is the address of the device plugged into the Test port (Tport) of the DUT/SUT. By seeing frames with all these different source addresses, the DUT/SUT should learn them. The source addresses MAY be in sequential order 🌸
- The Test port (Tport) of the DUT/SUT is the receiving port for the learning frames. Test frames get sent back out toward the addresses that were learned on the Learning port. The algorithm for this is coming up next 👑
- The Monitoring port (Mport) on the DUT/SUT is the watcher 👀 It listens for flooded or mis-forwarded frames. If the test spans multiple broadcast domains (VLANs), each broadcast domain REQUIRES a Monitoring port 💜
It is highly recommended that SNMP, Spanning Tree, and any other frames coming from the DUT/SUT get turned off while you run this test 🫶 If those protocols can't be turned off, the flood count MUST be modified so that it only counts test frames that come from Lport, and it MUST NOT count frames that come from the DUT/SUT itself. Don't let the DUT's own chatter mess with your numbers 😭
Here's the algorithm, and it's giving binary search energy 🔍
CONSTANT
AGE = ...; {value greater that DUT aging time}
MAX = ...; {maximum address support by implementation}
VARIABLE
LOW := 0; {Highest passed valve}
HIGH := MAX; {Lowest failed value}
N := ...; {user specified initial starting point}
BEGIN
DO
BEGIN
PAUSE(AGE); {Age out any learned addresses}
AddressLearning(TPort); {broadcast a frame with its source
Address and broadcast destination}
AddressLearning(LPort); {N frames with varying source addresses
to Test Port}
Transmit(TPort); {N frames with varying destination addresses
corresponding to Learning Port}
IF (MPort receive frame != 0) OR
(LPort receive frames < TPort transmit) THEN
BEGIN {Address Table of DUT/SUT was full}
HIGH := N;
END
ELSE
BEGIN {Address Table of DUT/SUT was NOT full}
LOW := N;
END
N := LOW + (HIGH - LOW)/2;
END WHILE (HIGH - LOW >= 2);
END {Value of N equals number of addresses supported by DUT/SUT}Because it's a binary search, the test lands on the exact number of addresses supported per port while keeping every iteration consistent 🍓 The catch is that each iteration might spend some time just waiting for the DUT/SUT's address tables to clear, thanks to the aging time. So if you can, set the DUT/SUT to a low aging time value, it'll save you so much waiting ⏳
Once the high and low values of N meet, boom, you've found the threshold of address handling 🎉
5.7.4 Measurements
The big question here is whether the offered addresses per port got forwarded successfully without any flooding 🦋
5.7.5 Reporting format
After the test runs, the results for each iteration SHOULD be shown in a table that includes the following 📊
- The number of addresses used for each test iteration (varied) 🌈
- The intended load used for each test iteration (fixed) ⭐
- The number of test frames that were offered to Tport of the DUT/SUT. This SHOULD match the number of addresses used for the test iteration. Test frames are the frames sent with varying destination addresses, and they confirm that the DUT/SUT has learned every address for each test iteration 💅
- The flood count on Tport during the test portion of each test. If the number isn't zero, that means the DUT/SUT flooded a frame whose destination address wasn't in its address table 🙈
- The number of frames correctly forwarded to the 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 equal the number of frames transmitted by Tport 🔥
- The flood count on Lport during the test portion of each test. If the number isn't zero, that means the DUT/SUT flooded a frame whose destination address wasn't in its address table 💀
- The flood count on Mport. If the value isn't zero, that means the DUT/SUT couldn't figure out the proper destination port for that many frames. In other words, its address table was full, so it flooded those frames to all ports 😭
5.8 Address Learning Rate
5.8.1 Objective
The goal is to figure out the rate of address learning for a LAN switching device 🧚
5.8.2 Setup Parameters
The following parameters MUST be defined. Each variable gets configured with the considerations below 📝
- Age Time - The maximum time that a DUT/SUT will keep a learned address in its forwarding table ⏰
- Initial Addresses Learning Rate - The starting rate at which new addresses are offered to the DUT/SUT to be learned 🌸
- Number of Addresses - The number of addresses that the DUT/SUT must learn. The number MUST be between 1 and the maximum number supported by the implementation. It is recommended no to exceed the address caching capacity found in section 5.9 💜
5.8.3 Procedure
The aging time of the DUT/SUT MUST be known. The aging time MUST be longer than the time necessary to produce frames at the specified rate. If a low frame rate is used, sending a large amount of frames might actually take longer than the aging time, so keep an eye on that 👀
This test MUST at a minimum be run in the three-port configuration in section 5.9.3. You MAY expand it to fully utilize the DUT/SUT in steps of two or three ports. A step of two adds an extra Learning port and Test port. A step of three adds an extra Learning port, Test port, and Monitoring port 🎀
An algorithm similar to the one for address caching capacity can be used to find the address learning rate 🦋 This test cycles through the rate at which address learning frames get 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 get determined for different numbers of addresses, but in each test run the number MUST remain constant, and it SHOULD be equal to or less than the maximum address caching capacity 🫶
5.8.4 Measurements
The question here is whether the offered addresses per port were successfully forwarded without flooding at the offered learning rate 🌈
5.8.5 Reporting format
After the test runs, the results for each iteration SHOULD be shown in a table 📊
- The number of addresses used for each test iteration (fixed) ⭐
- The intended load used for each test iteration (varied) 🔥
- The 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 isn't zero, that means the DUT/SUT flooded a frame whose destination address wasn't in its address table 🙈
- The number of frames correctly forwarded to the 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 equal the number of frames transmitted by Tport 🍓
- The flood count on Lport during the test portion of each test. If the number isn't zero, that means the DUT/SUT flooded a frame whose destination address wasn't in its address table 💀
- The flood count on Mport. If the value isn't zero, that means the DUT/SUT couldn't figure out the proper destination port for that many frames. In other words, its address table was full, so it flooded those frames to all ports 😭
5.9 Errored frames filtering
5.9.1 Objective
The point of the Errored frames filtering test is to see how the DUT behaves when it gets error or abnormal frame conditions 🧐 The results tell you whether the DUT/SUT filters out the errors, or just passes the errored frames along to the destination 🦋
5.9.2 Setup Parameters
The following parameters MUST be defined. Each variable gets configured with the considerations below 📝
- ILoad - The intended load per port, expressed as a percentage of the medium's maximum theoretical load. The actual transmitted frames per second depend on whether the link is running half duplex or full duplex. The test SHOULD be run multiple times, with a different load per port each time 🌸
- 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, so let's go through them one by one 💅
- 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. A DUT/SUT that supports 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 on an octet boundary but do 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 on 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 on an octet boundary. This is a combination of a CRC error and a Dribble Bit error. When both errors show up in the same frame, the DUT/SUT MUST determine that the CRC error takes precedence and filters the frame (section 4.2.4.1.2 [4]) from being propagated 💀
5.9.5 Reporting format
Okay bestie, for each error condition in section 5.6.3, a "pass" or "fail" MUST be reported ✅❌. Actual frame counts MAY be reported too if you want the diagnostic details 🔍💖
5.10 Broadcast frame Forwarding and Latency
5.10.1 Objective
Okay so this test is all about how well the DUT handles broadcast traffic 📡✨ It's about throughput and latency. Forwarding broadcast frames depends on a special function that the device has built in just for that job, and since every vendor can build that function a different way, we need to check how the DUT/SUT handles broadcast frames specifically 🦋
5.10.2 Setup Parameters
The following parameters MUST be defined 📝 Here's how each one gets configured:
- Frame Size: Recommended frame sizes are 64, 128, 256, 512, 1024, 1280 and 1518 bytes, per RFC 2544 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 as a percentage of the medium's maximum theoretical load, regardless of traffic orientation or duplex mode. Some 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
There are two parts to run here, bestie 🧚
Broadcast Frame Throughput: One source test port transmits test frames with a broadcast address, using the frame specified in RFC 2544 [3]. Then the selected receive ports measure the forwarding rate and frame loss rate 📊
Broadcast Frame Latency: Same setup as the Broadcast Frame Throughput test, but this time instead of a big stream, only ONE test frame gets sent 🦩 Then we measure the latency to each receive port, in seconds ⚡
5.10.4 Measurements
Frame loss rate of the DUT/SUT SHOULD be reported as defined in section 26.3 [3], with these notes 🧐 Frame loss rate SHOULD be measured at the end of the trial duration. For this measurement only, "rate" does not mean "per second," so don't get confused 🙈
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
Results for these tests SHOULD be reported as a graph 📈 The x coordinate SHOULD be the frame size and the y coordinate SHOULD be the test results. There SHOULD be at least two lines on the graph, one for the theoretical and one for the test results 💜
Also, to see how well the DUT/SUT can switch traffic while doing lots of different address lookups, the number of addresses per port MAY be increased across a series of tests 🌈
6. Security Considerations
Okay, real talk, this one's chill 🫶 This document is only about metric methodology. It doesn't describe a protocol or how a protocol gets implemented, so there are no security considerations associated with it 🔐✨
7. References
- [1] Bradner, S., Editor, "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991. 📚
- [2] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998. 📚
- [3] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, 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
Here are the authors' contact deets 💌
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.comAppendix A: Formulas
Time for the math, and it's actually giving pretty 🧮✨
A.1 Calculating the InterBurst Gap
IBG is defined in RFC 2285 [2] as the interval between two bursts ⏳ To hit a desired load, you need to define these input parameters 💕
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.Then the IBG (in seconds) can be calculated like this 🧠
[(100/LOAD - 1) * BURST * (IFG + 64 + 8*LENGTH)] + IFG
IBG = -----------------------------------------------------------
SPEEDA.2 Calculating the Number of Bursts for the Trial Duration
The number of bursts for the trial duration gets rounded up to the nearest integer 🔢 Here are the input parameters you need to define first 🌸
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.First up, calculate the burst duration as an intermediate number ⏱️
TXTIME = -----------------------------------------
SPEEDThen the number of bursts for the trial duration (rounded up) 🎯
DURATION
#OFBURSTS = --------------
(TXTIME + IBG)Example time, bestie 🍓
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 = 3110Appendix B: Generating Offered Load
So when you run a test, the traffic generator gets set to the Iload (Intended Load) and then measures the Oload (Offered Load) 💅 If the DUT/SUT does congestion control, the Iload and Oload won't match, and then the big question is: how do you generate the Oload? 🤔 This appendix covers two methods.
The Oload unit is bits per second. Both methods hold one unit constant and let the DUT/SUT vary the other one 🦋 The traffic generator SHOULD specify which method it uses 📢
B.1 Frame Based Load
Frame Based Load holds the number of bits constant, so the Trial Duration changes depending on congestion control ⏳ The upside is that the implementation is a simple state machine (or loop) 🧚 The downside is that Oload has to be measured on its own 😩
All ports on the traffic generator MUST transmit the exact number of test frames 💯 That number comes from multiplying each port's Iload by the Trial Duration. If the Iloads aren't all the same, the ports MAY NOT transmit the same number of frames. A partially meshed many-to-one test is an example of that 🕸️
All ports SHOULD start transmitting their frames within 1% of the trial duration. For a 30 second trial duration, that means 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 keeps transmitting after the Trial Duration because of congestion control, the Oload MAY be averaged over the entire transmit time ⏰ The Oload for the DUT/SUT MUST be the aggregate of all the per-port Oloads ➕ Oload per port MAY be reported 🎀
B.2 Time Based Load
Time based load holds the Trial Duration constant and lets the number of octets transmitted vary 🌈 The perks are an accurate Trial Duration and an integrated Oload measurement 🫶 The catch 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 it successfully transmitted 🔢
The start and stop get triggered at a layer defined by the test parameters. That layer could be the MAC layer, the IP layer, or some other point in the protocol stack 🧱 When the stop time hits, the traffic generator MUST complete its layer-specific transmit process (no fragments, finish the frame) 🏁
All ports MUST start transmitting their frames within 1% of the trial duration. For a 30 second trial duration, 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, so it SHOULD be reported along with the Oload measurement 📝
Each port gets an offset error allowance of 0.1% and a trial duration error allowance of 0.01% 🙆♀️
Oload is found by taking the number of octets successfully transmitted and dividing by the trial duration 🧮 The Oload for the DUT/SUT MUST be the aggregate of all the per-port Oloads ✨ Oload per port MAY be reported for diagnostic purposes 🔍
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. 💜
Okay, legal bit, but it's pretty straightforward 🧾 You can copy and share this document, translate it, and make derivative works that comment on or explain it or help with implementing it. You can publish and distribute all of that however you like, in whole or in part, with no restrictions, as long as the copyright notice and this paragraph are included on every copy and derivative work 🫶
The document itself, though, can't be changed in any way. That means no removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are if you need it for developing Internet standards (then the copyright procedures in the Internet Standards process have to be followed), or if you're translating it into a language other than English 🌍
These permissions are forever 💖 The Internet Society and its successors or assigns won't revoke them.
This document and the information in it are 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 RFC Editor function is currently provided by the Internet Society 🌸✨
📦 where this page comes from
- ietf: rfc2889 2000-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms