idnits 2.17.1 draft-ietf-bmwg-lanswitch-06.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-03-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 2 longer pages, the longest (page 1) being 62 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 a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4. Security Considerations' ) ** 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.) ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 645 has weird spacing: '...he case when ...' == Line 896 has weird spacing: '... in order...' -- 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 (August 1997) is 9713 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 (~~), 4 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: January 1998 August 1997 6 Benchmarking Terminology for LAN Switching Devices 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 26 Coast), or ftp.isi.edu (US West Coast). 28 This memo provides information for the Internet community. This memo 29 does not specify an Internet standard of any kind. Distribution of 30 this memo is unlimited. 32 Table of Contents 34 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 36 2. Existing definitions . . . . . . . . . . . . . . . . . . . . . . 3 38 3. Term definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 40 3.1 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . 3 42 3.1.1 Device under test (DUT) . . . . . . . . . . . . . . . . 3 43 3.1.2 System under test (SUT) . . . . . . . . . . . . . . . . 4 45 3.2 Traffic orientation . . . . . . . . . . . . . . . . . . . . 4 47 3.2.1 Unidirectional traffic . . . . . . . . . . . . . . . . 4 48 3.2.2 Bidirectional traffic . . . . . . . . . . . . . . . . . 6 50 3.3 Traffic distribution . . . . . . . . . . . . . . . . . . . . 7 52 3.3.1 One-to-one mapped traffic . . . . . . . . . . . . . . . 7 53 3.3.2 Partially meshed traffic . . . . . . . . . . . . . . . 7 54 3.3.3 Fully meshed traffic . . . . . . . . . . . . . . . . . 8 56 3.4 Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 3.4.1 Burst . . . . . . . . . . . . . . . . . . . . . . . . 10 59 3.4.2 Burst size . . . . . . . . . . . . . . . . . . . . . . 11 60 3.4.3 Inter-burst gap (IBG) . . . . . . . . . . . . . . . . 11 62 3.5 Loads . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 3.5.1 Intended load (Iload) . . . . . . . . . . . . . . . . 12 65 3.5.2 Offered load (Oload) . . . . . . . . . . . . . . . . . 13 66 3.5.3 Maximum offered load (MOL) . . . . . . . . . . . . . . 14 67 3.5.4 Overloading . . . . . . . . . . . . . . . . . . . . . 14 69 3.6 Forwarding rates . . . . . . . . . . . . . . . . . . . . . 15 71 3.6.1 Forwarding rate (FR) . . . . . . . . . . . . . . . . . 16 72 3.6.2 Forwarding rate at maximum offered load (FRMOL). . . . 16 73 3.6.3 Maximum forwarding rate (MFR). . . . . . . . . . . . . 17 75 3.7 Congestion control . . . . . . . . . . . . . . . . . . . . 18 77 3.7.1 Backpressure . . . . . . . . . . . . . . . . . . . . . 18 78 3.7.2 Forward pressure . . . . . . . . . . . . . . . . . . . 19 79 3.7.3 Head of line blocking . . . . . . . . . . . . . . . . 20 81 3.8 Address handling . . . . . . . . . . . . . . . . . . . . . 20 83 3.8.1 Address caching capacity . . . . . . . . . . . . . . . 21 84 3.8.2 Address learning rate . . . . . . . . . . . . . . . . 21 85 3.8.3 Flood count . . . . . . . . . . . . . . . . . . . . . 22 87 3.9 Errored frame filtering . . . . . . . . . . . . . . . . . . 22 89 3.9.1 Errored frames . . . . . . . . . . . . . . . . . . . . 22 91 3.10 Broadcasts . . . . . . . . . . . . . . . . . . . . . . . . 23 93 3.10.1 Broadcast forwarding rate at maximum load . . . . . . 23 94 3.10.2 Broadcast latency . . . . . . . . . . . . . . . . . . 24 96 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 24 98 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 102 7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25 104 1. Introduction 106 This Request for Comments (RFC) is intended to provide terminology 107 for the benchmarking of local area network (LAN) switching devices. 108 It extends the terminology already defined for benchmarking network 109 interconnect devices in RFCs 1242 and 1944 to switching devices. 111 Although it might be found useful to apply some of the terms defined 112 here to a broader range of network interconnect devices, this RFC 113 primarily deals with devices which switch frames at the Medium 114 Access Control (MAC) layer. It defines terms in relation to the 115 traffic put to use when benchmarking switching devices, forwarding 116 performance, latency, address handling and filtering. 118 2. Existing definitions 120 RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" 121 should be consulted before attempting to make use of this document. 122 RFC 1944 "Benchmarking Methodology for Network Interconnect Devices" 123 contains discussions of a number of terms relevant to the 124 benchmarking of switching devices and should also be consulted. 126 For the sake of clarity and continuity this RFC adopts the template 127 for definitions set out in Section 2 of RFC 1242. Definitions are 128 indexed and grouped together in sections for ease of reference. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 131 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in 133 RFC 2119. 135 3. Term definitions 137 3.1 Devices 139 This group of definitions applies to all types of networking 140 devices. 142 3.1.1 Device under test (DUT) 144 Definition: 146 The network forwarding device to which stimulus is offered and 147 response measured. 149 Discussion: 151 A single stand-alone or modular unit which receives frames on 152 or more of its interfaces and then forwards them to one or more 153 interfaces according to the addressing information contained in 154 the frame. 156 Measurement units: 158 n/a 160 Issues: 162 See Also: 164 system under test (SUT) (3.1.2) 166 3.1.2 System Under Test (SUT) 168 Definition: 170 The collective set of network devices to which stimulus is 171 offered as a single entity and response measured. 173 Discussion: 175 A system under test may be comprised of a variety of networking 176 devices. Some devices may be active in the forwarding decision- 177 making process, such as routers or switches; other devices may 178 be passive such as a CSU/DSU. Regardless of constituent 179 components, the system is treated as a singular entity to which 180 stimulus is offered and response measured. 182 Measurement units: 184 n/a 186 Issues: 188 See Also: 190 device under test (DUT) (3.1.1) 192 3.2 Traffic orientation 194 This group of definitions applies to the traffic presented to the 195 interfaces of a DUT/SUT and indicates whether the interfaces are 196 receiving only, transmitting only, or both receiving and 197 transmitting. 199 3.2.1 Unidirectional traffic 201 Definition: 203 When all frames presented to the input interfaces of a DUT/SUT 204 are addressed to output interfaces which do not themselves 205 receive any frames. 207 Discussion: 209 This definition conforms to the discussion in section 16 of RFC 210 1944 on multi-port testing which describes how unidirectional 211 traffic can be offered to a DUT/SUT to measure throughput. 212 Unidirectional traffic is also appropriate for: 214 -the measurement of the minimum inter-frame gap 215 -the creation of many-to-one or one-to-many interface overload 216 -the detection of head of line blocking 217 -the measurement of forwarding rates and throughput when 218 congestion control mechanisms are active. 220 When a tester offers unidirectional traffic to a DUT/SUT 221 reception and transmission are handled by different interfaces 222 or sets of interfaces of the DUT/SUT. All frames received from 223 the tester by the DUT/SUT are transmitted back to the tester 224 from interfaces which do not themselves receive any frames. 226 It is useful to distinguish traffic orientation and traffic 227 distribution when considering traffic patterns used in device 228 testing. Unidirectional traffic, for example, is traffic 229 orientated in a single direction between mutually exclusive 230 sets of source and destination interfaces of a DUT/SUT. Such 231 traffic, however, can be distributed between interfaces in 232 different ways. When traffic is sent to two or more 233 interfaces from an external source and then forwarded by the 234 DUT/SUT to a single output interface the traffic orientation is 235 unidirectional and the traffic distribution between interfaces 236 is many-to-one. Traffic can also be sent to a single input 237 interface and forwarded by the DUT/SUT to two or more output 238 interfaces to achieve a one-to-many distribution of traffic. 240 Such traffic distributions can also be combined to test for 241 head of line blocking or to measure forwarding rates and 242 throughput when congestion control is active. 244 When a DUT/SUT is equipped with interfaces running at different 245 media rates the number of input interfaces required to load or 246 overload an output interface or interfaces will vary. 248 It should be noted that measurement of the minimum inter-frame 249 gap serves to detect violations of the IEEE 802.3 standard. 251 Issues: 253 half duplex / full duplex 255 Measurement units: 257 n/a 259 See Also: 261 bidirectional traffic (3.2.2) 262 one-to-one mapped traffic (3.3.1) 263 partially meshed traffic (3.3.2) 264 fully meshed traffic (3.3.3) 265 congestion control (3.7) 266 head of line blocking (3.7.3) 268 3.2.2 Bidirectional traffic 270 Definition: 272 Frames presented to a DUT/SUT such that each of the interfaces 273 of the DUT/SUT both receive and transmit. 275 Discussion: 277 This definition conforms to the discussions in sections 14 and 278 16 of RFC 1944 on bidirectional traffic and multi-port testing. 280 When a tester offers bidirectional traffic to a DUT/SUT all the 281 interfaces which receive frames from the tester also transmit 282 frames back to the tester. 284 Bidirectional traffic MUST be offered when measuring throughput 285 on full duplex interfaces of a switching device. 287 Issues: 289 truncated binary exponential back-off algorithm 291 Measurement units: 293 n/a 295 See Also: 297 unidirectional traffic (3.2.1) 298 one-to-one mapped traffic (3.3.1) 299 partially meshed traffic (3.3.2) 300 fully meshed traffic (3.3.3) 302 3.3 Traffic distribution 304 This group of definitions applies to the distribution of frames 305 forwarded by any DUT/SUT. 307 3.3.1 One-to-one mapped traffic 309 Definition: 310 Frames offered to a single input interface and addressed to a 311 single output interface of a DUT/SUT where input and output 312 interfaces are grouped in mutually exclusive pairs. 314 Discussion: 316 In the simplest instance of one-to-one mapped traffic 317 distribution frames are forwarded between one source interface 318 and one destination interface of a DUT/SUT. One-to-one mapped 319 traffic distribution extends to multiple distinct pairs of 320 source and destination interfaces. 322 Measurement units: 324 n/a 326 Issues: 328 half duplex / full duplex 330 See Also: 332 unidrectional traffic (3.2.1) 333 bidirectional traffic (3.2.2) 334 partially meshed traffic (3.3.2.) 335 fully meshed traffic (3.3.3) 336 burst (3.4.1) 338 3.3.2 Partially meshed traffic 340 Definition: 342 Frames offered to one or more input interfaces of a DUT/SUT and 343 addressed to one or more output interfaces where input and 344 output interfaces are mutually exclusive and mapped one-to- 345 many, many-to-one or many-to-many. 347 Discussion: 348 This definition follows from the discussions in sections 14 and 349 16 of RFC 1944 on bidirectional traffic and multi-port testing. 350 Partially meshed traffic allows for one-to-many, many-to-one or 351 many-to-many mappings of input to output interfaces and readily 352 extends to configurations with multiple switching devices 353 linked together over backbone connections. 355 When partially meshed traffic is distributed in a one-to-many 356 or many-to-one mapping of receiving to transmitting interfaces 357 of a DUT/SUT traffic orientation will be unidirectional. When 358 traffic is partially meshed and distributed in a many-to-many 359 mapping of receiving to transmitting ports which are mutually 360 exclusive traffic orientation will be bidirectional. 362 Measurement units: 363 n/a 365 Issues: 367 half duplex / full duplex 369 See Also: 371 unidirectional traffic (3.2.1) 372 bidirectional traffic (3.2.2) 373 one-to-one mapped traffic (3.3.1) 374 fully meshed traffic (3.3.3) 375 burst (3.4.1) 377 3.3.3 Fully meshed traffic 379 Definition: 381 Frames switched simultaneously between all of a designated 382 number of interfaces of a DUT/SUT such that each of the 383 interfaces under test will both forward frames to and receive 384 frames from all of the other interfaces under test. 386 Discussion: 388 As with bidirectional multi-port traffic, meshed traffic 389 exercises both the transmission and reception sides of the 390 interfaces of a switching device. Since interfaces are not 391 divided into two groups every interface forwards frames to and 392 receives frames from every other interface. The total number 393 of individual input/output interface pairs when traffic is 394 meshed over n switched interfaces equals n x (n - 1). This 395 compares with n x (n / 2) such interface pairs in a 396 bidirectional multi-port test. 398 It should be noted that bidirectional multi-port traffic can 399 load backbone connections linking together two switching 400 devices more than fully meshed traffic. In a bidirectional 401 multiport test each one of two devices or systems connected 402 over a backbone connection can be configured to forward the 403 totality of the frames they receive to the devices or systems 404 placed on the opposite side of the backbone connection. All 405 frames generated during such a test will traverse the backbone 406 connection. Fully meshed traffic requires at least some of the 407 frames received on the interfaces of each one of the devices or 408 systems under test to be forwarded locally, that is to the 409 interfaces of the receiving devices themselves. Such frames 410 will not traverse the backbone connection. 412 Bidirectional meshed traffic on half duplex interfaces is 413 inherently bursty since interfaces must interrupt transmission 414 whenever they receive frames. This kind of bursty meshed 415 traffic is characteristic of real network traffic and can be 416 advantageously used to diagnose a DUT/SUT by exercising many of 417 its component parts simultaneously. Additional inspection may 418 be warranted to correlate the frame forwarding capacity of a 419 DUT/SUT when offered meshed traffic and the behavior of 420 individual elements such as input or output buffers, 421 buffer allocation mechanisms, aggregate switching capacity, 422 processing speed or medium access control. 424 The analysis of forwarding rate measurements presents a 425 challenge when offering bidirectional or fully meshed traffic 426 since the rate at which the tester can be observed to transmit 427 frames to the DUT/SUT may be smaller than the rate at which it 428 intends to transmit due to collisions on half duplex media or 429 the action of congestion control mechanisms. This makes it 430 important to take account of both the intended and offered 431 loads defined in sections 3.5.1.and 3.5.2 below when reporting 432 the results of such forwarding rate measurements. 434 When offering bursty meshed traffic to a DUT/SUT a number of 435 variables have to be considered. These include frame size, the 436 number of frames within bursts, the interval between bursts as 437 well as the distribution of load between incoming and outgoing 438 traffic. Terms related to bursts are defined in section 3.3 439 below. 441 Measurement units: 443 n/a 445 Issues: 447 half duplex / full duplex 449 See Also: 451 unidirectional traffic (3.2.1) 452 bidirectional traffic (3.2.2) 453 one-to-one mapped traffic (3.3.1) 454 partially meshed traffic (3.3.2) 455 burst (3.4.1) 456 intended load (3.5.1) 457 offered load (3.5.2) 459 3.4 Bursts 461 This group of definitions applies to the intervals between frames or 462 groups of frames offered to the DUT/SUT. 464 3.4.1 Burst 466 Definition: 468 A sequence of frames transmitted with the minimum inter-frame 469 gap allowed by the medium. 471 Discussion: 473 This definition follows from discussions in section 3.16 of RFC 474 1242 and section 21 of RFC 1944 which describes cases where it 475 is useful to consider isolated frames as single frame bursts. 477 Measurement units: 479 n/a 481 Issues: 483 See Also: 485 burst size (3.4.2) 486 inter-burst gap (IBG) (3.4.3) 488 3.4.2 Burst size 490 Definition: 492 The number of frames in a burst. 494 Discussion: 496 Burst size can range from one to infinity. In unidirectional 497 traffic as well as in bidirectional or meshed traffic on full 498 duplex interfaces there is no theoretical limit to burst 499 length. When traffic is bidirectional or meshed bursts on half 500 duplex media are finite since interfaces interrupt transmission 501 intermittently to receive frames. 503 On real networks burst size will normally increase with window 504 size. This makes it desirable to test devices with small as 505 well as large burst sizes. 507 Measurement units: 509 number of N-octet frames 511 Issues: 513 See Also: 515 burst (3.4.1) 516 inter-burst gap (IBG) (3.4.3) 518 3.4.3 Inter-burst gap (IBG) 520 Definition: 522 The interval between two bursts. 524 Discussion: 526 This definition conforms to the discussion in section 20 of RFC 527 1944 on bursty traffic. 529 Bidirectional and meshed traffic are inherently bursty since 530 interfaces share their time between receiving and transmitting 531 frames. External sources offering bursty traffic for a given 532 frame size and burst size must adjust the inter-burst gap to 533 achieve a specified average rate of frame transmission. 535 Measurement units: 537 nanoseconds 538 microseconds 539 milliseconds 540 seconds 542 Issues: 544 See Also: 546 burst (3.4.1) 547 burst size (3.4.2) 549 3.5 Loads 551 This group of definitions applies to the rates at which traffic is 552 offered to any DUT/SUT. 554 3.5.1 Intended load (Iload) 556 Definition: 558 The number of frames per second that an external source 559 attempts to transmit to a DUT/SUT for forwarding to a specified 560 output interface or interfaces. 562 Discussion: 564 Collisions on CSMA/CD links or the action of congestion control 565 mechanisms can effect the rate at which an external source of 566 traffic transmits frames to a DUT/SUT. This makes it useful to 567 distinguish the load that an external source attempts to apply 568 to a DUT/SUT and the load it is observed or measured to apply 570 In the case of Ethernet an external source of traffic MUST 571 Implement the truncated binary exponential back-off algorithm 572 to ensure that it is accessing the medium legally 574 Measurement units: 576 bits per second 577 N-octets per second 578 (N-octets per second / media_maximum-octets per second) x 100 580 Issues: 582 See Also: 584 burst (3.4.1) 585 inter-burst gap (3.4.3) 586 offered load (3.5.2) 588 3.5.2 Offered load (Oload) 590 Definition: 592 The number of frames per second that an external source can be 593 observed or measured to transmit to a DUT/SUT for forwarding to 594 a specified output interface or interfaces. 596 Discussion: 598 The load which an external device can be observed to apply to a 599 DUT/SUT may be less than the intended load due to collisions on 600 half duplex media or the action of congestion control 601 mechanisms. This makes it important to distinguish intended 602 and offered load when analyzing the results of forwarding rate 603 measurements using bidirectional or fully meshed traffic 605 Frames which are not successfully transmitted by an external 606 source of traffic to a DUT/SUT MUST NOT be counted as 607 transmitted frames when measuring the forwarding rate of a 608 DUT/SUT. 610 The frame count on an interface of a DUT/SUT may exceed the 611 rate at which an external device offers frames due to the 612 presence of spanning tree BPDUs (Bridge Protocol Data Units) on 613 802.1D-compliant switches or SNMP frames. Such frames should 614 be treated as modifiers as described in section 11 of RFC 1944 616 Measurement units: 618 bits per second 619 N-octets per second 620 (N-octets per second / media_maximum-octets per second) x 100 622 Issues: 624 token ring 626 See Also: 628 bidirectional traffic (3.2.2) 629 fully meshed traffic (3.3.3) 630 intended load (3.5.1) 631 forwarding rate (3.6.1) 633 3.5.3 Maximum offered load (MOL) 635 Definition: 637 The highest number of frames per second that an external source 638 can transmit to a DUT/SUT for forwarding to a specified output 639 interface or interfaces. 641 Discussion: 643 The maximum load that an external device can apply to a DUT/SUT 644 may not equal the maximum load allowed by the medium. This 645 will be the case when an external source lacks the resources 646 to transmit frames at the minimum legal inter-frame gap or when 647 it has sufficient resources to transmit frames below the 648 minimum legal inter-frame gap. Moreover, maximum load may vary 649 with respect to parameters other than a medium's maximum 650 theoretical utilization. For example, on those media employing 651 tokens, maximum load may vary as a function of Token Rotation 652 Time, Token Holding Time, or the ability to chain multiple 653 frames to a single token. The maximum load that an external 654 device applies to a DUT/SUT MUST be specified when measuring 655 forwarding rates. 657 Measurement units: 659 bits per second 660 N-octets per second 661 (N-octets per second / media_maximum-octets per second) x 100 663 Issues: 665 See Also: 667 offered load (3.5.2) 669 3.5.4 Overloading 671 Definition: 673 Attempting to load a DUT/SUT in excess of the maximum rate of 674 transmission allowed by the medium. 676 Discussion: 678 Overloading can serve to exercise buffers and buffer allocation 679 algorithms as well as congestion control mechanisms. 681 The number of input interfaces required to overload one or more 682 output interfaces of a DUT/SUT will vary according to the media 683 rates of the interfaces involved. 685 An external source can also overload an interface by 686 transmitting frames below the minimum inter-frame gap. A 687 DUT/SUT MUST forward such frames at intervals equal to or above 688 the minimum gap specified in standards. 690 A DUT/SUT using congestion control techniques such as 691 backpressure or forward pressure may exhibit no frame loss when 692 a tester attempts to overload one or more of its interfaces. 693 This should not be exploited to suggest that the DUT/SUT 694 supports rates of transmission in excess of the maximum rate 695 allowed by the medium since both techniques reduce the rate at 696 which the tester offers frames to prevent overloading. 697 Backpressure achieves this purpose by jamming the transmission 698 interfaces of the tester and forward pressure by hindering the 699 tester from gaining fair acces to the medium. Analysis of both 700 cases should take the distinction between intended load (3.5.1) 701 and offered load (3.5.2) into account. 703 Overloading can be achieved with unidirectional, bidirectional 704 and meshed traffic. 706 Measurement units: 708 N-octets per second 709 (N-octets per second / media_maximum-octets per second) x 100N- 710 octet 711 frames per second 713 Issues: 715 See Also: 717 unidirectional traffic (3.2.1) 718 intended load (3.5.1) 719 offered load (3.5.2) 720 forwarding rate (3.6.1) 721 backpressure (3.7.1) 722 forward pressure (3.7.2) 724 3.6 Forwarding rates 726 This group of definitions applies to the rates at which traffic is 727 forwarded by any DUT/SUT in response to a stimulus. 729 3.6.1 Forwarding rate (FR) 731 Definition: 733 The number of frames per second that a device can be observed 734 to successfully transmit to the correct destination interface 735 in response to a specified offered load. 737 Discussion: 739 Unlike throughput defined in section 3.17 of RFC 1242, 740 forwarding rate makes no explicit reference to frame loss. 741 Forwarding rate refers to the number of frames per second 742 observed on the output side of the interface under test an 743 MUST be reported in relation to the offered load. Forwarding 744 rate can be measured with different traffic orientations and 745 distributions. 747 It should be noted that the forwarding rate of a DUT/SUT may be 748 sensitive to the action of congestion control mechanisms. 750 Measurement units: 752 N-octet frames per second 754 Issues: 756 See Also: 758 offered load (3.5.2) 759 forwarding rate at maximum offered load (3.6.2) 760 maximum forwarding rate (3.6.3) 762 3.6.2 Forwarding rate at maximum offered load (FRMOL) 764 Definition: 766 The number of frames per second that a device can be observed 767 To successfully transmit to the correct destination interface 768 in response to the maximum offered load. 770 Discussion: 772 Forwarding rate at maximum offered load may be less than the 773 maximum rate at which a device can be observed to successfully 774 forward traffic. 776 This will be the case when the ability of a device to forward 777 frames degenerates when offered traffic at maximum load. 778 Maximum offered load MUST be cited when reporting forwarding 779 rate at maximum offered load. 781 Measurement units: 783 N-octet frames per second 785 Issues: 787 See Also: 789 maximum offered load (3.5.3) 790 forwarding rate (3.6.1) 791 maximum forwarding rate (3.6.3) 793 3.6.3 Maximum forwarding rate (MFR) 795 Definition: 797 The highest forwarding rate of a DUT/SUT taken from an 798 iterative set of forwarding rate measurements. 800 Discussion: 802 The forwarding rate of a device may degenerate before maximum 803 load is reached. The load applied to a device must be cited 804 when reporting maximum forwarding rate. 806 The following example illustrates how the terms relative to 807 loading and forwarding rates are meant to be used. In 808 particular it shows how the distinction between forwarding rate 809 at maximum offered load (FRMOL) and maximum forwarding rate 810 (MFR)can be used to characterize a DUT/SUT. 812 (A) (B) Column A - Oload 813 Test Device DUT/SUT Column B - FR 814 Offered Rate Forwarding Rate 815 ------------ --------------- 816 1. 14,880 fps 7,400 fps Row 1, Col A - MOL 817 2. 13,880 fps 8,472 fps Row 1, Col B - FRMOL 818 3. 12,880 fps 12,880 fps Row 3, Col B - MFR 820 Measurement units: 822 N-octet frames per second 824 Issues: 826 See Also: 828 offered load (3.5.2) 829 forwarding rates (3.6.1) 830 forwarding rate at maximum load (3.6.2) 832 3.7 Congestion control 834 This group of definitions applies to the behavior of a DUT/SUT when 835 congestion or contention is present. 837 3.7.1 Backpressure 839 Definition: 841 Any technique used by a DUT/SUT to attempt to avoid frame loss 842 by impeding external sources of traffic from transmitting 843 frames to congested interfaces. 845 Discussion: 847 Some switches send jam signals, for example preamble bits, back 848 to traffic sources when their transmit and/or receive buffers 849 start to overfill. Switches implementing full duplex Ethernet 850 links may use IEEE 802.3x Flow Control for the same purpose. 851 Such devices may incur no frame loss when external sources 852 attempt to offer traffic to congested or overloaded interfaces. 854 It should be noted that jamming and other flow control methods 855 may slow all traffic transmitted to congested input interfaces 856 including traffic intended for uncongested output interfaces. 858 A DUT/SUT applying backpressure may exhibit no frame loss when 859 a tester attempts to overload one or more of its interfaces. 860 This should not be interpreted to suggest that the interfaces 861 of the DUT/SUT support forwarding rates above the maximum rate 862 allowed by the medium. In these cases overloading is only 863 apparent since through the application of backpressure the 864 DUT/SUT avoids overloading by reducing the rate at which the 865 tester can offer frames. 867 Measurement units: 869 frame loss on congested interface or interfaces 870 N--octet frames per second between the interface applying 871 backpressure and an uncongested destination interface 873 Issues: 875 jamming not explicitly described in standards 877 See Also: 879 intended load (3.5.1) 880 offered load (3.5.2) 881 overloading (3.5.4) 882 forwarding rate (3.6.1) 883 forward pressure (3.7.2) 885 3.7.2 Forward pressure 887 Definition: 889 Methods which depart from or otherwise violate a defined 890 standardized protocol in an attempt to increase the forwarding 891 performance of a DUT/SUT. 893 Discussion: 895 A DUT/SUT may be found to inhibit or abort back-off algorithms 896 in order to force access to the medium when contention occurs. 897 It should be noted that the back-off algorithm should be fair 898 whether the DUT/SUT is in a congested or an uncongested state. 899 Transmission below the minimum inter-frame gap or the disregard 900 of flow control primitives fall into this category. 902 A DUT/SUT applying forward pressure may eliminate all or most 903 frame loss when a tester attempts to overload one or more of 904 its interfaces. This should not be interpreted to suggest that 905 the interfaces of the DUT/SUT can sustain forwarding rates 906 above the maximum rate allowed by the medium. Overloading in 907 such cases is only apparent since the application of forward 908 pressure by the DUT/SUT enables interfaces to relieve saturated 909 output queues by forcing access to the medium and concomitantly 910 inhibiting the tester from transmitting frames. 912 Measurement units: 914 intervals between frames in microseconds 915 intervals in microseconds between transmission retries during 916 16 successive collisions. 918 Issues: 920 truncated binary exponential back-off algorithm 922 See Also: 924 intended load (3.5.1) 925 offered load (3.5.2) 926 overloading (3.5.4) 927 forwarding rate (3.6.1) 928 backpressure (3.7.1) 930 3.7.3 Head of line blocking 932 Definition: 934 Frame loss or added delay observed on an uncongested output 935 interface whenever frames are received from an input interface 936 which is also attempting to forward frames to a congested 937 output interface. 939 Discussion: 941 It is important to verify that a switch does not slow 942 transmission or drop frames on interfaces which are not 943 congested whenever overloading on one of its other interfaces 944 occurs. 946 Measurement units: 948 frame loss recorded on an uncongested interface when receiving 949 frames from an interface which is also forwarding frames to a 950 congested interface. 952 Issues: 954 input buffers 956 See Also: 958 unidirectional traffic (3.2.1) 960 3.8 Address handling 962 This group of definitions applies to the process of address 963 resolution which enables a DUT/SUT to forward frames to the correct 964 destination. 966 3.8.1 Address caching capacity 968 Definition: 970 The number of MAC addresses per n interfaces, per module or per 971 device that a DUT/SUT can cache and successfully forward frames 972 to without flooding or dropping frames. 974 Discussion: 976 Users building networks will want to know how many nodes they 977 can connect to a DUT/SUT. This makes it necessary to verify 978 the number of MAC addresses that can be assigned per n 979 interfaces, per module and per chassis before a DUT/SUT begins 980 flooding frames. 982 Measurement units: 984 number of MAC addresses per n interfaces, per module and/or per 985 chassis 987 Issues: 989 See Also: 991 Address learning rate (3.8.2) 993 3.8.2 Address learning rate 995 Definition: 997 The maximum rate at which a switch can learn new MAC addresses 998 Before starting to flood or drop frames. 1000 Discussion: 1002 Users may want to know how long it takes a switch to build its 1003 address tables. This information is useful to have when 1004 considering how long it takes a network to come up when many 1005 users log on in the morning or after a network crash. 1007 Measurement units: 1009 frames per second with each successive frame sent to the switch 1010 containing a different source address. 1012 Issues: 1014 See Also: 1016 address caching capacity (3.8.1) 1018 3.8.3 Flood count 1020 Definition: 1022 Frames forwarded to interfaces which do not correspond to the 1023 destination MAC address information when traffic is offered to 1024 a DUT/SUT for forwarding. 1026 Discussion: 1028 When recording throughput statistics it is important to check 1029 that frames have been forwarded to their proper destinations. 1030 Flooded frames MUST NOT be counted as received frames. Both 1031 known and unknown unicast frames can be flooded. 1033 Measurement units: 1035 N-octet valid frames 1037 Issues: 1039 spanning tree BPDUs. 1041 See Also: 1043 address caching capacity (3.8.1) 1045 3.9 Errored frame filtering 1047 This group of definitions applies to frames with errors which a 1048 DUT/SUT may filter. 1050 3.9.1 Errored frames 1052 Definition: 1054 Frames which are over-sized, under-sized, misaligned or with an 1055 errored Frame Check Sequence. 1057 Discussion: 1059 Switches, unlike IEEE 802.1d compliant bridges, do not 1060 necessarily filter all types of illegal frames. Some switches, 1061 for example, which do not store frames before forwarding them 1062 to their destination interfaces may not filter over-sized 1063 frames (jabbers) or verify the validity of the Frame Check 1064 Sequence field. Other illegal frames are under-sized frames 1065 (runts) and misaligned frames. 1067 Measurement units: 1069 n/a 1071 Issues: 1073 See Also: 1075 3.10 Broadcasts 1077 This group of definitions applies to MAC layer and network layer 1078 broadcast frames. 1080 3.10.1 Broadcast forwarding rate 1082 Definition: 1084 The number of broadcast frames per second that a DUT/SUT can be 1085 observed to deliver to all interfaces located within a 1086 broadcast domain in response to a specified offered load of 1087 frames directed to the broadcast MAC address. 1089 Discussion: 1091 There is no standard forwarding mechanism used by switches to 1092 forward broadcast frames. It is useful to determine the 1093 broadcast forwarding rate for frames switched between 1094 interfaces on the same card, interfaces on different cards in 1095 the same chassis and interfaces on different chassis linked 1096 together over backbone connections. The terms maximum 1097 broadcast forwarding rate and broadcast forwarding rate at 1098 maximum load follow directly from the terms already defined for 1099 forwarding rate measurements in section 3.6 above. 1101 Measurement units: 1103 N-octet frames per second 1105 Issues: 1107 See Also: 1109 forwarding rate at maximum load (3.6.2) 1110 maximum forwarding rate (3.6.3) 1111 broadcast latency (3.10.2) 1113 3.10.2 Broadcast latency 1115 Definition: 1117 The time required by a DUT/SUT to forward a broadcast frame to 1118 each interface located within a broadcast domain. 1120 Discussion: 1122 Since there is no standard way for switches to process 1123 broadcast frames, broadcast latency may not be the same on all 1124 receiving interfaces of a switching device. The latency 1125 measurements SHOULD be bit oriented as described in 3.8 of 1126 RFC 1242. It is useful to determine broadcast latency for 1127 frames forwarded between interfaces on the same card, 1128 interfaces on different cards in the same chassis and 1129 interfaces on different chassis linked together over backbone 1130 connections. 1132 Measurement units: 1134 nanoseconds 1135 microseconds 1136 milliseconds 1137 seconds 1139 Issues: 1141 See Also: 1143 broadcast forwarding rate (3.10.1) 1145 4. Security Considerations 1147 Documents of this type do not directly effect the security of the 1148 Internet or of corporate networks as long as benchmarking is not 1149 performed on devices or systems connected to operating networks. 1151 The document points out that switching devices may violate the 1152 IEEE 802.3 standard by transmitting frames below the minimum 1153 interframe gap or unfairly accessing the medium by inhibiting the 1154 backoff algorithm. Although such violations do not directly 1155 engender breaches in security, they may perturb the normal 1156 functioning of other interworking devices by obstructing their 1157 access to the medium. Their use on the Internet or on corporate 1158 networks should be discouraged. 1160 5. References: 1162 1. RFC 1242 "Benchmarking Terminology for Network Interconnect 1163 Devices" 1164 2. RFC 1944 "Benchmarking Methodology for Network Interconnect 1165 Devices" 1167 6. Acknowledgments 1169 A special thanks goes to the IETF BenchMarking Methodology 1170 WorkGroup for the many suggestions it collectively made to help 1171 complete this RFC. Kevin Dubray (Bay Networks), Jean-Christophe 1172 Bestaux (ENL), Ajay Shah (WG), Henry Hamon (Netcom Systems), Stan 1173 Kopek (3Com) and Doug Ruby (Prominet) provided valuable input at 1174 various stages of this project. 1176 7. Author's Address 1178 Robert Mandeville 1179 European Network Laboratories (ENL) 1180 33, Boulevard Henri IV 1181 75004 Paris 1182 France 1184 phone: + 33 1 39 44 12 05 1185 mobile phone + 33 6 07 47 67 10 1186 fax: + 33 1 39 44 12 06 1188 email: bob.mandeville@eunet.fr