idnits 2.17.1 draft-ietf-bmwg-lanswitch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 558 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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.) ** There are 113 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 144: '...ectional traffic MUST be offered when ...' RFC 2119 keyword, line 183: '.... Backbone tests SHOULD use bidirectio...' RFC 2119 keyword, line 260: '...e and burst size MUST adjust the inter...' RFC 2119 keyword, line 298: '...ional loading ports under test MUST be...' RFC 2119 keyword, line 302: '...Ethernet traffic MUST implement the tr...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 459 has weird spacing: '...dresses which...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 11 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Expiration Date: January 1997 3 Benchmarking Terminology for Local Area Switching Devices 5 7 Status of this Document 9 This document is an Internet-Draft. Internet-Drafts are working documents 10 of the Internet Engineering Task Force (IETF), its areas, and its working 11 groups. Note that other groups may also distribute working documents as 12 Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months and 15 may be updated, replaced, or obsoleted by other documents at any time. It 16 is inappropriate to use Internet- Drafts as reference material or to cite 17 them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 21 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 22 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 24 Distribution of this document is unlimited. Please send comments to 25 bmwg@harvard.edu or to the editor. 27 Abstract 29 The purpose of this draft is to extend the benchmarking terminology and 30 methodology already defined for network interconnect devices in RFCs 1242 31 and 1944 by the Benchmarking Methodology Working Group (BMWG) of the 32 Internet Engineering Task Force (IETF) to address the specific requirements 33 of local area switches. Appendix A lists the tests and conditions that we 34 believe should be included for specific cases and gives additional 35 information about testing practices. 37 Although switches have clearly evolved from bridges, they have matured 38 enough in the last few years to deserve special attention. Switches are seen 39 as one of the principal sources of new bandwidth in the local area and are 40 handling a significantly increasing proportion of network traffic. The 41 multiplicity of products brought to market makes it desirable to define a 42 set of benchmarks designed to provide reliable and comparable data to the 43 user community with which to evaluate the performance characteristics of 44 switching devices. 46 1. Introduction 48 The purpose of this draft is to discuss and define a number of terms and 49 procedures for benchmarking switches. This draft covers local area devices 50 which switch frames at the Media Access Control (MAC) layer. Its intention 51 is to describe a benchmarking methodology which fully exercizes local area 52 switching devices at the MAC layer. It defines tests for throughput, 53 latency, address handling and filtering. 55 2. Term definitions 57 A previous document, "Benchmarking Terminology for Network Interconnect 58 Devices" (RFC 1242), defined many of the terms that are used in this 59 document. The terminology document should be consulted before attempting to 60 make use of this document. A more recent document, "Benchmarking Methodology 61 for Network Interconnect Devices" (RFC 1944), defined a number of test 62 procedures which are directly applicable to switches. Since it discusses a 63 number of terms relevant to benchmarking switches it should also be consulted. 64 A number of new terms applicable to benchmarking switches are defined below 65 using the format for definitions set out in Section 2 of RFC 1242. RFCs 1242 66 and 1944 already contain discussions of some of these terms. 68 2. 1. Reminder of RFC 1242 definition format 70 Term to be defined. (e.g., Latency) 72 Definition: 73 The specific definition for the term. 75 Discussion: 76 A brief discussion about the term, it's application 77 and any restrictions on measurement procedures. 79 Measurement units: 80 The units used to report measurements of this 81 term, if applicable. 83 Issues: 84 List of issues or conditions that effect this term. 86 See Also: 87 List of other terms that are relevant to the discussion 88 of this term. 90 2.2. Unidirectional traffic 92 Definition: 94 Unidirectional traffic is made up of a single or multiple streams of frames 95 forwarded in one direction only from one or more ports of a switching device 96 designated as input ports to one or more other ports of the device 97 designated as output ports. 99 Discussion: 100 This definition conforms to the discussion in section 16 of RFC 1944 on 101 multi-port testing which describes how unidirectional traffic can be offered 102 to ports of a device to measure maximum rate of throughput. 103 With regard to benchmarking switching devices some additional applications 104 of unidirectional traffic are to be considered: 105 - the measurement of the minimum inter-frame gap 106 - the detection of head of line blocking 107 - the measurement of throughput on ports when congestion control is activated 108 - the creation of many-to-one or one-to-many port overload 109 - the measurement of the aggressivity of the back-off algorithm in the case 110 of CSMA/CD devices 112 A couple of these applications, head of line blocking and congestion control 113 testing require unidirectional streams of traffic to be set up in a 114 particular way between at least four ports with two streams running from one 115 of the input ports to two output ports and a third stream running between 116 the second input port and one of the output ports. These streams can be 117 pictured as an inverted " Z " with input ports on the left and output ports 118 on the right. 119 Many-to-one overload requires a minimum to two input and one output ports 120 when all ports run at the same speed. When devices are equipped with ports 121 running at different speeds the number of ports required to overload an 122 output port or ports will vary. 124 Issues: 125 half duplex / full duplex 127 Measurement units: 128 n/a 130 See Also: 131 bidirectional traffic (2.3) 132 multidirectional traffic (2.4) 134 2.3. Bidirectional traffic 136 Definition: 137 Bidirectional traffic is made up of a single stream or multiple streams of 138 frames forwarded in both directions between ports belonging to two distinct 139 groups of ports on a switching device. 141 Discussion: 142 This definition conforms to the discussions in sections 14 and 16 of RFC 143 1944 on bidirectional traffic and multi-port testing. 144 Bidirectional traffic MUST be offered when measuring the maximum rate of 145 throughput on full duplex ports of a switching device. 147 It is not recommended to offer bidirectional traffic to measure maximum 148 rates of throughput between isolated pairs of half duplex CSMA/CD ports 149 since the capture effect may result in one of the ports transmitting for 150 extended periods to the exclusion of the other port. The capture effect is 151 generally considered to be an anomalous ramification of the truncated binary 152 exponential back-off algorithm implemented in CSMA/CD devices. 154 Issues: 155 back-off 157 Measurement units: 158 n/a 160 See Also: 161 unidirectional traffic (2.2) 162 multidirectional traffic (2.4) 164 2.4. Multidirectional traffic 166 Definition: 167 Multidirectional traffic is made up of multiple streams of frames forwarded 168 between all of the ports of a switching device. 170 Discussion: 171 This definition extends the discussions in sections 14 and 16 of RFC 1944 on 172 bidirectional traffic and multi-port testing. 173 As with bidirectional multi-port tests, multidirectional traffic exercizes 174 both the input and output sides of the ports of a switching device. But 175 since ports are not divided into two groups every port forwards frames to 176 and receives frames from every other port. The total number of individual 177 unidirectional streams offered in a multidirectional test for n switched 178 ports equals n x (n - 1). This compares with n x (n / 2) such streams in a 179 bidirectional multi-port test. It should be noted however that bidirectional 180 multiport tests create a greater load than multidirectional tests on 181 backbone connections linking together two switching devices. Since none of 182 the transmitted frames are forwarded locally all of the traffic is sent over 183 the backbone. Backbone tests SHOULD use bidirectional multiport traffic. 184 Multidirectional traffic is inherently bursty since ports must interrupt 185 transmission intermittently to receive frames. When offering such bursty 186 traffic to a device under test a number of variables have to be defined. 187 They include frame size, the number of frames within bursts as well as the 188 interval between bursts. The terms burst size and inter-burst gap are 189 defined in sections 2.6 and 2.7 below. 190 Bursty multidirectional traffic exercizes many of the component parts of a 191 switching device simultaneously as they would be on a real network. It 192 serves to determine the maximum throughput of a switching device when many 193 of its componenet parts are working at once. Complementary tests may single 194 out the performance characteristics of particular parts such as buffer size, 195 backplane capacity, switching speed and the behavior of the media access 196 controller . These tests are detailed in the methodology sections below. 198 Measurement units: 199 n/a 201 Issues: 202 half duplex / full duplex 204 See Also: 205 unidirectional traffic (2.2) 206 bidirectional traffic (2.3) 207 target rate / target load (2.6) 209 2.5 Burst 211 Definition: 212 A frame or a group of frames transmitted with the minimum inter-frame gap 213 allowed by the media. 215 Discussion: 216 This definition follows from the discussion in section 21 of RFC 1944. It is 217 useful to consider isolated frames as single frame bursts. 219 Measurement units: 220 n/a 222 Issues: 224 See Also: 225 burst size (2.6) 227 2.6 Burst size 229 Definition: 230 The number of frames in a burst. 232 Discussion: 233 Burst size can range from one to infinity. In unidirectional streams there 234 is no theoretical limit to the burst length. Bursts in bidirectional and 235 multidirectional streams of traffic are finite since ports interrupt 236 transmission intermittantly to receive frames. In multidirectional networks 237 bursts from several sources might be transmitted between ports at any one 238 time. This makes it desirable to test devices for large burst sizes. 240 Measurement units: 241 number of N-octet frames 243 Issues: 245 See Also: burst (2.5) 247 2.7 Inter-burst gap (IBG) 249 Definition: 250 The interval between two bursts. 252 Discussion: 253 This definition conforms to the discussion in section 20 of RFC 1944 on 254 bursty traffic. 255 Bidirectional and multidirectional streams of traffic are inherently bursty 256 since ports share their time between receiving and transmitting frames. 257 Assuming the number of frames per burst and frame length to be fixed, the 258 value of the inter-burst gap will determine the rate of transmission. 259 External sources offering bursty multidirectional traffic for a given frame 260 size and burst size MUST adjust the inter-burst gap to achieve a specified 261 rate of transmission. 262 When a burst contains a single frame inter-burst gap and inter-frame gap are 263 equal. 265 Measurement units: 266 nanoseconds 267 microseconds 268 miliseconds 269 seconds 271 Issues: 273 See Also: burst size (2.6), load (2.8) 275 2.8 Load 277 Definition: 278 The amount of traffic per second going through the transmit and receive 279 sides of a port. 281 Discussion: 282 Load can be expressed in a number of ways: bits per second, frames per 283 second with the frame size specified or as a percentage of the maximum frame 284 rate allowed by the media for a given frame size. For example, a 285 port-to-port unidirectional stream of 7440 64-byte Ethernet frames per 286 second offers a 50% load on the receive side of the input port and a 50% 287 load on the transmit side of the output port given that the maximum line 288 rate on an Ethernet is 14880 frames per second. In the case of bidirectional 289 or multidirectional traffic port load is the sum of the frames received and 290 transmitted on a port per second. 291 There is room for varying the balance between incoming and outgoing traffic 292 when loading ports with bidirectional and multidirectional traffic. In the 293 case of port-to-port bidirectional traffic a 100% load can be created by 294 offering a n% load on the receive side of the input port and a (100 - n)% 295 load on its transmit side. The output port will be offered the inverse load. 296 Multidirectional traffic will be equally distributed over all ports under 297 test when port receive and transmit sides are offered 50% loads. When 298 benchmarking with balanced multidirectional loading ports under test MUST be 299 offered an equally distributed load. 300 Target loads and actual loads may differ widely due to collisions on CSMA/CD 301 links or the action of congestion control mechanisms. External sources of 302 Ethernet traffic MUST implement the truncated binary exponential back-off 303 algorithm when executing bidirectional and multidirectional performance 304 tests to ensure that the external source of traffic is not accessing the 305 medium illegally. 306 Frames which are not successfully transmitted by the external source of 307 traffic to the device under test should be not counted as transmitted frames 308 in performance benchmarks. 310 Measurement units: 311 bits per second 312 N-octets per second 313 (N-octets per second / media_maximum-octets per second) x 100 315 Issues: 316 token ring 318 2.9 Overload 320 Definition: 321 Loading a port or ports in excess of the maximum line rate allowed by the media. 323 Discussion: 324 Overloading can serve to test a device's buffer depth or congestion control 325 mechanism. Unidirectional overloads require a minimum of two input and one 326 output ports when all ports run at the same nominal speed. Balanced 327 bidirectional and multidirectional overloading occur when the sum of the 328 traffic offered to the input and output sides of all ports exceeds the 329 maximum line rate allowed by the media by the same amount. 331 Measurement units: 332 N-octet frames per second 334 Issues: target load and mesured load 336 See Also: 338 2.10 Speed 340 Definition: 341 A measure of switching throughput which records the maximum number of frames 342 that a switched port is capable of receiving and/or transmitting per second. 344 Discussion: 345 In multidirectional benchmarking it is important to record the speed at 346 which switching devices are able to forward frames to their destination 347 addresses. Speed can vary for a number of reasons such as head of line 348 blocking, excessive collisions on CSMA/CD media, the action of congestion 349 control mechanisms at high loads or the backplane capacity of the switching 350 device. The rate of throughput on token rings is mostly a function of the 351 media acces controllers. 352 The rate of throughput can be measured on the input as well as the output 353 sides of a port. The rate of throughput measured on the output side of a 354 port measures the rate at which a device forwards frames to their 355 destinations. This rate MUST be reported as the rate of throughput. The 356 aggregate rate of throughput can be skewed when a device drops frames since 357 the input port may receive at a much higher rate than it transmits. 359 Measurement units: 360 N-octet frames per second 362 Issues: 364 See Also: 366 2.11 Valid frame / invalid frame 368 Definition: 369 A frame which is forwarded to its proper destination port based on MAC 370 address information is valid. A frame which is received on ports which do 371 not correspond to the MAC address information is invalid. 373 Discussion: 374 When recording throughput statistics it is important to check that frames 375 have been forwarded to their proper desinations. Invalid frames are 376 generally unknown unicast frames which the device under test forwards or 377 floods to all ports. 379 Measurement units: 380 N-octet valid frames per second 382 Issues: 383 Spanning tree BPDUs. 385 See Also: 387 2.11 Backpressure 389 Definition: 390 A jamming technique used by some switching devices to avoid frame loss when 391 congestion on one or more of its ports occurs. 393 Discussion: 394 Some switches are designed to send jam signals, for example preamble bits, 395 back to traffic sources when their transmit and/or receive buffers start to 396 overfill. Such devices may incur no frame loss when ports are offered target 397 loads in excess of 100% by external traffic sources. Jamming however affects 398 traffic destined to congested as well as uncongested ports so it is 399 important to measure the maximum speed at which a jamming port can forward 400 frames to uncongested port destinations. 402 Measurement units: 403 N--octet frames per second between the jamming port and an uncongested 404 destination port 406 Issues: 407 not explicitly described in standards 409 See Also: 410 forward pressure (2.12) 412 2.12 Forward pressure 414 Definition: 415 A technique which modifies the binary exponential backoff algorithm to avoid 416 frame loss when congestion on one or more of its ports occurs. 418 Discussion: 419 Some switches avoid buffer overload by retransmitting buffered frames 420 without waiting for the interval calculated by the normal operation of the 421 backoff algorithm. It is important to measure how aggressive a switch's 422 backoff algorithm is in both congested and uncongested states. Forward 423 pressure is manifested by lower numbers of collisions when congestion on a 424 port builds up. 426 Measurement units: 427 intervals in microseconds between transmission retries during 16 successive 428 collisions. 430 Issues: 431 not explicitly described in standards 433 See also: 434 backpressure (2.11) 436 2.13 Head of line blocking 438 Definition: 439 A pathologocal state whereby a switch drops frames forwarded to an 440 uncongested port whenever frames are forwarded from the same source port to 441 a congested port. 443 Discussion: 444 It is important to verify that a switch does not propagate frame loss to 445 ports which are not congested whenever overloading on one of its ports occurs. 447 Measurement units: 448 frame loss recorded on an uncongested port when receiving frames from a port 449 which is also forwarding frames to a congested destination port. 451 Issues: 452 Input buffers 454 See Also: 456 2.14 Address handling 458 Definition: 459 The number of different destination MAC addresses which a switch can learn. 461 Discussion: 463 Users building networks will want to know how many nodes they can connect to 464 a switch. This makes it necessary to verify the number of MAC addresses 465 that can be assigned per port, per module and per chassis before a switch 466 begins flooding frames. 468 Measurement units: 469 number of MAC addresses 471 Issues: 473 See Also: 475 2.15 Address learning speed 477 Definition: 478 The maximum rate at which a switch can learn MAC addresses before starting 479 to flood frames. 481 Discussion: 482 Users may want to know how long it takes a switch to build up its address 483 tables. This information may be useful for a user to have when considering 484 how a network comes up after a crash. 486 Measurement units: 487 frames per second with each successive frame sent to the switch containing a 488 different source address. 490 Issues: 492 See Also: address handling (2.14) 494 2.16 Filtering illegal frames 496 Definition: 497 Switches do not necessarily filter all types of illegal frames. Some 498 switches, for example, do not store frames before forwarding them to their 499 destination ports. These so-called cut-through switches forward frames after 500 reading the destination and source address fields. They do not normally 501 filter over-sized frames (jabbers) or verify the validity of the Frame Check 502 Sequence field. Other illegal frame types are under-sized frames (runts), 503 misaligned frames and frames followed by dribble bits. 505 Measurement units: 506 N-octet frames filtered or not filtered 508 Issues: 510 See Also: 512 2.17 Broadcast latency 514 Definition: 515 The time it takes a broadcast frame to go through a switching device and be 516 forwarded to each destination port. 518 Discussion: 519 Since there is no standard way for switches to process broadcast frames, 520 broadcast latency may not be the same on all receiving ports of a switching 521 device. Broadcast latency SHOULD be determined on all receiving ports. 523 Measurement units: 524 The latency measurements SHOULD be bit oriented as described in 3.8 of RFC 525 1242 and reported for all connected receive ports. 527 Issues: 529 See Also: 531 3. Editor's Address 533 Robert Mandeville 534 ENL (European Network Laboratories) 535 email: bob.mandeville@eunet.fr 536 35, rue Beaubourg 537 75003 Paris 538 France 539 phone: +33 07 47 67 10 540 fax: + 33 1 42 78 36 71 542 Bob Mandeville 543 ENL 544 European Network Laboratories 545 office phone, fax and voice mail: +33 1 42 78 36 71 546 mobile phone: +33 07 47 67 10