idnits 2.17.1 draft-ietf-bmwg-lanswitch-01.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-26) 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 582 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 7 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 101: '...ectional traffic SHOULD be offered to ...' RFC 2119 keyword, line 137: '...ectional traffic MUST be offered when ...' RFC 2119 keyword, line 170: '...rwarded locally. Backbone tests SHOULD...' RFC 2119 keyword, line 245: '...burst size MUST adjust the inter-burst...' RFC 2119 keyword, line 286: '...Ethernet traffic MUST implement the tr...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (Nov 1996) is 10024 days in the past. Is this intentional? 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 (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Mandeville 3 INTERNET-DRAFT European Network Laboratories 4 Expiration Date: May 1997 Nov 1996 6 Benchmarking Terminology for LAN Switching Devices 8 < draft-ietf-bmwg-lanswitch-01.txt > 10 Status of this Document 12 This document is an Internet-Draft. Internet-Drafts are working documents 13 of the Internet Engineering Task Force (IETF), its areas, and its working 14 groups. Note that other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months and 18 may be updated, replaced, or obsoleted by other documents at any time. It 19 is inappropriate to use Internet- Drafts as reference material or to cite 20 them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 25 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 Distribution of this document is unlimited. Please send comments to 28 bmwg@harvard.edu or to the editor. 30 Abstract 32 The purpose of this draft is to define and discuss benchmarking terminology 33 for local area switching devices. It is meant to extend the terminology 34 already defined for network interconnect devices in RFCs 1242 and 1944 by 35 the Benchmarking Methodology Working Group (BMWG) of the Internet 36 Engineering Task Force (IETF). 38 LAN switches are one of the principal sources of new bandwidth in the local 39 area and are handling a significantly increasing proportion of network 40 traffic. The multiplicity of products brought to market makes it desirable 41 to define a set of terms to be used when evaluating the performance 42 characteristics of local area switching devices. Well-defined terminology 43 will help in providing the user community with complete, reliable and 44 comparable data on LAN switches. 46 1. Introduction 48 The purpose of this draft is to discuss and define terminology for the 49 benchmarking of LAN switching devices. This draft covers local area devices 50 which switch frames at the Media Access Control (MAC) layer. It discusses 51 throughput, latency, address handling and filtering. 53 2. Term definitions 55 A previous document, "Benchmarking Terminology for Network Interconnect 56 Devices" (RFC 1242), defined many of the terms that are used in this 57 document. The terminology document should be consulted before attempting to 58 make use of this document. A more recent document, "Benchmarking Methodology 59 for Network Interconnect Devices" (RFC 1944), defined a number of test 60 procedures which are directly applicable to switches. Since it discusses a 61 number of terms relevant to benchmarking switches it should also be consulted. 62 A number of new terms applicable to benchmarking switches are defined below 63 using the format for definitions set out in Section 2 of RFC 1242. RFCs 1242 64 and 1944 already contain discussions of some of these terms. 66 2. 1. Reminder of RFC 1242 definition format 68 Term to be defined. (e.g., Latency) 70 Definition: 71 The specific definition for the term. 73 Discussion: 74 A brief discussion about the term, it's application 75 and any restrictions on measurement procedures. 77 Measurement units: 78 The units used to report measurements of this 79 term, if applicable. 81 Issues: 82 List of issues or conditions that effect this term. 84 See Also: 85 List of other terms that are relevant to the discussion 86 of this term. 88 2.2. Unidirectional traffic 90 Definition: 92 Unidirectional traffic is made up of a single or multiple streams of frames 93 forwarded in one direction only from one or more ports of a switching device 94 designated as input ports to one or more other ports of the device 95 designated as output ports. 97 Discussion: 98 This definition conforms to the discussion in section 16 of RFC 1944 on 99 multi-port testing which describes how unidirectional traffic can be offered 100 to ports of a device to measure maximum rate of throughput. 101 Unidirectional traffic SHOULD be offered to devices for: 102 - the measurement of the minimum inter-frame gap 103 - the creation of many-to-one or one-to-many port overload 104 - the detection of head of line blocking 105 - the measurement of throughput when congestion control mechanisms are active 107 Unidirectional streams of traffic can be used to create different patterns 108 of traffic. For example unidirectional streams can be offered to two input 109 ports so as to overload a single output port (2-to-1) or they can be offered 110 to a single input port and switched by the device under test to two or more 111 output ports (1-to-2). Such patterns can be combined to test for head of 112 line blocking or to measure throughput when congestion control mechanisms 113 are active. 114 When devices are equipped with ports running at different media rates the 115 number of input streams required to load or overload an output port or ports 116 will vary. 118 Issues: 119 half duplex / full duplex 121 Measurement units: 122 n/a 124 See Also: 125 bidirectional traffic (2.3) 126 multidirectional traffic (2.4) 128 2.3. Bidirectional traffic 130 Definition: 131 Bidirectional traffic is made up of two or more streams of frames forwarded 132 in opposite directions between at two or more ports of a switching device. 134 Discussion: 135 This definition conforms to the discussions in sections 14 and 16 of RFC 136 1944 on bidirectional traffic and multi-port testing. 137 Bidirectional traffic MUST be offered when measuring the maximum rate of 138 throughput on full duplex ports of a switching device. 140 Issues: 141 truncated binary exponential back-off algorithm 143 Measurement units: 144 n/a 146 See Also: 147 unidirectional traffic (2.2) 148 multidirectional traffic (2.4) 150 2.4. Multidirectional traffic 152 Definition: 153 Multidirectional traffic is made up of streams of frames that are switched 154 simultaneously between multiple ports of a switching device. When such 155 streams are fully meshed each of the ports under test will both send frames 156 to and receive frames from all of the other ports under test. 158 Discussion: 159 This definition extends the discussions in sections 14 and 16 of RFC 1944 on 160 bidirectional traffic and multi-port testing. 161 As with bidirectional multi-port tests, multidirectional traffic exercises 162 both the transmission and reception sides of the ports of a switching 163 device. Since ports are not divided into two groups every port forwards 164 frames to and receives frames from every other port. The total number of 165 individual unidirectional streams offered in a multidirectional test for n 166 switched ports equals n x (n - 1). This compares with n x (n / 2) such 167 streams in a bidirectional multi-port test. It should be noted however that 168 bidirectional multiport tests create a greater load than multidirectional 169 tests on backbone connections linking together two switching devices because 170 none of the transmitted frames are forwarded locally. Backbone tests SHOULD 171 use bidirectional multi-port traffic. 172 Multidirectional traffic on half duplex ports is inherently bursty since 173 ports must interrupt transmission intermittently to receive frames. When 174 offering such bursty traffic to a device under test a number of variables 175 have to be considered. They include frame size, the number of frames within 176 bursts as well as the interval between bursts. The terms burst, burst size 177 and inter-burst gap are defined in sections 2.5, 2.6 and 2.7 below. 178 Bursty multidirectional traffic is characteristic of real network traffic. 179 It simultaneously exercises many of the component parts of a switching 180 device such as input and output buffers, buffer allocation mechanisms, 181 aggregate switching capacity, processing speed and behavior of the media 182 access controller. 184 Measurement units: 185 n/a 187 Issues: 188 half duplex / full duplex 190 See Also: 191 unidirectional traffic (2.2) 192 bidirectional traffic (2.3) 194 2.5 Burst 196 Definition: 197 A group of frames transmitted with the minimum inter-frame gap allowed by 198 the media. This definition allows for single frame bursts and infinite bursts. 200 Discussion: 201 This definition follows from the discussion in section 21 of RFC 1944. It is 202 useful to consider isolated frames as single frame bursts. 204 Measurement units: 205 n/a 207 Issues: 209 See Also: 210 burst size (2.6) 212 2.6 Burst size 214 Definition: 215 The number of frames in a burst. 217 Discussion: 218 Burst size can range from one to infinity. In unidirectional streams there 219 is no theoretical limit to the burst length. Bursts in bidirectional and 220 multidirectional streams of traffic on half duplex media are finite since 221 ports interrupt transmission intermittently to receive frames. 222 On real networks burst size can increase with window size. This makes it 223 desirable to test devices with small as well as large burst sizes. 225 Measurement units: 226 number of N-octet frames 228 Issues: 230 See Also: burst (2.5) 232 2.7 Inter-burst gap (IBG) 234 Definition: 235 The interval between two bursts. 237 Discussion: 238 This definition conforms to the discussion in section 20 of RFC 1944 on 239 bursty traffic. 240 Bidirectional and multidirectional streams of traffic are inherently bursty 241 since ports share their time between receiving and transmitting frames. The 242 rate of transmission of an external source of traffic is a function of the 243 number of frames per burst, frame length and the inter-burst gap. External 244 sources offering bursty multidirectional traffic for a given frame size and 245 burst size MUST adjust the inter-burst gap to achieve a specified rate of 246 transmission. 247 When a burst contains a single frame inter-burst gap and inter-frame gap are 248 equal. 249 When a burst is infinite the interburst gap equals the minimum inter-frame gap. 251 Measurement units: 252 nanoseconds 253 microseconds 254 milliseconds 255 seconds 257 Issues: 259 See Also: burst size (2.6), load (2.8) 261 2.8 Load, nominal and real 263 Definition: 264 The amount of traffic per second that a port transmits and receives. 266 Discussion: 267 Load can be expressed in a number of ways: bits per second, frames per 268 second with the frame size specified or as a percentage of the maximum frame 269 rate allowed by the media for a given frame size. A unidirectional stream of 270 7440 64-byte Ethernet frames per second is equivalent to a 50% load given 271 that the maximum rate of transmission on an Ethernet is 14880 64-byte frames 272 per second. 273 In the case of bidirectional or multidirectional traffic port load is the 274 sum of the frames transmitted and received on a port per second. 275 There is room for varying the balance between incoming and outgoing traffic 276 when loading ports with bidirectional and multidirectional traffic. In the 277 case of bidirectional traffic a 100% load can be created by offering a n% 278 load on one port and a (100 - n)% load on the opposite port. 279 Multidirectional traffic will be equally distributed over all ports under 280 test when all ports are offered 50% of the target load. 281 It has to kept in mind that an external source may not deliver frames to a 282 device under test at the desired rate due to collisions on CSMA/CD links or 283 the action of congestion control mechanisms. Because of this it is often 284 necessary to distinguish between the desired or target load (nominal load) 285 and the actual load (real load) offered to the device under test. 286 External sources of Ethernet traffic MUST implement the truncated binary 287 exponential back-off algorithm when executing bidirectional and 288 multidirectional performance tests to ensure that the external source of 289 traffic is accessing the medium legally. 290 Frames which are not successfully transmitted by the external source of 291 traffic to the device under test MUST NOT be not counted as transmitted 292 frames in performance benchmarks. 294 Measurement units: 295 bits per second 296 N-octets per second 297 (N-octets per second / media_maximum-octets per second) x 100 299 Issues: 300 token ring 302 2.9 Overload 304 Definition: 305 Loading a port or ports in excess of the maximum rate of transmission 306 allowed by the media. 308 Discussion: 309 Overloading can serve to exercise input and/or output buffers, buffer 310 allocation algorithms and congestion control mechanisms. Unidirectional 311 overloads require a minimum of two input and one output ports when all ports 312 run at the same nominal speed. 313 Bidirectional and multidirectional overloading occurs when the sum of the 314 traffic transmitted and received on each port exceeds the maximum media 315 rate. The external source of traffic MUST transmit at the same rate situated 316 between more than 50% and a 100% of the maximum media rate to each of the 317 ports under test in order to equally distribute an overload over all ports 318 under test. 320 Measurement units: 321 N-octet frames per second 323 Issues: nominal/real load 325 See Also: 327 2.10 Speed 329 Definition: 330 The number of frames that a device is capable of delivering to the correct 331 destination port in a given time interval. The maximum speed of a switching 332 device is the highest number of frames it can deliver during a one second 333 interval to the correct destination port. 335 Discussion: 336 Switching devices which exhibit no frame loss may be found to deliver frames 337 to their proper destination ports at differing rates. This may be due to the 338 action of congestion control mechanisms at high loads or the relative 339 aggressiveness of the truncated binary back-off algorithm. Speed MUST only 340 be sampled on the output side of the ports under test. This is because an 341 input port may receive frames at higher rates when the device under test 342 drops frames. 344 Measurement units: 345 N-octet frames per second 347 Issues: 349 See Also: 351 2.11 Flooded frame 353 Definition: 354 A unicast frame which is received on ports which do not correspond to the 355 frame's destination MAC address information. 357 Discussion: 358 When recording throughput statistics it is important to check that frames 359 have been forwarded to their proper destinations. Flooded frames MUST NOT be 360 counted as received frames. 362 Measurement units: 363 N-octet valid frames per second 365 Issues: 366 Spanning tree BPDUs. 368 See Also: 370 2.11 Backpressure 372 Definition: 373 A jamming technique used by some switching devices to avoid frame loss when 374 one or more of its ports are saturated. 376 Discussion: 377 Some switches are designed to send jamming signals back to traffic sources 378 when ports begin to saturate. Such devices may incur no frame loss when 379 ports are offered target loads in excess of 100% by external traffic 380 sources. Jamming however affects traffic destined to congested as well as 381 uncongested ports so it is important to measure the maximum speed at which a 382 device can forward frames to both congested and uncongested ports when 383 backpressure mechanisms are active. 385 Measurement units: 386 N--octet frames per second between the jamming port and an uncongested 387 destination port 389 Issues: 390 not explicitly described in standards 392 See Also: 393 forward pressure (2.12) 395 2.12 Forward pressure 397 Definition: 398 A technique which modifies the truncated binary exponential backoff 399 algorithm to avoid frame loss when congestion on one or more of the ports 400 under test occurs. 402 Discussion: 403 Some switches avoid buffer overload by retransmitting buffered frames 404 without waiting for the interval calculated by the normal operation of the 405 backoff algorithm. It is useful to measure how aggressive a switch's backoff 406 algorithm is in both congested and uncongested states. Forward pressure 407 reduces the number of collisions when congestion on a port builds up. 409 Measurement units: 410 intervals in microseconds between transmission retries during 16 successive 411 collisions. 413 Issues: 414 not explicitly described in standards 416 See also: 417 backpressure (2.11) 419 2.13 Head of line blocking 421 Definition: 422 A pathological state whereby a switch drops frames forwarded to an 423 uncongested port whenever frames are forwarded from the same source port to 424 a congested port. 426 Discussion: 427 It is important to verify that a switch does not propagate frame loss to 428 ports which are not congested whenever overloading on one of its ports occurs. 430 Measurement units: 431 frame loss recorded on an uncongested port when receiving frames from a port 432 which is also forwarding frames to a congested destination port. 434 Issues: 435 Input buffers 437 See Also: 439 2.14 Address handling 441 Definition: 442 The number of MAC addresses per port, per module or per device which a 443 switch can cache and successfully forward frames to without flooding or 444 dropping frames. 446 Discussion: 448 Users building networks will want to know how many nodes they can connect to 449 a switch. This makes it necessary to verify the number of MAC addresses that 450 can be assigned per port, per module and per chassis before a switch begins 451 flooding frames. 453 Measurement units: 454 number of MAC addresses 456 Issues: 458 See Also: 460 2.15 Address learning rate 462 Definition: 463 The maximum rate at which a switch can learn MAC addresses before starting 464 to flood or drop frames. 466 Discussion: 467 Users may want to know how long it takes a switch to build up its address 468 tables. This information is useful to have when considering how long it 469 takes a network to come up when many users log on in the morning or after a 470 network crash. 472 Measurement units: 473 frames per second with each successive frame sent to the switch containing a 474 different source address. 476 Issues: 478 See Also: address handling (2.14) 480 2.16 Filtering illegal frames 482 Definition: 483 Switches do not necessarily filter all types of illegal frames. Some 484 switches, for example, do not store frames before forwarding them to their 485 destination ports. These so-called cut-through switches forward frames after 486 reading the destination and source address fields. They do not normally 487 filter over-sized frames (jabbers) or verify the validity of the Frame Check 488 Sequence field. Other examples of illegal frame types are under-sized frames 489 (runts), misaligned frames and frames followed by dribble bits. 491 Measurement units: 492 N-octet frames filtered or not filtered 494 Issues: 496 See Also: 498 2.17 Broadcast rate 500 Definition: 501 The number of broadcast frames forwarded by the device under test per 502 second. The maximum broadcast rate corresponds to highest number of 503 broadcast frames a switch can forward either locally or over a backbone 504 connection. 506 Discussion: 507 There is no standard forwarding mechanism used by switches to forward 508 broadcast frames. It is useful to determine the broadcast forwarding rate 509 both locally and over backbone connections. 511 Measurement units: 512 N-octet frames per second 514 Issues: 516 See Also: 517 broadcast latency 519 2.18 Broadcast latency 521 Definition: 522 The time it takes a broadcast frame to go through a switching device and be 523 forwarded to each destination port. 525 Discussion: 526 Since there is no standard way for switches to process broadcast frames, 527 broadcast latency may not be the same on all receiving ports of a switching 528 device. Broadcast latency SHOULD be determined on all receiving ports both 529 locally and, if applicable, over backbone connections. 531 Measurement units: 532 The latency measurements SHOULD be bit oriented as described in 3.8 of RFC 533 1242 and reported for all connected receive ports. 535 Issues: 537 See Also: 538 broadcast rate 540 3. Acknowledgments 542 In order of appearance Ajay Shah of Wandel & Goltermann, Jean-Christophe 543 Bestaux of European Network Laboratories, Stan Kopek of Digital Equipment 544 Corporation, Henry Hamon of Netcom Systems and Kevin Dubray of Bay Networks 545 were all instrumental in getting this draft done. 546 A special thanks goes to the IETF BenchMark WorkGroup for the many 547 suggestions it collectively made to help shape this draft. 548 The editor 549 Bob Mandeville 551 4. Editor's Address 553 Robert Mandeville 554 ENL (European Network Laboratories) 555 email: bob.mandeville@eunet.fr 556 35, rue Beaubourg 557 75003 Paris 558 France 559 phone: +33 6 07 47 67 10 560 fax: + 33 1 42 78 36 71 562 !!!PLEASE TAKE NOTE!!! 563 ENL HAS MOVED TO A NEW SITE: 565 Robert Mandeville, ENL 566 European Network Laboratories 567 6 Parc Ariane, le Mercure 568 Blvd des Chenes 569 78284 Guyancourt 570 France 572 NEW LAB PHONE, FAX, VOICE MAIL: +33 1 39 44 12 05 573 mobile phone: +33 6 07 47 67 10