idnits 2.17.1 draft-ietf-bmwg-mcast-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-16) 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 537: '...principal result MUST be reported in c...' RFC 2119 keyword, line 574: '...ncy measurements MUST be reported with...' RFC 2119 keyword, line 601: '...lay measurements MUST be reported with...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...ment is an I...' == Line 12 has weird spacing: '...cuments of t...' == Line 13 has weird spacing: '...ups may also ...' == Line 17 has weird spacing: '... and may be...' == Line 18 has weird spacing: '...me. It is i...' == (43 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (August 1998) is 9376 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) == Unused Reference: 'Br91' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'Br96' is defined on line 635, but no explicit reference was found in the text == Unused Reference: 'Ma98' is defined on line 643, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. 'Br91') ** Obsolete normative reference: RFC 1944 (ref. 'Br96') (Obsoleted by RFC 2544) -- Possible downref: Non-RFC (?) normative reference: ref. 'Hu95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Se98' ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. 'Ma98') -- Possible downref: Non-RFC (?) normative reference: ref. 'Mt98' Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Dubray 3 INTERNET-DRAFT IronBridge Networks 4 Expiration Date: Febuary 1999 August 1998 6 Terminology for IP Multicast Benchmarking 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 areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on the ftp.is.co.za (Africa), ftp.nordu.net (Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 25 Rim), ftp.ietf.org (US East 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 Abstract 33 The purpose of this document is to define terminology specific to the 34 benchmarking of multicast IP forwarding devices. It builds upon the 35 tenets set forth in RFC 1242, RFC 2285, and other IETF Benchmarking 36 Methodology Working Group (BMWG) efforts. This document seeks to 37 extend these efforts to the multicast paradigm. 39 The BMWG produces two major classes of documents: Benchmarking 40 Terminology documents and Benchmarking Methodology documents. The 41 Terminology documents present the benchmarks and other related terms. 42 The Methodology documents define the procedures required to collect 43 the benchmarks cited in the corresponding Terminology documents. 45 1. Introduction 47 Network forwarding devices are being required to take a single frame 48 and support delivery to a number of destinations having membership to 49 a particular group. As such, multicast support may place a different 50 burden on the resources of these network forwarding devices than with 51 unicast or broadcast traffic types. 53 Such burdens may not be readily apparent at first glance - the IP 54 multicast packet's Class D address may be the only noticeable 55 difference from an IP unicast packet. However, there are many 56 factors that may impact the treatment of IP multicast packets. 58 Consider how a device's architecture may impact the handling of a 59 multicast frame. For example, is the multicast packet subject to the 60 same processing as its unicast analog? Or is the multicast packet 61 treated as an exeception and processed on a different data path? 62 Consider, too, how a shared memory architecture may demonstrate a 63 different performance profile than an architecture which explicitly 64 passes each individual packet between the processing entities. 66 In addition to forwarding device architecture, there are other 67 factors that may impact a device's or system's multicast related 68 performance. Protocol requirements may demand that routers and 69 switches consider destination and source addressing in its multicast 70 forwarding decisions. Capturing multicast source/destination 71 addressing information may impact forwarding table size and lengthen 72 lookups. Topological factors such as the degree of packet 73 replication, the number of multicast groups being supported by the 74 system, or the placement of multicast packets in unicast wrappers to 75 span non-multicast network paths may all potentially affect a 76 system's multicast related performance. For an overall understanding 77 of IP multicasting, the reader is directed to [Se98], [Hu95], and 78 [Mt98]. 80 By clearly identifying IP multicast benchmarks and related 81 terminology in this document, it is hoped that detailed methodologies 82 can be generated in subsequent documents. Taken in tandem, these two 83 efforts endeavor to assist the clinical, empirical, and consistent 84 characterization of certain aspects of multicast technologies and 85 their individual implementations. Understanding the operational 86 profile of multicast forwarding devices may assist the network 87 designer to better deploy multicast in his or her networking 88 environment. 90 This work is primarily directed towards intermediate IP multicast 91 forwarding devices (e.g., routers or switches) on LANs. Elements of 92 this text may or may not be applicable to other media as well. 93 Moreover, this document focuses on one source to many destinations 94 profiling. Elements of this document may require extension when 95 considering multiple source to multiple destination IP multicast 96 communication. 98 2. Definition Format 100 This section cites the template suggested by RFC 1242 in the 101 specification of a term to be defined. 103 Term to be defined. 105 Definition: 106 The specific definition for the term. 108 Discussion: 109 A brief discussion of the term, its application and any 110 restrictions on measurement procedures. 112 Measurement units: 113 Units used to record measurements of this term, if applicable. 115 [Issues:] 116 List of issues or conditions that effect this term. This 117 field is optional in this document. 119 [See Also:] 120 List of other terms that are relevant to the discussion 121 of this term. This field is optional in this document. 123 2.1 Existing Terminology 125 This document draws on existing terminology defined in other BMWG 126 work. Examples include, but are not limited to: 128 Throughput (RFC 1242, section 3.17) 129 Latency (RFC 1242, section 3.8) 130 Constant Load (RFC 1242, section 3.4) 131 Frame Loss Rate (RFC 1242, section 3.6) 132 Overhead behavior (RFC 1242, section 3.11) 133 Forwarding Rates (RFC 2285, section 3.6) 134 Loads (RFC 2285, section 3.5) 135 Devices (RFC 2285, section 3.1) 137 3. Table of Defined Terms 139 3.1 General Nomenclature 140 3.1.1 Traffic Class. 141 3.1.2 Group Class. 142 3.1.3 Service Class. 144 3.2 Forwarding and Throughput 145 3.2.1 Mixed Class Throughput (MCT). 146 3.2.2 Scaled Group Forwarding Matrix (SGFM). 147 3.2.3 Aggregated Multicast Throughput (AMT) 148 3.2.4 Encapsulation Throughput (ET) 149 3.2.5 Decapsulation Throughput (DT) 150 3.2.6 Re-encapsulation Throughput (RET) 152 3.3 Forwarding Latency 153 3.3.1 Multicast Latency 154 3.3.2 Min/Max Multicast Latency 156 3.4 Overhead 157 3.4.1 Group Join Delay. 158 3.4.2 Group Leave Delay. 160 3.5 Capacity 161 3.5.1 Multicast Group Capacity. 163 3.6 Interaction 164 3.6.1 Burdened Response 165 3.6.2 Forwarding Burdened Multicast Latency 166 3.6.3 Forwarding Burdened Join Delay 168 3.1 General Nomenclature 170 This section will present general terminology to be used in 171 this and other documents. 173 3.1.1 Traffic Class. 175 Definition: 176 An equivalence class of packets comprising one or more data 177 streams. 179 Discussion: 180 In the scope of this document, Traffic Class will be considered 181 a logical identifier used to discriminate between a set or sets 182 of packets offered the DUT. 184 For example, one Traffic Class may identify a set of unicast pack- 185 ets offered to the DUT. Another Traffic Class may differentiate 186 the multicast packets destined to multicast group X. Yet another 187 Class may distinguish the set of multicast packets destined to 188 multicast group Y. 190 Unless otherwise qualified, the usage of the word "Class" in this 191 document will refer simply to a Traffic Class. 193 Measurement units: 194 Not applicable. 196 3.1.2 Group Class. 198 Definition: 199 A specific type of Traffic Class where the packets comprising the 200 Class are destined to a particular multicast group. 202 Discussion: 204 Measurement units: 205 Not applicable. 207 3.1.3 Service Class. 209 Definition: 210 A specific type of Traffic Class where the packets comprising the 211 Class require particular treatment or treatments by the network 212 forwarding devices along the path to the packets' destination(s). 214 Discussion: 216 Measurement units: 217 Not applicable. 219 3.2 Forwarding and Throughput. 221 This section presents terminology related to the characterization of 222 the packet forwarding ability of a DUT/SUT in a multicast 223 environment. Some metrics extend the concept of throughput 224 presented in RFC 1242. The notion of Forwarding Rate is cited in 225 RFC 2285. 227 3.2.1 Mixed Class Throughput (MCT). 229 Definition: 230 The maximum rate at which none of the offered frames, comprised 231 from a unicast Class and a multicast Class, to be forwarded are 232 dropped by the device across a fixed number of ports. 234 Discussion: 235 Often times, throughput is collected on a homogenous traffic 236 class - the offered load to the DUT is either singularly unicast or 237 singularly multicast. In most networking environments, the traffic 238 mix is seldom so uniformly distributed. 240 Based on the RFC 1242 definition for throughput, the Mixed 241 Class Throughput benchmark attempts to characterize the DUT's 242 ability to process both unicast and multicast frames in the 243 same aggregated traffic stream. 245 Measurement units: 246 Frames per second 248 Issues: 249 Related methodology may have to address the ratio of unicast 250 packets to multicast packets. 252 3.2.2 Scaled Group Forwarding Matrix (SGFM). 254 Definition: 255 A table that demonstrates Forwarding Rate as a function of 256 tested multicast groups for a fixed number of tested 257 DUT/SUT ports. 259 Discussion: 260 A desirable attribute of many Internet mechanisms is the ability 261 to "scale." This benchmark seeks to demonstrate the ability 262 of a SUT to forward as the number of multicast groups is scaled 263 upwards. 265 Measurement units: 266 Packets per second, with corresponding tested multicast group 267 and port configurations. 269 Issues: 270 The corresponding methodology may have to reflect the impact 271 that the pairing (source, group) has on many multicast routing 272 protocols. 274 3.2.3 Aggregated Multicast Throughput (AMT) 276 Definition: 277 The maximum rate at which none of the offered frames to be 278 forwarded through N destination interfaces of the same multicast 279 group are dropped. 281 Discussion: 282 Another "scaling" type of exercise, designed to identify the 283 DUT/SUT's ability to handle traffic as a function of the 284 multicast destination ports it is required to support. 286 Measurement units: 287 The ordered pair (N,t) where, 289 N = the number of destination ports of the multicast group. 290 t = the throughput, in frames per second, relative to the 291 source stream. 293 3.2.4 Encapsulation Throughput (ET) 295 Definition: 296 The maximum rate at which frames offered a DUT are encapsulated 297 and correctly forwarded by the DUT without loss. 299 Discussion: 300 A popular technique in presenting a frame to a device that may 301 not support a protocol feature is to encapsulate, or tunnel, 302 the packet containing the unsupported feature in a format that 303 is supported by that device. 305 More specifically, encapsulation refers to the act of taking a 306 frame or part of a frame and embedding it as a payload of another 307 frame. This benchmark attempts to characterize the overhead 308 behavior associated with that translational process. 310 Consideration may need to be given with respect to the impact 311 of different frame formats on usable bandwidth. 313 Measurement units: 314 Frames per second. 316 3.2.5 Decapsulation Throughput (DT) 318 Definition: 319 The maximum rate at which frames offered a DUT are decapsulated 320 and correctly forwarded by the DUT without loss. 322 Discussion: 323 A popular technique in presenting a frame to a device that may 324 not support a protocol feature is to encapsulate, or tunnel, 325 the packet containing the unsupported feature in a format that 326 is supported by that device. At some point, the frame may be 327 required to be returned its orginal format from its encapsulation 328 wrapper for use by the frame's next destination. 330 More specifically, decapsulation refers to the act of taking a 331 frame or part of a frame embedded as a payload of another frame 332 and returning it to the payload's appropriate format. This 333 benchmark attempts to characterize the overhead behavior associated 334 with that translational process. 336 Consideration may need to be given with respect to the impact 337 of different frame formats on usable bandwidth. 339 Measurement units: 340 Frames per second. 342 3.2.6 Re-encapsulation Throughput (RET) 344 Definition: 345 The maximum rate at which frames of one encapsulated format offered 346 a DUT are converted to another encapsulated format and correctly 347 forwarded by the DUT without loss. 349 Discussion: 350 A popular technique in presenting a frame to a device that may 351 not support a protocol feature is to encapsulate, or tunnel, 352 the packet containing the unsupported feature in a format that 353 is supported by that device. At some point, the frame may be 354 required to be converted from one encapsulation format to another 355 encapsulation format. 357 More specifically, re-encapsulation refers to the act of taking an 358 encapsulated payload of one format and replacing it with another 359 encapsulated format - all the while preserving the original 360 payload's contents. This benchmark attempts to characterize the 361 overhead behavior associated with that translational process. 363 Consideration may need to be given with respect to the impact 364 of different frame formats on usable bandwidth. 366 Measurement units: 367 Frames per second. 369 3.3 Forwarding Latency. 371 This section presents terminology relating to the characterization of 372 the forwarding latency of a DUT/SUT in a multicast environment. 373 It extends the concept of latency presented in RFC 1242. 375 3.3.1 Multicast Latency. 377 Definition: 378 The set of individual latencies from a single input port on 379 the DUT or SUT to all tested ports belonging to the destination 380 multicast group. 382 Discussion: 383 This benchmark is based on the RFC 1242 definition of latency. 384 While it is useful to collect latency between a pair of source 385 and destination multicast ports, it may be insightful to collect 386 the same type of measurements across a range of ports supporting 387 that Group Class. 389 A variety of statistical exercises can be applied to the set of 390 latencies measurements. 392 Measurement units: 393 Time units with enough precision to reflect a latency measurement. 395 3.3.2 Min/Max Multicast Latency. 397 Definition: 398 The difference between the maximum latency measurement and the 399 minimum latency measurement from the set of latencies produced by 400 the Multicast Latency benchmark. 402 Discussion: 403 This statistic may yield some insight into how a particular 404 implementation handles its multicast traffic. This may be useful 405 to users of multicast synchronization types of applications. 407 Measurement units: 408 Time units with enough precision to reflect latency measurement. 410 3.4 Overhead 412 This section presents terminology relating to the characterization of 413 the overhead delays associated with explicit operations found in 414 multicast environments. 416 3.4.1 Group Join Delay. 418 Definition: 419 The time duration it takes a DUT/SUT to start forwarding multicast 420 packets from the time a successful IGMP group membership report has 421 been issued to the DUT/SUT. 423 Discussion: 424 Many factors can contribute to different results, such as 425 the number or type of multicast-related protocols configured 426 on the system under test. Other factors are physical topology and 427 "tree" configuration. 429 Because of the number of variables that could impact this metric, 430 the metric may be a better characterization tool for a device or 431 system rather than a basis for comparisons with other devices. 433 A consideration for the related methodology: possible need to 434 differentiate a specifically-forwarded multicast frame from those 435 sprayed by protocols implementing a flooding tactic to solicit 436 prune feedback. 438 Issues: 439 While this metric attempts to identify a simple delay, the 440 underlying and contributing delay components (e.g., propagation 441 delay, frame processing delay, etc.) make this a less than simple 442 measurement. The corresponding methodology will need to consider 443 this and similar factors to ensure a consistent and precise 444 metric result. 446 Measurement units: 447 Microseconds. 449 3.4.2 Group Leave Delay. 451 Definition: 452 The time duration it takes a DUT/SUT to cease forwarding multicast 453 packets after a corresponding IGMP "Leave Group" message has been 454 successfully offered to the DUT/SUT. 456 Discussion: 457 While it is important to understand how quickly a system can 458 process multicast frames; it may be beneficial to understand 459 how quickly that same system can stop the process as well. 461 Because of the number of variables that could impact this metric, 462 the metric may be a better characterization tool for a device or 463 system rather than a basis for comparisons with other devices. 465 Measurement units: 466 Microseconds. 468 Issues: Methodology may need to consider protocol-specific timeout 469 values. 471 Issues: 473 While this metric attempts to identify a simple delay, the 474 underlying and contributing delay components (e.g., propagation 475 delay, frame processing delay, etc.) make this a less than simple 476 measurement. Moreover, the cessation of traffic is a rather 477 unobservable event (i.e., at what point is the multicast forwarded 478 considered stopped on the DUT interface processing the Leave?). 479 The corresponding methodology will need to consider this and 480 similar factors to ensure a consistent and precise metric result. 482 The Methodology may also need to consider protocol-specific timeout 483 values as well. 485 3.5 Capacity 487 This section offers terms relating to the identification of multicast 488 group limits of a DUT/SUT. 490 3.5.1 Multicast Group Capacity. 492 Definition: 493 The maximum number of multicast groups a SUT/DUT can support 494 while maintaining the ability to forward multicast frames 495 to all multicast groups registered to that SUT/DUT. 497 Discussion: 499 Measurement units: 500 Multicast groups. 502 Issues: 503 The related methodology may have to consider the impact of 504 multicast sources per group on the ability of a SUT/DUT to 505 "scale up" the number of supportable multicast groups. 507 3.6 Interaction 509 Network forwarding devices are generally required to provide more 510 functionality than than the forwarding of traffic. Moreover, network 511 forwarding devices may be asked to provide those functions in a 512 variety of environments. This section offers terms to assist in the 513 charaterization of DUT/SUT behavior in consideration of potentially 514 interacting factors. 516 3.6.1 Burdened Response. 518 Definition: 520 A measured response collected from a DUT/SUT in light of 521 interacting, or potentially interacting, distinct stimulii. 523 Discussion: 524 Many metrics provide a one dimensional view into an operating 525 characteristic of a tested system. For example, the forwarding 526 rate metric may yield information about the packet processing 527 ability of a device. Collecting that same metric in view of 528 another control variable can oftentimes be very insightful. Taking 529 that same forwarding rate measurement, for instance, while the 530 device's address table is injected with an additional 50,000 531 entries may yield a different perspective. 533 Measurement units: 534 A burdened response is a type of metric. Metrics of this 535 this type must follow guidelines when reporting results. 537 The metric's principal result MUST be reported in conjunction with 538 the contributing factors. 540 For example, in reporting a Forwarding Burdened Latency, the 541 latency measurement should be reported with respect to 542 corresponding Offered Load and Forwarding Rates. 544 Issues: 545 A Burdened response may be very illuminating when trying to 546 characterize a single device or system. Extreme care must 547 be exercised when attempting to use that characterization as 548 a basis of comparison with other devices or systems. Test agents 549 must ensure that the measured response is a function of the 550 controlled stimulii, and not secondary factors. An example of 551 of such an interfering factor would be configuration mismatch of 552 a timer impacting a response process. 554 3.6.2 Forwarding Burdened Multicast Latency. 556 Definition: 557 A multicast latency taken from a DUT/SUT in the presence of 558 a traffic forwarding requirement. 560 Discussion: 561 This burdened response metric builds on the Multicast Latency 562 definition offered in section 3.3.1. It mandates that the DUT be 563 subjected to an additional measure of traffic not required by the 564 non-burdened metric. 566 This metric attempts to provide a means by which to evaluate 567 how traffic load may or may not impact a device's or system's 568 packet processing delay. 570 Measurement units: 571 Time units with enough precision to reflect the latencies 572 measurements. 574 Latency measurements MUST be reported with the corresponding 575 sustained Forwarding Rate and associated Offered Load. 577 3.6.3 Forwarding Burdened Group Join Delay. 579 Definition: 580 A multicast Group Join Delay taken from a DUT/SUT in the presence 581 of a traffic forwarding requirement. 583 Discussion: 584 This burdened response metric builds on the Group Join Delay 585 definition offered in section 3.4.1. It mandates that the DUT be 586 subjected to an additional measure of traffic not required by the 587 non-burdened metric. 589 Many factors can contribute to different results, such as 590 the number or type of multicast-related protocols configured 591 on the system under test. Other factors could be physical topology 592 or the logical multicast "tree" configuration. 594 Because of the number of variables that could impact this metric, 595 the metric may be a better characterization tool for a device or 596 system rather than a basis for comparisons with other devices. 598 Measurement units: 599 Time units with enough precision to reflect the delay measurements. 601 Delay measurements MUST be reported with the corresponding 602 sustained Forwarding Rate and associated Offered Load. 604 Issues: 605 While this metric attempts to identify a simple delay, the 606 underlying and contributing delay components (e.g., propagation 607 delay, frame processing delay, etc.) make this a less than simple 608 measurement. The corresponding methodology will need to consider 609 this and similar factors to ensure a consistent and precise 610 metric result. 612 4. Security Considerations 613 This document addresses metrics and terminology relating to the 614 performance benchmarking of IP Multicast forwarding devices. 615 The information contained in this document does not impact the 616 security of the Internet. 618 Methodologies regarding the collection of the metrics described 619 within this document may need to cite security considerations. 620 This document does not address methodological issues. 622 5. Acknowledgments 624 The IETF BMWG participants have made several comments and suggestions 625 regarding this work. Particular thanks goes to Harald Alvestrand, 626 Scott Bradner, Brad Cain, Eric Crawley, Bob Mandeville, David Newman, 627 Shuching Sheih, Dave Thaler, Chuck Winter, Zhaohui Zhang, and John 628 Galgay for their insightful review and assistance. 630 6. References 632 [Br91] Bradner, S. Benchmarking Terminology for Network 633 Interconnection Devices. RFC 1242. July, 1991. 635 [Br96] Bradner, S., McQuaid, J. Benchmarking Methodology for Network 636 Interconnect Devices. RFC 1944. May, 1996. 638 [Hu95] Huitema, C. "Routing in the Internet." Prentice-Hall, 1995. 640 [Se98] Semeria, C. and Maufer, T. "Introduction to IP Multicast 641 Routing." http://www.3com.com/nsc/501303.html 3Com Corp., 1998. 643 [Ma98] Mandeville, R. Benchmarking Terminology for LAN Switching 644 Devices. RFC 2285. February, 1998. 646 [Mt98] Maufer, T. "Deploying IP Multicast in the Enterprise." 647 Prentice-Hall, 1998. 649 7. Author's Address 651 Kevin Dubray 652 IronBridge Networks 653 55 Hayden Avenue 654 Lexington, MA 02421 655 USA 656 Phone: 781 402 8018 657 EMail: kdubray@ironbridgenetworks.com