idnits 2.17.1 draft-ietf-bmwg-mswitch-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 30 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 96 has weird spacing: '...erfaces are g...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Any frame received which does not have the correct destination address MUST not be counted as a received frame and SHOULD be counted as part of a flood count. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Any frame received which does not have the correct destination address MUST not be counted as a received frame and SHOULD be counted as part of a flood count. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Any frame received which does not have the correct destination address MUST not be counted as a received frame and SHOULD be counted as part of a flood count. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Any frame received which does not have the correct destination address MUST not be counted as a received frame and SHOULD be counted as part of a flood count. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Any frame received which does not have the correct destination address MUST not be counted as a received frame and SHOULD be counted as part of a flood count. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Undersize - The DUT/SUT MUST filter frames less than 64 bytes from being propagated through the DUT/SUT (per ISO 8802-3 4.2.4.2.2). Undersized frames (or collision fragments) transmitted to the DUT/SUT MUST not appear as receive frames or as error frames on another port. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A second port (port 2) receives frames from the DUT/SUT and measures the Forwarding Rate. The measured Forwarding Rate SHOULD not exceed the medium's maximum theoretical utilization. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Any frame received which does not have the correct destination address MUST not be counted as a received frame and SHOULD be counted as part of a flood count. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1999) is 9113 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 17 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Mandeville 2 Internet-Draft European Network Laboratories 3 Expiration Date: November 1999 J. Perser 4 Netcom Systems 5 May 1999 7 Benchmarking Methodology for LAN Switching Devices 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Table of Contents 33 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 34 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 2 35 3. Test setup . . . . . . . . . . . . . . . . . . . . . . . . . . 2 36 4. Frame formats and sizes . . . . . . . . . . . . . . . . . . . . 3 37 5. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . . 4 38 5.1 Fully meshed throughput, frame loss and forwarding rates . . 4 39 5.2 Partially meshed overloading . . . . . . . . . . . . . . . . 7 40 5.3 Head of line blocking . . . . . . . . . . . . . . . . . . . . 10 41 5.4 Partially meshed multiple devices . . . . . . . . . . . . . . 13 42 5.5 Multiple streams of unidirectional traffic . . . . . . . . . 15 43 5.6 Filter illegal frames . . . . . . . . . . . . . . . . . . . . 18 44 5.7 Broadcast frame handling and latency . . . . . . . . . . . . 20 45 5.8 Maximum forwarding rate and minimum interframe gap . . . . . 21 46 5.9 Address caching capacity . . . . . . . . . . . . . . . . . . 23 47 5.10 Address learning rate . . . . . . . . . . . . . . . . . . . . 26 48 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 28 49 7. Authors' Address . . . . . . . . . . . . . . . . . . . . . . . 28 50 Appendix A: Formulas . . . . . . . . . . . . . . . . . . . . . . 29 52 1. Introduction 54 This document is intended to provide methodology for the benchmarking 55 of local area network (LAN) switching devices. It extends the 56 methodology already defined for benchmarking network interconnecting 57 devices in RFC 2544 to switching devices. 59 This RFC primarily deals with devices which switch frames at the 60 Medium Access Control (MAC) layer. It provides a methodology for 61 benchmarking switching devices, forwarding performance, congestion 62 control, latency, address handling and filtering. In addition to 63 defining the tests, this document also describes specific formats for 64 reporting the results of the tests. 66 A previous document, "Benchmarking Terminology for LAN Switching 67 Devices" (RFC 2285), defined many of the terms that are used in this 68 document. The terminology document SHOULD be consulted before 69 attempting to make use of this document. 71 2. Requirements 73 The following RFCs SHOULD be consulted before attempting to make use 74 of this document: 76 * RFC 1242 "Benchmarking Terminology for Network Interconnect 77 Devices" 79 * RFC 2285 "Benchmarking Terminology for LAN Switching Devices" 81 * RFC 2544 "Benchmarking Methodology for Network Interconnect 82 Devices" 84 For the sake of clarity and continuity, this RFC adopts the template 85 for benchmarking tests set out in Section 26 of RFC 2544. 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 89 this document are to be interpreted as described in RFC 2119. 91 3. Test setup 93 This document extends the general test setup described in section 6 94 of RFC 2544 to the benchmarking of LAN switching devices. RFC 2544 95 primarily describes non-meshed traffic where input and output 96 interfaces are grouped in mutually exclusive sending and receiving 97 pairs. In fully meshed traffic, each interface of a DUT/SUT is set 98 up to both receive and transmit frames to all the other interfaces 99 under test. 101 Prior to each test run, the DUT/SUT MUST learn the MAC addresses used 102 in the test and the address learning SHOULD be verified. Addresses 103 not learned will be forwarded as flooded frames and reduce the amount 104 of correctly forwarded frames. The rate at which address learning 105 frames are offered may have to be adjusted to be as low as 50 frames 106 per second or even less, to guarantee successful learning. The 107 DUT/SUT address aging time SHOULD be configured to be greater than 108 the period of the learning phase of the test plus the test duration 109 plus any configuration time required by the testing device. 110 Addresses SHOULD NOT age out until the test duration is completed. 111 More than one learning trial may be needed for the association of the 112 address to the port to occur. 114 If a DUT/SUT uses a hashing algorithm with address learning, the 115 DUT/SUT may not learn the necessary addresses to perform the tests. 116 The format of the MAC addresses MUST be adjustable so that the 117 address mapping may be re-arranged to make a DUT/SUT learn addresses 118 without confusion. 120 It is recommended that SNMP and Spanning Tree be disabled when bench- 121 marking switching devices unless investigating overhead behavior. If 122 such protocols cannot be turned off, it is recommended that the 123 levels of offered load be reduced (less than 100%) to allow for 124 the additional management frames. 126 4. Frame formats and sizes 128 The frame format is defined in RFC 2544 section 8 and MUST contain a 129 unique signature field located in the UDP DATA area of the Test Frame 130 (see Appendix C of RFC 2544). The purpose of the signature field is 131 filter out frames that are not part of the offered load. 133 The signature field MUST be unique enough to identify the frames not 134 originating from the DUT/SUT. The signature field SHOULD be located 135 after byte 56 (ISO/IEC 8802-3 collision window) or at the end of the 136 frame. The length, contents and method of detection is not defined 137 in this memo. 139 The signature field MAY have a unique identifier per port. This 140 would filter out misforwarded frames. It is possible for a DUT/SUT 141 to strip off the MAC layer, send it through its switching matrix, 142 and transmit it out with the correct destination MAC address but the 143 wrong payload. 145 For frame sizes, refer to RFC 2544, section 9. 147 There are three possible frame formats for layer 2 Ethernet switches: 148 standard MAC Ethernet frames, standard MAC Ethernet frames 149 with vendor-specific tags added to them, and IEEE 802.3ac 150 frames tagged to accommodate 802.3p&q. The two types of tagged 151 frames may exceed the standard maximum length frame of 1518 bytes, 152 and may not be accepted by the interface controllers of some 153 DUT/SUTs. It is recommended to check the compatibility of the DUT/SUT 154 with tagged frames before testing. 156 Devices switching tagged frames of over 1518 bytes will have a lower 157 maximum forwarding rate than standard untagged frames. 159 5. Benchmarking Tests 161 The following tests offer objectives, procedures, and reporting 162 formats for benchmarking LAN switching devices. 164 5.1 Fully meshed throughput, frame loss and forwarding rates 166 5.1.1 Objective 168 To determine the throughput, frame loss and forwarding rates of 169 DUT/SUTs offered fully meshed traffic as defined in RFC 2285. 171 5.1.2 Setup Parameters 173 When offering bursty full meshed traffic, the following parameters 174 MUST be defined. Each parameter is configured with the following 175 considerations. 177 Frame Size - Recommended frame sizes are 64, 128, 256, 512, 1024, 178 1280 and 1518 bytes, per RFC 2544 section 9. The four CRC bytes 179 are included in the frame size specified. 181 Interframe Gap (IFG) - The IFG between frames inside a burst 182 MUST be at the minimum specified by the standard (9.6 us for 183 10Mbps Ethernet, 960 ns for 100Mbps Ethernet, and 96 ns for 184 1 Gbps Ethernet). 186 Interburst Gap (IBG) - This is the interval between bursts of 187 traffic. Refer to Appendix A Formulas, for the formula used to 188 compute IBG. 190 Duplex mode - Half duplex or full duplex. 192 Load / Port - Load per port is expressed in a percentage of the 193 medium's maximum intended load possible. The actual transmitted 194 frame per second is dependent upon half duplex or full duplex 195 operation. The test SHOULD be run multiple times with a different 196 load per port in each case. 198 In half duplex mode, exactly half of the intended load SHOULD be 199 transmitted to each of the ports under test. For example, with a 200 100% load of 64-byte frames, the intended load for each port under 201 test is 7440 frames received per second and 7440 frames 202 transmitted per second (for 10Mbps Ethernet). 204 In full duplex mode, the entire intended load SHOULD be 205 transmitted to each of the ports under test. For example, with a 206 100% load of 64-byte frames, the intended load for each port under 207 test is 14880 frames received per second and 14880 frames 208 transmitted per second (for 10Mbps Ethernet). 210 Burst Size - The burst size defines the number of frames sent 211 back-to-back at the minimum legal IFG (96 bit times) before 212 pausing transmission to receive frames. Burst sizes 213 SHOULD vary between 1 and 930 frames. A burst size of 1 will 214 simulate non-bursty traffic. 216 Addresses per port - Represents the number of addresses which 217 are being tested for each port. Number of addresses SHOULD be a 218 binary exponential (i.e. 1, 2, 4, 8, 16, 32, 64, 128, 256, ...). 219 Recommended values are 1, 16 and 256. 221 Test Duration - Test duration SHOULD be between 1 and 300 seconds. 222 RFC 2285 recommends a duration of at least 10 seconds for each 223 test. 225 5.1.3 Procedure 227 All ports MUST transmit the exact number of frames. All ports SHOULD 228 start transmitting their frames within 1% of the test duration. For 229 a test duration of 10 seconds, all ports SHOULD have started 230 transmitting frames with 100 milliseconds of each other. 232 Each port in the test MUST send frames to all other ports in a 233 round robin type fashion. The following table shows how each port in 234 a test MUST transmit frames to all other ports in the test. In this 235 example, there are six ports with 1 address per port: 237 Source Port Destination Ports (in order of transmission) 239 Port #1 2 3 4 5 6 2... 240 Port #2 3 4 5 6 1 3... 241 Port #3 4 5 6 1 2 4... 242 Port #4 5 6 1 2 3 5... 243 Port #5 6 1 2 3 4 6... 244 Port #6 1 2 3 4 5 1... 246 As shown in the table, there is an equal distribution of destination 247 addresses for each transmit opportunity. This keeps the test balanced 248 so that one destination port is not overloaded by the test algorithm 249 and all ports are equally and fully loaded throughout the test. Not 250 following this algorithm exactly will produce inconsistent results. 252 For tests using multiple addresses per port, the actual port 253 destinations are the same as described above and the actual 254 source/destination address pairs SHOULD be chosen randomly to 255 exercise the DUT/SUT's ability to perform address lookups. 257 For every address, the testing device MUST send learning frames to 258 allow the DUT/SUT to update its address tables properly. 260 5.1.4 Measurements 262 Each port should receive the same number of frames that it 263 transmitted. Each receiving port MUST categorize, then count the 264 frames into one of two groups: 266 1.) Received Frames: received frames MUST have the correct 267 destination MAC address and SHOULD match a signature field. 269 2.) Flood count: defined in RFC 2285 3.8.3. 271 Any frame received which does not have the correct destination 272 address MUST not be counted as a received frame and SHOULD be counted 273 as part of a flood count. 275 Any frame originating from the DUT/SUT MUST not be counted as a 276 received frame. Frames originating from the DUT/SUT MAY be counted 277 as flooded frames or not counted at all. 279 Frame loss rate of the DUT/SUT SHOULD be reported as defined in 280 RFC 2544 section 26.3 with the following notes: Frame loss rate 281 SHOULD be measured at the end of the test duration. The term "rate", 282 for this measurement only, does not imply the units in the fashion of 283 "per seconds." 285 Throughput measurement is defined in RFC 2544. 287 Forwarding rate (FR) of the DUT/SUT SHOULD be reported as the number 288 of frames per second that the device is observed to successfully 289 transmit to the correct destination interface in response to a 290 specified offered load. The offered load MUST also be cited. 292 Forwarding rate at maximum offered load (FRMOL) MUST be reported 293 as the number of frames per second that a device can successfully 294 transmit to the correct destination interface in response to the 295 maximum offered load as defined in RFC 2285, section 3.6. The 296 maximum offered load MUST also be cited. 298 Maximum forwarding rate (MFR) MUST be reported as the highest 299 forwarding rate of a DUT/SUT taken from an iterative set of 300 forwarding rate measurements. The load applied to the device MUST 301 also be cited. 303 5.1.5 Reporting format 305 The results for these tests SHOULD be reported in the form of a 306 graph. The x coordinate SHOULD be the frame size, the y coordinate 307 SHOULD be the test results. There SHOULD be at least two lines on 308 the graph, one plotting the theoretical and one plotting the test 309 results. 311 To measure the DUT/SUT's ability to switch traffic while performing 312 many different address lookups, the number of addresses per port 313 MAY be increased in a series of tests. 315 5.2 Partially meshed overloading 317 5.2.1 Objective 319 To determine the throughput when transmitting from/to multiple ports 320 and to/from one port. As with the fully meshed throughput test, this 321 test is a measure of the capability of the DUT to switch frames 322 without frame loss. Results of this test can be used to determine 323 the ability of the DUT to utilize an Ethernet port when switching 324 traffic from multiple Ethernet ports. 326 5.2.2 Setup Parameters 328 When offering bursty meshed traffic, the following parameters MUST 329 be defined. Each parameter is configured with the following 330 considerations. 332 Frame Size - Recommended frame sizes are 64, 128, 256, 512, 1024, 333 1280 and 1518 bytes, per RFC 2544 section 9. The four CRC bytes 334 are included in the frame size specified. 336 Traffic Direction - Traffic can be generated in one direction, the 337 reverse direction, or both directions. 339 Interframe Gap (IFG) - The IFG between frames inside a burst 340 MUST be at the minimum specified by the standard (9.6 us for 341 10Mbps Ethernet, 960 ns for 100Mbps Ethernet, and 96 ns for 342 1 Gbps Ethernet). 344 Interburst Gap (IBG) - This is the interval between bursts of 345 traffic. Refer to Appendix A, Calculating Interburst Gap, for 346 the formula used to compute IBG. 348 Duplex mode - Half duplex or full duplex. 350 Load / Port - Load per port is expressed in a percentage of the 351 medium's maximum intended load possible. The actual transmitted 352 frame per second is dependent upon half duplex or full duplex 353 operation. The test SHOULD be run multiple times with a different 354 load per port in each case. 356 In half duplex mode, exactly half of the intended load SHOULD be 357 transmitted to each of the ports under test. For example, with a 358 100% load of 64-byte frames, the intended load for each port under 359 test is 7440 frames received per second and 7440 frames 360 transmitted per second (for 10Mbps Ethernet). 362 In full duplex mode, the entire intended load SHOULD be 363 transmitted to each of the ports under test. For example, with a 364 100% load of 64-byte frames, the intended load for each port under 365 test is 14880 frames received per second and 14880 frames 366 transmitted per second (for 10Mbps Ethernet). 368 Burst Size - The burst size defines the number of frames sent 369 back-to-back at the minimum legal IFG (96 bit times) before 370 pausing transmission to receive frames. Burst sizes 371 SHOULD vary between 1 and 930 frames. A burst size of 1 will 372 simulate non-bursty traffic. 374 Addresses per port - Represents the number of addresses which 375 are being tested for each port. Number of addresses SHOULD be a 376 binary exponential (i.e. 1, 2, 4, 8, 16, 32, 64, 128, 256, ...). 377 Recommended values are 1, 16 and 256. 379 Test Duration - Test duration SHOULD be between 1 and 300 seconds. 380 RFC 2285 recommends a duration of at least 10 seconds for each 381 test. 383 5.2.3 Procedure 385 In this test, each transmitting port MUST transmit the exact number 386 of frames. Depending upon traffic direction, some or all of the 387 ports will be transmitting. 389 Frames transmitted from the Many Ports MUST be destined to the One 390 port. Frames transmitted from the One Port MUST be destined to the 391 Many ports in a round robin type fashion. See section 5.1.3 for a 392 description of the round robin fashion. 394 For tests using multiple addresses per port, the actual port 395 destinations are the same as described above and the actual 396 source/destination address pairs SHOULD be chosen randomly to 397 exercise the DUT/SUT's ability to perform address lookups. 399 +----------+ 400 | | 401 | Many | <-------- 402 | | \ 403 +----------+ \ 404 \ 405 +----------+ \ +-------------+ 406 | | ------------> | | 407 | Many | <-----------------------> | One | 408 | | ------------> | | 409 +----------+ / +-------------+ 410 / 411 +----------+ / 412 | | / 413 | Many | <------- 414 | | 415 +----------+ 417 For every address, the testing device MUST send learning frames to 418 allow the DUT/SUT to update its address tables properly. 420 5.2.4 Measurements 422 Each receiving port MUST categorize, then count the frames into one 423 of two groups: 425 1.) Received Frames: received frames MUST have the correct 426 destination MAC address and SHOULD match a signature field. 428 2.) Flood count: defined in RFC 2285 3.8.3. 430 Any frame received which does not have the correct destination 431 address MUST not be counted as a received frame and SHOULD be counted 432 as part of a flood count. 434 Any frame originating from the DUT/SUT MUST not be counted as a 435 received frame. Frames originating from the DUT/SUT MAY be counted 436 as flooded frames or not counted at all. 438 Forwarding rate (FR) of the DUT/SUT SHOULD be reported as the number 439 of frames per second that the device is observed to successfully 440 transmit to the correct destination interface in response to a 441 specified offered load. The offered load MUST also be cited. 443 Forwarding rate at maximum offered load (FRMOL) MUST be reported 444 as the number of frames per second that a device can successfully 445 transmit to the correct destination interface in response to the 446 maximum offered load as defined in RFC 2285, section 3.6. The 447 maximum offered load MUST also be cited. 449 Maximum forwarding rate (MFR) MUST be reported as the highest 450 forwarding rate of a DUT/SUT taken from an iterative set of 451 forwarding rate measurements. The load applied to the device MUST 452 also be cited. 454 5.2.5 Reporting Format 456 The results for these tests SHOULD be reported in the form of a 457 graph. The x coordinate SHOULD be the frame size, the y coordinate 458 SHOULD be the test results. There SHOULD be at least two lines on 459 the graph, one plotting the theoretical and one plotting the test 460 results. 462 To measure the DUT/SUT's ability to switch traffic while performing 463 many different address lookups, the number of addresses per port 464 MAY be increased in a series of tests. 466 5.3 Head-of-line blocking 468 5.3.1 Objective 470 To determine how a DUT handles congestion. Namely, does the device 471 implement congestion control and does congestion on one port 472 affect an uncongested port? 474 5.3.2 Setup Parameters 476 The following parameters MUST be defined. Each variable is 477 configured with the following considerations. 479 Frame Size - Recommended frame sizes are 64, 128, 256, 512, 1024, 480 1280 and 1518 bytes, per RFC 2544 section 9. The four CRC bytes 481 are included in the frame size specified. 483 Duplex mode - Half duplex or full duplex. 485 Interframe Gap (IFG) - The IFG between frames MUST be at the 486 minimum specified by the standard (9.6 us for 10Mbps Ethernet, 487 960 ns for 100Mbps Ethernet, and 96 ns for 1 Gbps Ethernet). 489 Addresses per port - Represents the number of addresses which 490 are being tested for each port. Number of addresses SHOULD be a 491 binary exponential (i.e. 1, 2, 4, 8, 16, 32, 64, 128, 256, ...). 492 Recommended values are 1, 16 and 256. 494 Test Duration - Test duration SHOULD be between 1 and 300 seconds. 495 RFC 2285 recommends a duration of at least 10 seconds for each 496 test. 498 5.3.3 Procedure 500 This test MUST consist of a multiple of four ports. Four ports are 501 REQUIRED and MAY be expanded to fully utilize the DUT/SUT in 502 increments of four. Each group of four will contain a test block 503 with two of the ports as source transmitters and two of the ports as 504 receivers. The diagram below depicts the flow of traffic between the 505 switch ports: 507 +----------+ 50 % MOL +-------------+ 508 | | ------------------------> | | 509 | | 50 % MOL | uncongested | 510 | | --------- | | 511 +----------+ \ +-------------+ 512 \ 513 \ 514 \ 515 +----------+ \ +-------------+ 516 | | ---------> | | 517 | | 100 % MOL | congested | 518 | | ------------------------> | | 519 +----------+ +-------------+ 521 Both source transmitters MUST transmit the exact number of frames. 522 The first source MUST transmit frames at the MOL with the destination 523 address of the two receive ports in an alternating order. The first 524 frame to the uncongested receive port, second frame to the congested 525 receive port, then repeat. The second source transmitter MUST 526 transmit frames at the MOL only to the congested receive port. 528 Both receive ports SHOULD distinguish between frames originating from 529 the source ports and frames originating from the DUT/SUT. Only 530 frames from the source ports SHOULD be counted. 532 The uncongested receive port should be receiving at a rate of half 533 the MOL. The number of frames received on the uncongested port 534 SHOULD be 50% of the frames transmitted by the first source 535 transmitter. The congested receive port should be receiving at the 536 MOL. The number of frames received on the congested port should be 537 between 100% and 150% of the frames transmitted by one source 538 transmitter. 540 Frames destined to uncongested ports in a switch device should not 541 be dropped due to other ports being congested, even if the source 542 is sending to both the congested and uncongested ports. 544 5.3.4 Measurements 546 Any frame received which does not have the correct destination 547 address MUST not be counted as a received frame and SHOULD be counted 548 as part of a flood count. 550 Any frame originating from the DUT/SUT MUST not be counted as a 551 received frame. Frames originating from the DUT/SUT MAY be counted 552 as flooded frames or not counted at all. 554 Frame loss rate of the DUT/SUT's congested and uncongested ports MUST 555 be reported as defined in RFC 2544 section 26.3 with the following 556 notes: Frame loss rate SHOULD be measured at the end of the test 557 duration. The term "rate", for this measurement only, does not imply 558 the units in the fashion of "per seconds." 560 Forwarding rate (FR) of the DUT/SUT's congested and uncongested ports 561 MUST be reported as the number of frames per second that the device 562 is observed to successfully transmit to the correct destination 563 interface in response to a specified offered load. The offered load 564 MUST also be cited. 566 5.3.5 Reporting format 568 This test MUST report the frame lost rate at the uncongested port, 569 the maximum forwarding rate (at 50% offered load) at the uncongested 570 port, and the frame lost rate at the congested port. This test MAY 571 report the frame counts transmitted and frame counts received by the 572 ports. 574 If the DUT implements a flow control mechanism, an indication of this 575 is presented by observing no frame loss on the congested port. It 576 should be noted that this test expects the overall load to the 577 congested port to be greater than 100%. Therefore if the load is 578 greater than 100% and no frame loss is detected, then the DUT must be 579 implementing a flow control mechanism. The type of flow control 580 mechanism used is beyond the scope of this memo. 582 If there is frame loss at the uncongested port, "Head of Line" 583 blocking exists. The DUT cannot forward the amount of traffic to the 584 congested port and as a result it is also losing frames destined to 585 the uncongested port. 587 It should be noted that some DUTs may not be able to handle the 100% 588 load presented at the input port. In this case, there may be frame 589 loss reported at the uncongested port which is due to the load at the 590 input port rather than the congested port's load. 592 If the uncongested frame loss is reported as zero, but the maximum 593 forwarding rate is less than 7440 (for 10Mbps Ethernet), then this 594 may be an indication of congestion control being enforced by the DUT. 595 In this case, the congestion control is affecting the throughput of 596 the uncongested port. 598 If no congestion control is detected, the expected percentage frame 599 loss for the congested port is 33% at 150% overload. It is receiving 600 100% load from 1 port, and 50% from another, and can only get 100% 601 possible throughput, therefore having a frame loss rate of 33% 602 (150%-50%/150%). 604 5.4 Partially Meshed Multiple Devices 606 5.4.1 Objective 608 To determine the throughput, frame loss and forwarding rates of two 609 switching devices equipped with multiple Ethernet ports and one high 610 speed backbone uplink (Gigabit Ethernet, ATM, SONET). 612 5.4.2 Setup Parameters 614 When offering bursty partially meshed traffic, the following 615 parameters MUST be defined. Each variable is configured with the 616 following considerations. 618 Frame Size - Recommended frame sizes are 64, 128, 256, 512, 1024, 619 1280 and 1518 bytes, per RFC 2544 section 9. The four CRC bytes 620 are included in the frame size specified. 622 Interframe Gap (IFG) - The IFG between frames inside a burst 623 MUST be at the minimum specified by the standard (9.6 us for 624 10Mbps Ethernet, 960 ns for 100Mbps Ethernet, and 96 ns for 625 1 Gbps Ethernet). 627 Interburst Gap (IBG) - This is the interval between bursts of 628 traffic. Refer to Appendix A, Calculating Interburst Gap, for 629 the formula used to compute IBG. 631 Duplex mode - Half duplex or full duplex. 633 Load / Port - Load per port is expressed in a percentage of the 634 medium's maximum intended load possible. The actual transmitted 635 frame per second is dependent upon half duplex or full duplex 636 operation. The test SHOULD be run multiple times with a different 637 load per port in each case. 639 In half duplex mode, exactly half of the intended load SHOULD be 640 transmitted to each of the ports under test. For example, with a 641 100% load of 64-byte frames, the intended load for each port under 642 test is 7440 frames received per second and 7440 frames 643 transmitted per second (for 10Mbps Ethernet). 645 In full duplex mode, the entire intended load SHOULD be 646 transmitted to each of the ports under test. For example, with a 647 100% load of 64-byte frames, the intended load for each port under 648 test is 14880 frames received per second and 14880 frames 649 transmitted per second (for 10Mbps Ethernet). 651 Burst Size - The burst size defines the number of frames sent 652 back-to-back at the minimum legal IFG (96 bit times) before 653 pausing transmission to receive frames. Burst sizes 654 SHOULD vary between 1 and 930 frames. 656 Addresses per port - Represents the number of addresses which 657 are being tested for each port. Number of addresses SHOULD be a 658 binary exponential (i.e. 1, 2, 4, 8, 16, 32, 64, 128, 256, ...). 659 Recommended values are 1, 16 and 256. 661 Test Duration - Test duration SHOULD be between 1 and 300 seconds. 662 RFC 2285 recommends a duration of at least 10 seconds for each 663 test. 665 Local Traffic - A Boolean value of ON or OFF. The frame 666 sequence 667 algorithm MAY be altered to remove local traffic. With local 668 traffic ON, the algorithm is exactly the same as a fully meshed 669 throughput. With local traffic OFF, the port sends frames to all 670 other ports on the other side of the backbone uplink in a round 671 robin type fashion. 673 5.4.3 Procedure 675 All ports MUST transmit the exact number of frames. All ports SHOULD 676 start transmitting their frames within 1% of the test duration. For 677 a test duration of 10 seconds, all ports SHOULD have started 678 transmitting frames with 100 milliseconds of each other. 680 Each port in the test MUST send frames to all other ports in a 681 round robin type fashion as defined in section 5.1. Local traffic 682 MAY be removed from the round robin list in order to send the entire 683 load across the backbone uplink. 685 For tests using multiple addresses per port, the actual port 686 destinations are the same as described above and the actual 687 source/destination address pairs SHOULD be chosen randomly to 688 exercise the DUT/SUT's ability to perform address lookups. 690 For every address, the testing device MUST send learning frames to 691 allow the DUT/SUT to update its address tables properly. 693 To measure the DUT/SUT's ability to switch traffic while performing 694 many different address lookups, the number of addresses per port 695 MAY be increased in a series of tests. 697 5.4.4 Measurements 699 Each port should receive the same amount of frames that is 700 transmitted. Each receiving port MUST categorize, then count the 701 frames into one of two groups: 703 1.) Received frames MUST have the correct destination MAC address 704 and SHOULD match a signature field. 706 2.) Flood count (defined in RFC 2285 3.8.3). 708 Any frame received which does not have the correct destination 709 address MUST not be counted as a received frame and SHOULD be counted 710 as part of a flood count. 712 Any frame originating from the DUT/SUT MUST not be counted as a 713 received frame. Frames originating from the DUT/SUT MAY be counted 714 as flooded frames or not counted at all. 716 Frame loss rate of the DUT/SUT SHOULD be reported as defined in 717 RFC 2544 section 26.3 with the following notes: Frame loss rate 718 SHOULD be measured at the end of the test duration. The term "rate", 719 for this measurement only, does not imply the units in the fashion of 720 "per seconds." 722 Forwarding rate (FR) of the DUT/SUT SHOULD be reported as the number 723 of frames per second that the device is observed to successfully 724 transmit to the correct destination interface in response to a 725 specified offered load. The offered load MUST also be cited. 727 Forwarding rate at maximum offered load (FRMOL) MUST be reported 728 as the number of frames per second that a device can successfully 729 transmit to the correct destination interface in response to the 730 maximum offered load as defined in RFC 2285, section 3.6. The 731 maximum offered load MUST also be cited. 733 Maximum forwarding rate (MFR) MUST be reported as the highest 734 forwarding rate of a DUT/SUT taken from an iterative set of 735 forwarding rate measurements. The load applied to the device MUST 736 also be cited. 738 5.4.5 Reporting format 740 The results for these tests SHOULD be reported in the form of a 741 graph. The x coordinate SHOULD be the frame size, the y coordinate 742 SHOULD be the test results. There SHOULD be at least two lines on 743 the graph, one plotting the theoretical and one plotting the test 744 results. 746 To measure the DUT/SUT's ability to switch traffic while performing 747 many different address lookups, the number of addresses per port 748 MAY be increased in a series of tests. 750 5.5 Multiple streams of unidirectional traffic 752 5.5.1 Objective 754 To determine the throughput of the DUT/SUT when presented multiple 755 streams of unidirectional traffic with half of the ports on the 756 DUT/SUT are receiving frames destined to the other half of the 757 ports. 759 5.1.2 Setup Parameters 761 The following parameters MUST be defined. Each variable is 762 configured with the following considerations. 764 Frame Size - Recommended frame sizes are 64, 128, 256, 512, 1024, 765 1280 and 1518 bytes, per RFC 2544 section 9. The four CRC bytes 766 are included in the frame size specified. 768 Duplex mode - Half duplex or full duplex. 770 Load / Port - Load per port is expressed in a percentage of the 771 medium's maximum intended load possible. The actual transmitted 772 frame per second is dependent upon half duplex or full duplex 773 operation. The test SHOULD be run multiple times with a different 774 load per port in each case. 776 In half duplex mode, exactly half of the intended load SHOULD be 777 transmitted to each of the ports under test. For example, with a 778 100% load of 64-byte frames, the intended load for each port under 779 test is 7440 frames received per second and 7440 frames 780 transmitted per second (for 10Mbps Ethernet). 782 In full duplex mode, the entire intended load SHOULD be 783 transmitted to each of the ports under test. For example, with a 784 100% load of 64-byte frames, the intended load for each port under 785 test is 14880 frames received per second and 14880 frames 786 transmitted per second (for 10Mbps Ethernet). 788 Addresses per port - Represents the number of addresses which 789 are being tested for each port. Number of addresses SHOULD be a 790 binary exponential (i.e. 1, 2, 4, 8, 16, 32, 64, 128, 256, ...). 791 Recommended values are 1, 16 and 256. 793 Test Duration - Test duration SHOULD be between 1 and 300 seconds. 794 RFC 2285 recommends a duration of at least 10 seconds for each 795 test. 797 5.5.3 Procedure 799 Ports do not send and receive frames simultaneously. As a 800 consequence, there should be no collisions unless the DUT is 801 misforwarding frames, generating flooded or Spanning-Tree frames or 802 is enabling some flow control mechanism. Ports used for this test 803 are either transmitting or receiving, but not both. Those ports which 804 are transmitting send frames destined to addresses corresponding to 805 each of the ports receiving. This creates a unidirectional mesh of 806 traffic. 808 All ports MUST transmit the exact number of frames. All ports SHOULD 809 start transmitting their frames within 1% of the test duration. For 810 a test duration of 10 seconds, all ports SHOULD have started 811 transmitting frames with 100 milliseconds of each other. 813 Each transmitting port in the test MUST send frames to all receiving 814 ports in a round robin type fashion. The following table shows how 815 each port in a test MUST transmit frames to all other ports in the 816 test. In this 8 port example, port 1 through 4 are transmitting and 817 ports 5 through 8 are receiving; each with 1 address per port: 819 Source Port, then Destination Ports (in order of transmission) 821 Port #1 5 6 7 8 5 6... 822 Port #2 6 7 8 5 6 7... 823 Port #3 7 8 5 6 7 8... 824 Port #4 8 5 6 7 8 5... 826 As shown in the table, there is an equal distribution of destination 827 addresses for each transmit opportunity. This keeps the test balanced 828 so that one destination port is not overloaded by the test algorithm 829 and all receiving ports are equally and fully loaded throughout the 830 test. Not following this algorithm exactly will product inconsistent 831 results. 833 For tests using multiple addresses per port, the actual port 834 destinations are the same as described above and the actual 835 source/destination address pairs SHOULD be chosen randomly to 836 exercise the DUT/SUT's ability to perform address lookups. 838 For every address, the testing device MUST send learning frames to 839 allow the DUT/SUT to load its address tables properly. The address 840 table's aging time SHOULD be set sufficiently longer than the 841 learning time and test duration time combined. If the address table 842 ages out during the test, the results will show a lower performing 843 DUT/SUT. 845 To measure the DUT/SUT's ability to switch traffic while performing 846 many different address lookups, the number of addresses per port 847 MAY be increased in a series of tests. 849 5.5.4 Measurements 851 Each port should receive the same number of frames that it 852 transmitted. Each receiving port MUST categorize, then count the 853 frames into one of two groups: 855 1.) Received Frames: received frames MUST have the correct 856 destination MAC address and SHOULD match a signature field. 858 2.) Flood count: defined in RFC 2285 3.8.3. 860 Any frame received which does not have the correct destination 861 address MUST not be counted as a received frame and SHOULD be counted 862 as part of a flood count. 864 Any frame originating from the DUT/SUT MUST not be counted as a 865 received frame. Frames originating from the DUT/SUT MAY be counted 866 as flooded frames or not counted at all. 868 Frame loss rate of the DUT/SUT SHOULD be reported as defined in 869 RFC 2544 section 26.3 with the following notes: Frame loss rate 870 SHOULD be measured at the end of the test duration. The term "rate", 871 for this measurement only, does not imply the units in the fashion of 872 "per seconds." 874 Forwarding rate (FR) of the DUT/SUT SHOULD be reported as the number 875 of frames per second that the device is observed to successfully 876 transmit to the correct destination interface in response to a 877 specified offered load. The offered load MUST also be cited. 879 Forwarding rate at maximum offered load (FRMOL) MUST be reported 880 as the number of frames per second that a device can successfully 881 transmit to the correct destination interface in response to the 882 maximum offered load as defined in RFC 2285, section 3.6. The 883 maximum offered load MUST also be cited. 885 Maximum forwarding rate (MFR) MUST be reported as the highest 886 forwarding rate of a DUT/SUT taken from an iterative set of 887 forwarding rate measurements. The load applied to the device MUST 888 also be cited. 890 5.1.5 Reporting format 892 The results for these tests SHOULD be reported in the form of a 893 graph. The x coordinate SHOULD be the frame size, the y coordinate 894 SHOULD be the test results. There SHOULD be at least two lines on 895 the graph, one plotting the theoretical and one plotting the test 896 results. 898 To measure the DUT/SUT's ability to switch traffic while performing 899 many different address lookups, the number of addresses per port 900 MAY be increased in a series of tests. 902 5.6 Filter illegal frames 904 5.6.1 Objective 906 The objective of the filter illegal frame test is to determine 907 the behavior of the DUT under errors or abnormal frame conditions. 908 The results of the test indicate if the DUT/SUT filters the errors, 909 or simply propagates the errored frames along to the destination. 911 5.1.2 Setup Parameters 913 The following parameters MUST be defined. Each variable is 914 configured with the following considerations. 916 Load / Port - Load per port is expressed in a percentage of the 917 medium's maximum intended load possible. The actual transmitted 918 frame per second is dependent upon half duplex or full duplex 919 operation. The test SHOULD be run multiple times with a different 920 load per port in each case. 922 Test Duration - Test duration SHOULD be between 1 and 300 seconds. 923 RFC 2285 recommends a duration of at least 10 seconds for each 924 test. 926 5.6.3 Procedure 928 Each of the illegal frames for Ethernet MUST be checked: 930 Oversize - The DUT/SUT MAY filter frames larger than 1518 bytes 931 from being propagated through the DUT/SUT (ISO 8802-3 4.2.4.2.1). 932 Oversized frames transmitted to the DUT/SUT should not appear as 933 receive frames or as error frames on any port. DUT/SUT supporting 934 tagged Frames MAY forward frames up to and including 1522 bytes 935 long (IEEE 802.3ac 4.2.4.2.1). 937 Undersize - The DUT/SUT MUST filter frames less than 64 bytes from 938 being propagated through the DUT/SUT (per ISO 8802-3 4.2.4.2.2). 939 Undersized frames (or collision fragments) transmitted to the DUT/SUT 940 MUST not appear as receive frames or as error frames on another port. 942 CRC Errors - The DUT/SUT MUST filter frames that fail the Frame Check 943 Sequence Validation (ISO 8802-3 4.2.4.1.2) from being propagated 944 through the DUT/SUT. Frames with an invalid CRC transmitted to the 945 DUT/SUT should not appear as receive frames or as error frames on 946 another port. 948 Dribble Bit Errors - The DUT/SUT MUST correct and forward frames 949 containing dribbling bits. Frames transmitted to the DUT/SUT that do 950 not end in an octet boundary but contain a valid frame check sequence 951 MUST be accepted by the DUT/SUT (ISO 8802-3 4.2.4.2.1) and forwarded 952 to the correct receive port with the frame ending in an octet 953 boundary (ISO 8802-3 3.4). 955 Alignment Errors - The DUT/SUT MUST filter frames than fail the Frame 956 Check Sequence Validation AND do not end in an octet boundary. This 957 is a combination of a CRC error and a Dribble Bit error. When both 958 errors are occurring in the same frame, the DUT/SUT MUST determine 959 the CRC error takes precedence and filters the frame (ISO 8802-3 960 4.2.4.1.2) from being propagated. 962 5.7 Broadcast frame handling and latency test 964 5.7.1 Objective 966 The objective of the Broadcast Frame Handling and Latency Test is to 967 determine the throughput and latency of the DUT when handling 968 broadcast traffic. The ability to forward broadcast frames will 969 depend on special features built into the device for that purpose. 970 It is therefore necessary to determine the ability of switches to 971 handle broadcast frames, since there may be many different ways of 972 implementing such a feature. 974 5.7.2 Setup Parameters 976 The following parameters MUST be defined. Each variable is 977 configured with the following considerations. 979 Frame Size - Recommended frame sizes are 64, 128, 256, 512, 1024, 980 1280 and 1518 bytes, per RFC 2544 section 9. The four CRC bytes 981 are included in the frame size specified. 983 Duplex mode - Half duplex or full duplex. 985 Load / Port - Load per port is expressed in a percentage of the 986 medium's maximum intended load possible. The actual transmitted 987 frame per second is dependent upon half duplex or full duplex 988 operation. The test SHOULD be run multiple times with a different 989 load per port in each case. 991 In half duplex mode, exactly half of the intended load SHOULD be 992 transmitted to each of the ports under test. For example, with a 993 100% load of 64-byte frames, the intended load for each port under 994 test is 7440 frames received per second and 7440 frames 995 transmitted per second (for 10Mbps Ethernet). 997 In full duplex mode, the entire intended load SHOULD be 998 transmitted to each of the ports under test. For example, with a 999 100% load of 64-byte frames, the intended load for each port under 1000 test is 14880 frames received per second and 14880 frames 1001 transmitted per second (for 10Mbps Ethernet). 1003 Test Duration - Test duration SHOULD be between 1 and 300 seconds. 1004 RFC 2285 recommends a duration of at least 10 seconds for each 1005 test. 1007 5.7.3 Procedure 1009 For this test, there are two parts to be run. 1011 Broadcast Frame Throughput - This portion of the test uses a single 1012 source test port to transmit frames with a broadcast address using 1013 the frame specified in RFC 2544. Selected receive ports then 1014 measure the forwarding rate and Frame loss rate. 1016 Broadcast Frame Latency - This test uses the same setup as the 1017 Broadcast Frame throughput, but instead of a large stream of frames 1018 being sent, only one frame is sent and the latency to each of the 1019 receive ports are measured in seconds. 1021 5.7.4 Measurements 1023 Frame loss rate of the DUT/SUT SHOULD be reported as defined in 1024 RFC 2544 section 26.3 with the following notes: Frame loss rate 1025 SHOULD be measured at the end of the test duration. The term "rate", 1026 for this measurement only, does not imply the units in the fashion of 1027 "per seconds." 1029 Forwarding rate (FR) of the DUT/SUT SHOULD be reported as the number 1030 of frames per second that the device is observed to successfully 1031 transmit to the correct destination interface in response to a 1032 specified offered load. The offered load MUST also be cited. 1034 5.8 Maximum forwarding rate and minimum interframe gap 1036 5.8.1 Objective 1038 The objective of the Maximum forwarding rate test is to find the 1039 peak value of the Forwarding Rate when the Offered Load is varied 1040 between the throughput (RFC 1242) and the Maximum Offered Load 1041 (RFC 2285). 1043 The Minimum Interframe gap Test overloads a DUT/SUT port and measure 1044 the output for forward pressure. If the DUT/SUT transmits frames 1045 with an interframe gap less than 96 bits (ISO 8802-3 4.2.3.2.2), then 1046 forward pressure is detected. 1048 5.8.2 Setup Parameters 1050 The following parameters MUST be defined. Each variable is 1051 configured with the following considerations. 1053 Frame Size - Recommended frame sizes are 64, 128, 256, 512, 1024, 1054 1280 and 1518 bytes, per RFC 2544 section 9. The four CRC bytes 1055 are included in the frame size specified. 1057 Duplex mode - Half duplex or full duplex. 1059 Test Duration - Test duration SHOULD be between 1 and 300 seconds. 1060 RFC 2285 recommends a duration of at least 10 seconds for each 1061 test. 1063 Step Size - The minimum incremental resolution that the Offered 1064 Load (OL) will be incremented in frames per second. The smaller 1065 the step size, the more accurate the measurement and the more 1066 iterations required. As the Offered Load approaches the Maximum 1067 Offered Load, the minimum step size will increase because of gap 1068 resolution on the testing device. 1070 5.8.3 Procedure 1072 If the throughput and the Maximum Offered Load are the same, then 1073 Maximum Forwarding rate is equal to the Maximum Offered Load. 1075 This test SHOULD at a minimum be performed in a two-port 1076 configuration as described below. Learning frames MUST be sent to 1077 allow the DUT/SUT to update its address tables properly. 1079 The first port (port 1) device transmits frames at the Offered Load 1080 to the DUT/SUT. A second port (port 2) receives frames from the 1081 DUT/SUT and measures the Forwarding Rate. 1083 The Offered Load is incremented for each Step Size to find the 1084 Maximum Forwarding Rate. The algorithm for the test is as follows: 1086 CONSTANT 1087 MOL = ... frames/sec; {Maximum Offered Load} 1088 VARIABLE 1089 MFR := 0 frames/sec; {Maximum Forwarding Rate} 1090 OLOAD := starting throughput in frames/sec; {offered load} 1091 STEP := ... frames/sec; {Step Size} 1092 BEGIN 1093 OLOAD := OLOAD - STEP; 1094 DO 1095 BEGIN 1096 OLOAD := OLOAD + STEP 1097 IF (OLOAD > MOL) THEN 1098 BEGIN 1099 OLOAD := MOL 1100 END 1101 AddressLearning; {Port 2 broadcast frame with its source 1102 address} 1103 Transmit(OLOAD); {Port 1 sends frames to Port 2 at Offered load} 1104 IF (Port 2 Forwarding Rate > MFR) THEN 1105 BEGIN 1106 MFR := Port 2 Forwarding Rate; {A higher value than before} 1107 END 1108 END 1109 WHILE (OLOAD >= MOL); {MFR equals Maximum Forwarding Rate} 1110 DONE 1112 The Minimum Interframe gap test SHOULD, at a minimum, be performed in 1113 a two-port configuration as described below. Learning frames MUST be 1114 sent to allow the DUT/SUT to update its address tables properly. 1116 The first port (port 1) device transmits frames with an interframe 1117 gap of 88 bits to the DUT/SUT. This will apply forward pressure to 1118 the DUT/SUT and overload it at a rate of one byte per frame. The 1119 frames MUST be constructed with a source address of port 1 and a 1120 destination address of port 2. 1122 A second port (port 2) receives frames from the DUT/SUT and measures 1123 the Forwarding Rate. The measured Forwarding Rate SHOULD not exceed 1124 the medium's maximum theoretical utilization. 1126 5.8.4 Measurements 1128 Port 2 MUST categorize, then count the frames into one of two groups: 1130 1.) Received Frames: received frames MUST have the correct 1131 destination MAC address and SHOULD match a signature field. 1133 2.) Flood count: defined in RFC 2285 3.8.3. 1135 Any frame received which does not have the correct destination 1136 address MUST not be counted as a received frame and SHOULD be counted 1137 as part of a flood count. 1139 Any frame originating from the DUT/SUT MUST not be counted as a 1140 received frame. Frames originating from the DUT/SUT MAY be counted 1141 as flooded frames or not counted at all. 1143 5.8.5 Reporting format 1145 Maximum forwarding rate (MFR) MUST be reported as the highest 1146 forwarding rate of a DUT/SUT taken from an iterative set of 1147 forwarding rate measurements. The load applied to the device MUST 1148 also be cited. 1150 Forwarding rate (FR) of the DUT/SUT SHOULD be reported as the number 1151 of frames per second that the device is observed to successfully 1152 transmit to the correct destination interface in response to a 1153 specified offered load. The offered load MUST also be cited. 1155 5.9 Address Caching Capacity 1157 5.9.1 Objective 1159 To determine the address caching capacity of a LAN switching device 1160 as defined in RFC 2285, section 3.8.1. 1162 5.9.2 Setup Parameters 1164 The following parameters MUST be defined. Each variable is 1165 configured with the following considerations. 1167 Age Time - The maximum time that a DUT/SUT will keep a learned 1168 address in its forwarding table. 1170 Addresses Learning Rate - The rate at which new addresses are 1171 offered to the DUT/SUT to be learned. The rate at which address 1172 learning frames are offered may have to be adjusted to be as low as 1173 50 frames per second or even less, to guarantee successful 1174 learning. 1176 Initial Addresses - The initial number of addresses to start the 1177 test with. The number MUST be between 1 and the maximum number 1178 supported by the implementation. 1180 5.9.3 Procedure 1182 The aging time of the DUT/SUT MUST be known. The aging time MUST be 1183 longer than the time necessary to produce frames at the specified 1184 rate. If a low frame rate is used for the test, then it may be 1185 possible that sending a large amount of frames may actually take 1186 longer than the aging time. 1188 This test SHOULD at a minimum be performed in a three-port 1189 configuration as described below. 1191 This test MUST consist of a multiple of three ports. Three ports 1192 are REQUIRED and MAY be expanded to fully utilized the DUT/SUT in 1193 increments of three. Each group of three will contain a test 1194 block as follows: 1196 The first port (port 1) send frames with varying source addresses and 1197 a fixed destination address corresponding to the MAC address of the 1198 receiving port (port 2) of the DUT/SUT. By receiving frames with 1199 varying source addresses, the DUT/SUT will learn these new addresses 1200 from the sending port of the test device. The source addresses MAY 1201 be in sequential order. 1203 A second port (port 2) acts as the receiving port for the address 1204 learning frames. This port also sends test frames back to the 1205 addresses learned on the first port. The algorithm for this is 1206 explained below. 1208 A third port (port 3) on the DUT/SUT act as a monitoring port to 1209 listen for flooded frames. 1211 It is highly recommended that SNMP, Spanning Tree, and any other 1212 frames originating from the DUT/SUT be disabled when running this 1213 test. If such protocols cannot be turned off, the flood count MUST 1214 be modified only to count frame originating from port 1 and MUST 1215 NOT count frames originating from the DUT/SUT. 1216 The algorithm for the test is as follows: 1218 CONSTANT 1219 AGE = ...; {value greater that DUT aging time} 1220 MAX = ...; {maximum address support by implementation} 1221 VARIABLE 1222 LOW := 0; {Highest passed valve} 1223 HIGH := MAX; {Lowest failed value} 1224 N := ...; {user specified initial starting point} 1225 BEGIN 1226 DO 1227 BEGIN 1228 PAUSE(AGE); {Age out any learned addresses} 1229 AddressLearning(Port 2); {broadcast a frame with its source 1230 Address and broadcast destination} 1231 AddressLearning(Port 1); {N frames with varying source 1232 addresses 1233 to Port 2} 1234 Transmit(Port 2); {N frames with varying destination addresses 1235 corresponding to Port 1} 1236 IF (Port 3 receive frame != 0) OR 1237 (Port 1 receive frames < Port 2 transmit) THEN 1238 BEGIN {Address Table of DUT/SUT was full} 1239 HIGH := N; 1240 END 1241 ELSE 1242 BEGIN {Address Table of DUT/SUT was NOT full} 1243 LOW := N; 1244 END 1245 N := LOW + (HIGH - LOW)/2; 1246 END WHILE (HIGH - LOW < 2); 1247 END {Value of N equals number of addresses supported by DUT/SUT} 1249 Using a binary search approach, the test targets the exact number of 1250 addresses supported per port with consistent test iterations. Due 1251 to the aging time of DUT/SUT address tables, each iteration may take 1252 some time during the waiting period for the addresses to clear. If 1253 possible, configure the DUT/SUT for a low value for the aging time. 1255 Once the high and low values of N meet, then the threshold of address 1256 handling has been found. 1258 5.9.4 Measurements 1260 Whether the offered addresses per port was successful forwarded 1261 without flooding. 1263 5.9.5 Reporting format 1265 After the test is run, results for each iteration SHOULD be displayed 1266 in a table to include: 1268 The number of addresses used for each test iteration (varied). 1270 The intended load used for each test iteration (fixed). 1272 Number of test frames that were transmitted by test port number 2. 1273 This SHOULD match the number of addresses used for the test 1274 iteration. Test frames are the frames sent with varying 1275 destination addresses to confirm that the DUT/SUT has learned 1276 all of the addresses for each test iteration. 1278 The flood count on port 2 during the test portion of each test. 1279 If the number is non-zero, this is an indication of the DUT/SUT 1280 flooding a frame in which the destination address is not in the 1281 address table. 1283 The number of frames correctly forwarded to test port 1 during 1284 the test portion of the test. Received frames MUST have the 1285 correct destination MAC address and SHOULD match a signature 1286 field. For a passing test iteration, this number should be equal 1287 to the number of frames transmitted by port 2. 1289 The flood count on port 1 during the test portion of each test. 1290 If the number is non-zero, this is an indication of the DUT/SUT 1291 flooding a frame in which the destination address is not in the 1292 address table. 1294 The flood count on port 3. If the value is not zero, then this 1295 indicates that for that test iteration, the DUT/SUT could not 1296 determine the proper destination port for that many frames. In 1297 other words, the DUT/SUT flooded the frame to all ports since its 1298 address table was full. 1300 5.10 Address Learning Rate 1302 5.10.1 Objective 1304 To determine the rate of address learning of a LAN switching device 1305 as defined in RFC 2285, section 3.8.2. 1307 5.10.2 Setup Parameters 1309 The following parameters MUST be defined. Each variable is 1310 configured with the following considerations. 1312 Age Time - The maximum time that a DUT/SUT will keep a learned 1313 address in its forwarding table. 1315 Initial Addresses Learning Rate - The starting rate at which new 1316 addresses are offered to the DUT/SUT to be learned. 1318 Number of Addresses - The number of addresses that the DUT/SUT must 1319 learn. The number MUST be between 1 and the maximum number 1320 supported by the implementation. It is recommended no to exceed 1321 the address caching capacity found in section 5.9 1323 5.10.3 Procedure 1325 The aging time of the DUT/SUT MUST be known. The aging time MUST be 1326 longer than the time necessary to produce frames at the specified 1327 rate. If a low frame rate is used for the test, then it may be 1328 possible that sending a large amount of frames may actually take 1329 longer than the aging time. 1331 This test SHOULD at a minimum be performed in a three-port 1332 configuration as described below. 1334 This test MUST consist of a multiple of three ports. Three ports 1335 are REQUIRED and MAY be expanded to fully utilized the DUT/SUT in 1336 increments of three. Each group of three will contain a test 1337 block as described in section 5.9. 1339 An algorithm similar to the one used to determine address caching 1340 capacity can be used to determine the address learning rate. This 1341 test iterates the rate at which address learning frames are offered 1342 by the test device connected to the DUT/SUT. It is recommended to 1343 set the number of addresses offered to the DUT/SUT in this test to 1344 the maximum caching capacity. 1346 The address learning rate might be determined for different numbers 1347 of addresses but in each test run, the number MUST remain constant 1348 and SHOULD be equal to or less than the maximum address caching 1349 capacity. 1351 5.10.4 Measurements 1353 Whether the offered addresses per port was successful forwarded 1354 without flooding at the offered learning rate. 1356 5.10.5 Reporting format 1358 After the test is run, results for each iteration SHOULD be displayed 1359 in a table: 1361 The number of addresses used for each test iteration (fixed). 1363 The intended load used for each test iteration (varied). 1365 Number of test frames that were transmitted by test port number 2. 1366 This SHOULD match the number of addresses used for the test 1367 iteration. Test frames are the frames sent with varying 1368 destination addresses to confirm that the DUT/SUT has learned 1369 all of the addresses for each test iteration. 1371 The flood count on port 2 during the test portion of each test. 1372 If the number is non-zero, this is an indication of the DUT/SUT 1373 flooding a frame in which the destination address is not in the 1374 address table. 1376 The number of frames correctly forwarded to test port 1 during 1377 the test portion of the test. Received frames MUST have the 1378 correct destination MAC address and SHOULD match a signature 1379 field. For a passing test iteration, this number should be equal 1380 to the number of frames transmitted by port 2. 1382 The flood count on port 1 during the test portion of each test. 1383 If the number is non-zero, this is an indication of the DUT/SUT 1384 flooding a frame in which the destination address is not in the 1385 address table. 1387 The flood count on port 3. If the value is not zero, then this 1388 indicates that for that test iteration, the DUT/SUT could not 1389 determine the proper destination port for that many frames. In 1390 other words, the DUT/SUT flooded the frame to all ports since its 1391 address table was full. 1393 6. Security Considerations 1395 This document does not yet address Security Considerations. 1397 7. Authors' Address 1399 Robert Mandeville 1400 European Network Laboratories (ENL) 1401 2, rue Helene Boucher 1402 87286 Guyancourt Cedex 1403 France 1405 Phone: + 33 1 39 44 12 05 1406 EMail: bob@enl.net 1408 Jerry Perser 1409 Netcom Systems 1410 20550 Nordhoff St. 1411 Chatsworth, CA 91311 1412 USA 1414 Phone: + 1 818 700 5100 1415 Email: jerry_perser@netcomsystems.com 1417 Appendix A: Formulas 1419 A.1 Calculating the InterBurst Gap 1421 IBG is defined in RFC 2285 as the interval between two bursts. To 1422 achieve a desired load, the follow Input Parameter need to be 1423 defined: 1425 LENGTH - Frame size in bytes including the CRC. 1427 LOAD - The intended load in percent. Range is 0 to 100. 1429 BURST - The number of frames in the burst (integer value). 1431 SPEED - media's speed in bits/sec 1432 Ethernet is 10,000,000 bits/sec 1433 Fast Ethernet is 100,000,000 bits/sec 1434 Gigabit Ethernet is 1,000,000,000 bits/sec 1436 DUPLEX - A constant to adjust the transmit rate for full or half 1437 duplex mode. In full duplex the value is 100, in half 1438 duplex the value is 200. 1440 IFG - A constant 96 bits for the minimum interframe gap. 1442 The IBG (in seconds) can be calculated: 1444 (DUPLEX/LOAD - 1) * BURST * (IFG + 64 + 8*LENGTH)] + IFG 1445 IBG = ---------------------------------------------------------- 1446 SPEED 1448 A.2 Calculating the Number of Bursts for the Test Duration 1450 The number of burst for the test duration is rounded up to the 1451 nearest 1452 integer number. The follow Input Parameter need to be defined: 1454 LENGTH - Frame size in bytes including the CRC. 1456 BURST - The number of frames in the burst (integer value). 1458 SPEED - media's speed in bits/sec 1459 Ethernet is 10,000,000 bits/sec 1460 Fast Ethernet is 100,000,000 bits/sec 1461 Gigabit Ethernet is 1,000,000,000 bits/sec 1463 IFG - A constant 96 bits for the minimum interframe gap. 1465 IBG - Found in the above formula 1467 DURATION - Test duration in seconds. 1469 An intermediate number of the Burst duration needs to be calculated 1470 first: 1472 IFG*(BURST-1) + BURST*(64 + 8*LENGTH) 1473 TXTIME = ----------------------------------------- 1474 SPEED 1476 Number of Burst for the Test Duration (rounded up): 1478 DURATION 1479 #OFBURSTS = -------------- 1480 (TXTIME + IBG) 1482 Example: 1484 LENGTH = 64 bytes per frame 1485 LOAD = 100 % offered load 1486 BURST = 24 frames per burst 1487 SPEED = 10 Mbits/sec (Ethernet) 1488 DUPLEX = 200 (half duplex) 1489 DURATION = 10 seconds test 1491 IBG = 1612.8 uS 1492 TXTIME = 1603.2 uS 1493 #OFBURSTS = 3110