idnits 2.17.1 draft-ietf-bmwg-lanswitch-05.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 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 74 lines 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.) ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 226: '...traffic MUST be offered when measuring...' RFC 2119 keyword, line 469: '...DUT/SUT MUST NOT be counted as transmi...' RFC 2119 keyword, line 565: '...e under test and MUST be reported in r...' RFC 2119 keyword, line 860: '...ce. The latency measurements SHOULD be...' 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 (July 1997) is 9775 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: 9 errors (**), 0 flaws (~~), 2 warnings (==), 2 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 Expires in six months July 1997 5 Benchmarking Terminology for LAN Switching Devices 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 This memo provides information for the Internet community. This memo 28 does not specify an Internet standard of any kind. Distribution of 29 this memo is unlimited. 31 Table of Contents 33 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 34 2. Existing definitions. . . . . . . . . . . . . . . . . . . . . . . . 2 35 3. Term definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 3 37 3.1 Devices .. . . . . . . . . . . . . . . . . . . . . . . . . . 3 38 3.1.1 Device under test (DUT) . . . . . . . . . . . . . . . . 3 39 3.1.2 System under test (SUT). . . . . . . . . . . . . . . . 3 41 3.2 Traffic orientation. . . . . . . . . . . . . . . . . . . . . 3 42 3.2.1 Unidirectional traffic. . . . . . . . . . . . . . . . . 4 43 3.2.2 Bidirectional traffic . . . . . . . . . . . . . . . . . 5 45 3.3 Traffic distribution . . . . . . . . . . . . . . . . . . . . 5 46 3.3.1 One-to-one mapped traffic. .. . . . . . . . . . . . . . 5 47 3.3.2 Partially meshed traffic. . . . . . . . . . . . . . . . 6 48 3.3.3 Fully meshed traffic. . . . . . . . . . . . . . . . . . 6 50 3.4 Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . 8 51 3.4.1 Burst . . . . . . . . . . . . . . . . . . . . . . . . . 8 52 3.4.2 Burst size. . . . . . . . . . . . . . . . . . . . . . . 8 53 3.4.3 Inter-burst gap (IBG) . . . . . . . . . . . . . . . . . 9 55 3.5 Loads. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 3.5.1 Intended load (Iload) . . . . . . . . . . . . . . . . . 9 57 3.5.2 Offered load (Oload) . . . . . . . . . . . . . . . . . 10 58 3.5.3 Maximum offered load (MOL) . . . . . . . . . . . . . . 10 59 3.5.4 Overloading. . . . . . . . . . . . . . . . . . . . . . 11 61 3.6 Forwarding rates. . . . . . . . . . . . . . . . . . . . . . 12 62 3.6.1 Forwarding rate (FR) . . . . . . . . . . . . . . . . . 12 63 3.6.2 Forwarding rate at maximum offered load (FRMOL). . . . 12 64 3.6.3 Maximum forwarding rate (MFR). . . . . . . . . . . . . 13 66 3.7 Congestion control. . . . . . . . . . . . . . . . . . . . . 14 67 3.7.1 Backpressure . . . . . . . . . . . . . . . . . . . . . 14 68 3.7.2 Forward pressure . . . . . . . . . . . . . . . . . . . 14 69 3.7.3 Head of line blocking. . . . . . . . . . . . . . . . . 15 70 3.8 Address handling. . . . . . . . . . . . . . . . . . . . . . 15 71 3.8.1 Address caching capacity . . . . . . . . . . . . . . . 15 72 3.8.2 Address learning rate. . . . . . . . . . . . . . . . . 16 73 3.8.3 Flood count. . . . . . . . . . . . . . . . . . . . . . 16 75 3.9 Errored frame filtering . . . . . . . . . . . . . . . . . . 17 76 3.9.1 Errored frames . . . . . . . . . . . . . . . . . . . . 17 78 3.10 Broadcasts . . . . . . . . . . . . . . . . . . . . . . . . 17 79 3.10.1 Broadcast forwarding rate at maximum load . . . . . . 17 80 3.10.2 Broadcast latency . . . . . . . . . . . . . . . . . . 18 82 4. Security Considerations. . . . . . . . . . . . . . . . . . . . . . 18 83 5. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 1. Introduction 89 This document is intended to provide terminology for 90 the benchmarking of local area network (LAN) switching devices. It 91 extends the terminology already defined for benchmarking network 92 interconnect devices in RFCs 1242 and 1944 to switching devices. 93 Although it might be found useful to apply some of the terms defined 94 here to a broader range of network interconnect devices, this document 95 primarily deals with devices which switch frames at the Medium Access 96 Control (MAC) layer. It defines terms in relation to the traffic put to 97 use when benchmarking switching devices, forwarding performance, 98 latency, address handling and filtering. 100 2. Existing definitions 102 RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" 103 should be consulted before attempting to make use of this document. RFC 104 1944 "Benchmarking Methodology for Network Interconnect Devices" 105 contains discussions of a number of terms relevant to the benchmarking 106 of switching devices and should also be consulted. 108 For the sake of clarity and continuity this RFC adopts the template for 109 definitions set out in Section 2 of RFC 1242. Definitions are indexed 110 and grouped together in sections for ease of reference. 112 3. Term definitions 114 3.1 Devices 116 This group of definitions applies to all types of networking devices. 118 3.1.1 Device under test (DUT) 120 Definition: 121 The network forwarding device to which stimulus is offered and response 122 measured. 124 Discussion: 125 A single stand-alone or modular unit generally equipped with its own 126 power supply. 128 Measurement units: 129 n/a 131 Issues: 133 See Also: 134 system under test (SUT) (3.1.2) 136 3.1.2 System Under Test (SUT). 138 Definition: 139 The collective set of network devices to which stimulus is offered as a 140 single entity and response measured. 142 Discussion: 143 A system under test may be comprised of a variety of networking devices. 144 Some devices may be active in the forwarding decision-making process, 145 such as routers or switches; other devices may be passive such as a 146 CSU/DSU. Regardless of constituent components, the system is treated as 147 a singular entity to which stimulus is offered and response measured. 149 Measurement units: 150 n/a 152 Issues: 154 See Also: 155 device under test (DUT) (3.1.1) 157 3.2 Traffic orientation 159 This group of definitions applies to the traffic presented to the 160 interfaces of a DUT/SUT and indicates whether the interfaces are 161 receiving only, transmitting only, or both receiving and transmitting. 163 3.2.1 Unidirectional traffic 165 Definition: 167 Frames presented to a DUT/SUT such that the receiving and transmitting 168 interfaces are mutually exclusive. 170 Discussion: 171 This definition conforms to the discussion in section 16 of RFC 1944 on 172 multi-port testing which describes how unidirectional traffic can be 173 offered to a DUT/SUT to measure throughput. Unidirectional traffic is also 174 appropriate for: 176 -the measurement of the minimum inter-frame gap 177 -the creation of many-to-one or one-to-many interface overload 178 -the detection of head of line blocking 179 -the measurement of forwarding rates and throughput when congestion 180 control mechanisms are active. 182 When considering traffic patterns it is useful to distinguish traffic 183 orientation and traffic distribution. In the case of unidirectional 184 traffic, for example, traffic is orientated in a single direction 185 between mutually exclusive sets of source and destination interfaces 186 of a DUT/SUT. Such traffic, however, can be distributed between 187 interfaces in different ways. When traffic is sent to two or more 188 interfaces from an external source and forwarded by the DUT/SUT to 189 a single output interface traffic orientation is unidirectional and 190 traffic distribution between interfaces is many-to-one. Traffic can 191 also be sent to a single input interface and forwarded by the DUT/SUT 192 to two or more output interfaces to achieve a one-to-many distribution 193 of traffic between interfaces. 195 Such traffic distributions can also be combined to test for head of 196 line blocking or to measure forwarding rates and throughput when 197 congestion control is active. 199 When a DUT/SUT is equipped with interfaces running at different media 200 rates the number of input interfaces required to load or overload an 201 output interface or interfaces will vary. 203 It should be noted that measurement of the minimum inter-frame gap 204 serves to detect violations of the IEEE 802.3 standard. 206 Issues: 207 half duplex / full duplex 208 Measurement units: 209 n/a 211 See Also: 212 bidirectional traffic (3.2.2) 213 one-to-one mapped traffic (3.3.1) 214 partially meshed traffic (3.3.2) 215 fully meshed traffic (3.3.3) 217 3.2.2 Bidirectional traffic 219 Definition: 220 Frames presented to a DUT/SUT such that the interfaces of the DUT/SUT both 221 receive and transmit. 223 Discussion: 224 This definition conforms to the discussions in sections 14 and 16 of 225 RFC 1944 on bidirectional traffic and multi-port testing. Bidirectional 226 traffic MUST be offered when measuring throughput on full duplex 227 interfaces of a switching device. 229 Issues: 230 truncated binary exponential back-off algorithm 232 Measurement units: 233 n/a 235 See Also: 236 unidirectional traffic (3.2.1) 237 one-to-one mapped traffic (3.3.1) 238 partially meshed traffic (3.3.2) 239 fully meshed traffic (3.3.3) 241 3.3 Traffic distribution 243 This group of definitions applies to the distribution of frames 244 forwarded by any DUT/SUT. 246 3.3.1 One-to-one mapped traffic 248 Definition: 249 Frames offered to a single input interface and destined to a single 250 output interface of a DUT/SUT where input and output interfaces are 251 grouped in mutually exclusive pairs. 253 Discussion: 254 In the simplest instance of one-to-one mapped traffic distribution 255 frames are forwarded between one source interface and one destination 256 interface of a DUT/SUT. One-to-one mapped traffic distribution extends 257 to multiple distinct pairs of source and destination interfaces. 259 Measurement units: 260 n/a 262 Issues: 263 half duplex / full duplex 265 See Also: 266 unidrectional traffic (3.2.1) 267 bidirectional traffic (3.2.2) 268 partially meshed traffic (3.3.2.) 269 fully meshed traffic (3.3.3) 270 burst (3.4.1) 272 3.3.2 Partially meshed traffic 274 Definition: 275 Frames forwarded between mutually exclusive sets of input and output 276 interfaces of a DUT/SUT. 278 Discussion: 279 This definition follows from the discussions in sections 14 and 16 of 280 RFC 1944 on bidirectional traffic and multi-port testing. Partially 281 meshed traffic allows for one-to-many, many-to-one or many-to-many 282 mappings of input to output interfaces and readily extends to 283 configurations with multiple switching devices linked together over 284 backbone connections. 286 Measurement units: 287 n/a 289 Issues: 290 half duplex / full duplex 292 See Also: 293 unidirectional traffic (3.2.1) 294 bidirectional traffic (3.2.2) 295 one-to-one mapped traffic (3.3.1) 296 fully meshed traffic (3.3.3) 297 burst (3.4.1) 299 3.3.3 Fully meshed traffic 301 Definition: 302 Frames switched simultaneously between all of a designated number of 303 interfaces of a device such that each of the interfacess under test 304 will both forward frames to and receive frames from all of the other 305 interfaces under test. 307 Discussion: 308 As with bidirectional multi-port traffic, meshed traffic exercises both 309 the transmission and reception sides of the interfaces of a switching 310 device. Since interfaces are not divided into two groups every 311 interface forwards frames to and receives frames from every other 312 interface. The total number of individual input/output interface 313 pairs when traffic is meshed over n switched interfaces equals 314 n x (n - 1). This compares with n x (n / 2) such interface pairs in a 315 bidirectional multi-port test. 317 It should be noted that bidirectional multi-port traffic can load 318 backbone connections linking together two switching devices more 319 than meshed traffic. 321 Bidirectional meshed traffic on half duplex interfaces is inherently 322 bursty since interfaces must interrupt transmission whenever they 323 receive frames. This kind of bursty meshed traffic is characteristic 324 of real network traffic and can be advantageously used to diagnose a 325 DUT/SUT by exercising many of its component parts simultaneously. 326 Additional inspection may be warranted to correlate the frame 327 forwarding capacity of a DUT/SUT when offered meshed traffic and 328 the behavior of individual elements such as input or output buffers, 329 buffer allocation mechanisms, aggregate switching capacity, processing 330 speed or medium access control. 332 When offering bursty meshed traffic to a DUT/SUT a number of variables 333 have to be considered. These include frame size, the number of frames 334 within bursts, the interval between bursts as well as the distribution 335 of load between incoming and outgoing traffic. Terms related to bursts 336 are defined in section 3.3 below. 338 Measurement units: 339 n/a 341 Issues: 342 half duplex / full duplex 344 See Also: 345 unidirectional traffic (3.2.1) 346 bidirectional traffic (3.2.2) 347 one-to-one mapped traffic (3.3.1) 348 partially meshed traffic (3.3.2) 349 burst (3.4.1) 350 3.4 Bursts 352 This group of definitions applies to the intervals between frames or 353 groups of frames offered to the DUT/SUT. 355 3.4.1 Burst 357 Definition: 358 A sequence of frames transmitted with the minimum inter-frame gap 359 allowed by the medium. 361 Discussion: 362 This definition follows from discussions in section 3.16 of RFC 1242 363 and section 21 of RFC 1944 which describes cases where it is useful to 364 consider isolated frames as single frame bursts. 366 Measurement units: 367 n/a 369 Issues: 371 See Also: 372 burst size (3.4.2) 373 inter-burst gap (IBG) (3.4.3) 375 3.4.2 Burst size 377 Definition: 378 The number of frames in a burst. 380 Discussion: 381 Burst size can range from one to infinity. In unidirectional traffic 382 there is no theoretical limit to burst length. When traffic is 383 bidirectional or meshed bursts on half duplex media are finite since 384 interfaces interrupt transmission intermittently to receive frames. 385 On real networks burst size will normally increase with window size. 386 This makes it desirable to test devices with small as well as large 387 burst sizes. 389 Measurement units: 390 number of N-octet frames 392 Issues: 394 See Also: 395 burst (3.4.1) 396 inter-burst gap (IBG) (3.4.3) 397 3.4.3 Inter-burst gap (IBG) 399 Definition: 400 The interval between two bursts. 402 Discussion: 403 This definition conforms to the discussion in section 20 of RFC 1944 on 404 bursty traffic. 406 Bidirectional and meshed traffic are inherently bursty since interfaces 407 share their time between receiving and transmitting frames. External 408 sources offering bursty traffic for a given frame size and burst size 409 must adjust the inter-burst gap to achieve a specified rate of 410 transmission. 412 Measurement units: 413 nanoseconds 414 microseconds 415 milliseconds 416 seconds 418 Issues: 420 See Also: 421 burst (3.4.1) 422 burst size (3.4.2) 424 3.5 Loads 426 This group of definitions applies to the rates at which traffic is 427 offered to any DUT/SUT. 429 3.5.1 Intended load (Iload) 431 Definition: 432 The number of frames per second that an external source attempts to 433 transmit to a DUT/SUT for forwarding to a specified output interface or 434 interfaces. 436 Discussion: 437 Collisions on CSMA/CD links or the action of congestion control 438 mechanisms can effect the rate at which an external source of traffic 439 transmits frames to a DUT/SUT. This makes it useful to distinguish the 440 load that an external source attempts to apply to a DUT/SUT and the 441 load it is observed or measured to apply. 443 In the case of Ethernet an external source of traffic must implement 444 the truncated binary exponential back-off algorithm to ensure that it 445 is accessing the medium legally. 447 Measurement units: 448 bits per second 449 N-octets per second 450 (N-octets per second / media_maximum-octets per second) x 100 452 Issues: 454 See Also: 455 offered load (3.5.2) 457 3.5.2 Offered load (Oload) 459 Definition: 460 The number of frames per second that an external source can be observed 461 or measured to transmit to a DUT/SUT for forwarding to a specified 462 output interface or interfaces. 464 Discussion: 465 The load which an external device can be observed to apply to a DUT/SUT 466 may be less than the load the external device attempts to apply due to 467 collisions or the action of congestion control mechanisms. Frames which 468 are not successfully transmitted by an external source of traffic to a 469 DUT/SUT MUST NOT be counted as transmitted frames when measuring the 470 forwarding rate of a DUT/SUT. 472 The frame count on an interface of a DUT/SUT may exceed the rate at 473 which an external device offers frames due to the presence of spanning 474 tree BPDUs (Bridge Protocol Data Units) on 802.1D-compliant switches or 475 SNMP frames. Such frames should be treated as modifiers as described in 476 section 11 of RFC 1944. 478 Measurement units: 479 bits per second 480 N-octets per second 481 (N-octets per second / media_maximum-octets per second) x 100 483 Issues: 484 token ring 486 See also: 488 intended load (3.5.1) 490 3.5.3 Maximum offered load (MOL) 492 Definition: 493 The highest number of frames per second that an external source can 494 transmit to a DUT/SUT for forwarding to a specified output interface 495 or interfaces. 497 Discussion: 498 The maximum load that an external device can apply to a DUT/SUT may not 499 equal the maximum load allowed by the medium. This will be the case 500 when an external source lacks the resources to transmit frames at the 501 minimum legal inter-frame gap or when it has sufficient resources to 502 transmit frames below the minimum legal inter-frame gap. Moreover, 503 maximum load may vary with respect to parameters other than a medium's 504 maximum theoretical utilization. For example, on those media employing 505 tokens, maximum load may vary as a function of Token Rotation Time, 506 Token Holding Time, or the ability to chain multiple frames to a single 507 token. The maximum load that an external device applies to a DUT/SUT 508 MUST be specified when measuring forwarding rates. 510 Measurement units: 511 bits per second 512 N-octets per second 513 (N-octets per second / media_maximum-octets per second) x 100 515 Issues: 517 See Also: 518 offered load (3.5.2) 520 3.5.4 Overloading 522 Definition: 523 Attempting to load a DUT/SUT in excess of the maximum rate of 524 transmission allowed by the medium. 526 Discussion: 527 Overloading can serve to exercise buffers and buffer allocation 528 algorithms as well as congestion control mechanisms. 530 The number of input interfaces required to overload one or more output 531 interfaces of a DUT/SUT will vary according to the media rates of the 532 interfaces involved. An external source can also overload an interface 533 by transmitting frames below the minimum inter-frame gap. This can 534 serve to determine whether a device respects the minimum inter-frame 535 gap. 537 Overloading can be achieved with unidirectional, bidirectional and 538 meshed traffic. 540 Measurement units: 541 N-octets per second 542 (N-octets per second / media_maximum-octets per second) x 100 543 N-octet frames per second 544 Issues: 546 See Also: 547 offered load (3.5.2) 549 3.6 Forwarding rates 551 This group of definitions applies to the rates at which traffic is 552 forwarded by any DUT/SUT in response to a stimulus. 554 3.6.1 Forwarding rate (FR) 556 Definition: 557 The number of frames per second that a device can be observed to 558 successfully transmit to the correct destination interface in response 559 to a specified offered load. 561 Discussion: 562 Unlike throughput defined in section 3.17 of RFC 1242, forwarding rate 563 makes no explicit reference to frame loss. Forwarding rate refers to 564 the number of frames per second observed on the output side of the 565 interface under test and MUST be reported in relation to the offered 566 load. Forwarding rate can be measured with different traffic 567 orientations and distributions. 569 It should be noted that the forwarding rate of a DUT/SUT 570 may be sensitive to the action of congestion control mechanisms. 572 Measurement units: 573 N-octet frames per second 575 Issues: 577 See Also: 578 offered load (3.5.2) 579 forwarding rate at maximum offered load (3.6.2) 580 maximum forwarding rate (3.6.3) 582 3.6.2 Forwarding rate at maximum offered load (FRMOL) 584 Definition: 585 The number of frames per second that a device can be observed to 586 successfully transmit to the correct destination interface in response 587 to the maximum offered load. 589 Discussion: 590 Forwarding rate at maximum offered load may be less than the maximum 591 rate at which a device can be observed to successfully forward traffic. 592 This will be the case when the ability of a device to forward frames 593 degenerates when offered traffic at maximum load. Maximum offered load 594 MUST be cited when reporting forwarding rate at maximum offered load. 596 Measurement units: 597 N-octet frames per second 599 Issues: 601 See Also: 602 maximum offered load (3.5.3) 603 forwarding rate (3.6.1) 604 maximum forwarding rate (3.6.3) 606 3.6.3 Maximum forwarding rate (MFR) 608 Definition: 609 The highest forwarding rate of a DUT/SUT taken from an iterative set 610 of forwarding rate measurements. 612 Discussion: 613 The forwarding rate of a device may degenerate before maximum load is 614 reached. The load applied to a device must be cited when reporting 615 maximum forwarding rate. 617 The following example illustrates how the terms relative to loading and 618 forwarding rates are meant to be used. In particular it shows how the 619 distinction between forwarding rate at maximum offered load (FRMOL) 620 and maximum forwarding rate (MFR)can be used to characterize a DUT/SUT. 622 (A) (B) 623 Test Device DUT/SUT 624 Offered Rate Forwarding Rate 625 ------------ --------------- 626 1. 14,880 fps 7,400 fps 627 2. 13,880 fps 8,472 fps 628 3. 12,880 fps 12,880 fps 630 Column A - Oload 631 Column B - FR 632 Row 1, Col A - MOL 633 Row 1, Col B - FRMOL 634 Row 3, Col B - MFR 636 Measurement units: 637 N-octet frames per second 639 Issues: 641 See Also: 642 offered load (3.5.2) 643 forwarding rates (3.6.1) 644 forwarding rate at maximum load (3.6.2) 646 3.7 Congestion control 648 This group of definitions applies to the behavior of a DUT/SUT when 649 congestion or contention is present. 651 3.7.1 Backpressure 653 Definition: 654 Any technique used by a DUT/SUT to attempt to avoid frame loss by 655 impeding external sources of traffic from transmitting frames to 656 congested interfaces. 658 Discussion: 659 Some switches send jam signals, for example preamble bits, back to 660 traffic sources when their transmit and/or receive buffers start to 661 overfill. Switches implementing full duplex Ethernet links may use IEEE 662 802.3x Flow Control for the same purpose. Such devices may incur no 663 frame loss when external sources attempt to offer traffic to congested 664 or overloaded interfaces. 666 It should be noted that jamming and other flow control methods may slow 667 all traffic transmitted to congested input interfaces including traffic 668 intended for uncongested output interfaces. 670 Measurement units: 671 frame loss on congested interface or interfaces 672 N--octet frames per second between the interface applying backpressure 673 and an uncongested destination interface 675 Issues: 676 jamming not explicitly described in standards 678 See Also: 679 forward pressure (3.7.2) 681 3.7.2 Forward pressure 683 Definition: 684 Methods which depart from or otherwise violate a defined standardized 685 protocol in an attempt to increase the forwarding performance of a 686 DUT/SUT. 688 Discussion: 689 A DUT/SUT may be found to inhibit or abort back-off algorithms in order 690 to force access to the medium when contention occurs. It should be 691 noted that the back-off algorithm should be fair whether the DUT/SUT is 692 in a congested or an uncongested state. Transmission below the minimum 693 inter-frame gap or the disregard of flow control primitives fall into 694 this category. 696 Measurement units: 697 intervals between frames in microseconds 698 intervals in microseconds between transmission retries during 16 699 successive collisions. 701 Issues: 702 truncated binary exponential back-off algorithm 704 See also: 705 backpressure (3.7.1) 707 3.7.3 Head of line blocking 709 Definition: 710 Frame loss observed on an uncongested output interface whenever frames 711 are received from an input interface which is also attempting to 712 forward frames to a congested output interface. 714 Discussion: 715 It is important to verify that a switch does not slow transmission or 716 drop frames on interfaces which are not congested whenever overloading 717 on one of its other interfaces occurs. 719 Measurement units: 720 frame loss recorded on an uncongested interface when receiving frames 721 from an interface which is also forwarding frames to a congested 722 interface. 724 Issues:input buffers 726 See Also: 727 unidirectional traffic (3.2.1) 729 3.8 Address handling 731 This group of definitions applies to the process of address resolution 732 which enables a DUT/SUT to forward frames to the correct destination. 734 3.8.1 Address caching capacity 735 Definition: 736 The number of MAC addresses per n interfaces, per module or per device 737 that a DUT/SUT can cache and successfully forward frames to without 738 flooding or dropping frames. 740 Discussion: 742 Users building networks will want to know how many nodes they can 743 connect to a DUT/SUT. This makes it necessary to verify the number of 744 MAC addresses that can be assigned per n interfaces, per module and per 745 chassis before a DUT/SUT begins flooding frames. 747 Measurement units: 748 number of MAC addresses per n interfaces, per module and/or per chassis 750 Issues: 752 See Also: 753 Address learning rate (3.8.2) 755 3.8.2 Address learning rate 757 Definition: 758 The maximum rate at which a switch can learn new MAC addresses before 759 starting to flood or drop frames. 761 Discussion: 762 Users may want to know how long it takes a switch to build its address 763 tables. This information is useful to have when considering how long it 764 takes a network to come up when many users log on in the morning or 765 after a network crash. 767 Measurement units: 768 frames per second with each successive frame sent to the switch 769 containing a different source address. 771 Issues: 773 See Also: address caching capacity (3.8.1) 775 3.8.3 Flood count 777 Definition: 778 Frames forwarded to interfaces which do not correspond to the 779 destination MAC address information when traffic is offered to a 780 DUT/SUT for forwarding. 782 Discussion: 783 When recording throughput statistics it is important to check that 784 frames have been forwarded to their proper destinations. Flooded frames 785 MUST NOT be counted as received frames. Both known and unknown unicast 786 frames can be flooded. 788 Measurement units: 789 N-octet valid frames 791 Issues: 792 Spanning tree BPDUs. 794 See Also: 795 address caching capacity (3.8.1) 797 3.9 Errored frame filtering 799 This group of definitions applies to frames with errors which a DUT/SUT 800 may filter. 802 3.9.1 Errored frames 804 Definition: 805 Frames which are over-sized, under-sized, misaligned or with an errored 806 Frame Check Sequence. 808 Discussion: 809 Switches, unlike IEEE 802.1d compliant bridges, do not necessarily 810 filter all types of illegal frames. Some switches, for example, which 811 do not store frames before forwarding them to their destination 812 interfaces may not filter over-sized frames (jabbers) or verify the 813 validity of the Frame Check Sequence field. Other illegal frames are 814 under-sized frames (runts) and misaligned frames. 816 Measurement units:n/a 818 Issues: 820 See Also: 822 3.10 Broadcasts 823 This group of definitions applies to MAC layer and network layer 824 broadcast frames. 826 3.10.1 Broadcast forwarding rate 828 Definition: 829 The number of broadcast frames per second that a DUT/SUT can be 830 observed to deliver to all interfaces located within a broadcast domain 831 in response to a specified offered load. 833 Discussion: 834 There is no standard forwarding mechanism used by switches to forward 835 broadcast frames. It is useful to determine the broadcast forwarding 836 rate for frames switched between interfaces on the same card, interfaces 837 on different cards in the same chassis and interfaces on different 838 chassis linked together over backbone connections. The terms maximum 839 broadcast forwarding rate and broadcast forwarding rate at maximum load 840 follow directly from the terms already defined for forwarding rate 841 measurements in section 3.6 above.Measurement units: 842 N-octet frames per second 844 Issues: 846 See Also: 847 forwarding rate at maximum load (3.6.2) 848 maximum forwarding rate (3.6.3) 849 broadcast latency (3.10.2) 851 3.10.2 Broadcast latency 853 Definition: 854 The time required by a DUT/SUT to forward a broadcast frame to each 855 interface located within a broadcast domain. 857 Discussion: 858 Since there is no standard way for switches to process broadcast 859 frames, broadcast latency may not be the same on all receiving 860 interfaces of a switching device. The latency measurements SHOULD be 861 bit oriented as described in 3.8 of RFC 1242. It is useful to determine 862 broadcast latency for frames forwarded between interfaces on the same 863 card, interfaces on different cards in the same chassis and interfaces 864 on different chassis linked together over backbone connections. 866 Measurement units: 867 nanoseconds 868 microseconds 869 milliseconds 870 seconds 872 Issues: 874 See Also: 875 broadcast forwarding rate (3.10.1) 877 4. Security Considerations 879 This document raises no security issues. 881 5. References: 883 1. RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" 884 2. RFC 1944 "Benchmarking Methodology for Network Interconnect Devices" 886 6. Acknowledgments 888 A special thanks goes to the IETF BenchMarking Methodology WorkGroup 889 for the many suggestions it collectively made to help complete this RFC. 890 Kevin Dubray (Bay Networks), Jean-Christophe Bestaux (ENL), Ajay Shah 891 (WG), Henry Hamon (Netcom Systems), Stan Kopek (3Com) and Doug Ruby 892 (Prominet) provided valuable input at various stages of this project. 894 7. Author's Address 896 Robert Mandeville 897 European Network Laboratories (ENL) 898 6, Parc Ariane "Le Mercure" 899 Boulevard des Chenes 900 78284 Guyancourt 901 France 903 phone: + 33 1 39 44 12 05 or mobile phone + 33 6 07 47 67 10 904 fax: + 33 1 39 44 12 06 905 email: bob.mandeville@eunet.fr