idnits 2.17.1 draft-ietf-bmwg-mcastm-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The total number of multicast groups joined MUST not exceed the multicast group capacity of the DUT/SUT. The Group Capacity (Section 7.1) results MUST be known prior to running this test. -- 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 (January 2004) is 7397 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) == Missing Reference: 'Me89' is mentioned on line 250, but not defined == Missing Reference: 'Du96' is mentioned on line 1195, but not defined == Unused Reference: 'Br97' is defined on line 1341, but no explicit reference was found in the text == Unused Reference: 'Ca02' is defined on line 1355, but no explicit reference was found in the text == Unused Reference: 'De89' is defined on line 1358, but no explicit reference was found in the text == Unused Reference: 'Fe97' is defined on line 1361, but no explicit reference was found in the text == Unused Reference: 'Hu95' is defined on line 1364, but no explicit reference was found in the text == Unused Reference: 'Ka98' is defined on line 1366, but no explicit reference was found in the text == Unused Reference: 'Mt98' is defined on line 1369, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. 'Br91') ** Downref: Normative reference to an Informational RFC: RFC 2544 (ref. 'Br96') ** Downref: Normative reference to an Informational RFC: RFC 2432 (ref. 'Du98') -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA1' ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. 'Ma98') Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Debra Stopp 2 INTERNET-DRAFT Ixia 3 Expires in: February 2004 Brooks Hickman 4 Spirent Communications 5 January 2004 7 Methodology for IP Multicast Benchmarking 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 The purpose of this document is to describe methodology specific to 39 the benchmarking of multicast IP forwarding devices. It builds upon 40 the tenets set forth in RFC 2544, RFC 2432 and other IETF 41 Benchmarking Methodology Working Group (BMWG) efforts. This 42 document seeks to extend these efforts to the multicast paradigm. 44 The BMWG produces two major classes of documents: Benchmarking 45 Terminology documents and Benchmarking Methodology documents. The 46 Terminology documents present the benchmarks and other related 47 terms. The Methodology documents define the procedures required to 48 collect the benchmarks cited in the corresponding Terminology 49 documents. 51 Table of Contents 53 1. INTRODUCTION...................................................3 55 2. KEY WORDS TO REFLECT REQUIREMENTS..............................3 57 3. TEST SET UP....................................................3 58 3.1. Test Considerations..........................................5 59 3.1.1. IGMP Support..............................................6 60 3.1.2. Group Addresses...........................................6 61 3.1.3. Frame Sizes...............................................6 62 3.1.4. TTL.......................................................6 63 3.1.5. Trial Duration............................................6 64 4. FORWARDING AND THROUGHPUT......................................7 65 4.1. Mixed Class Throughput.......................................7 66 4.2. Scaled Group Forwarding Matrix...............................8 67 4.3. Aggregated Multicast Throughput..............................9 68 4.4. Encapsulation/Decapsulation (Tunneling) Throughput..........10 69 4.4.1. Encapsulation Throughput.................................10 70 4.4.2. Decapsulation Throughput.................................12 71 4.4.3. Re-encapsulation Throughput..............................14 72 5. FORWARDING LATENCY............................................16 73 5.1. Multicast Latency...........................................17 74 5.2. Min/Max Multicast Latency...................................19 75 6. OVERHEAD......................................................20 76 6.1. Group Join Delay............................................20 77 6.2. Group Leave Delay...........................................23 78 7. CAPACITY......................................................25 79 7.1. Multicast Group Capacity....................................25 80 8. INTERACTION...................................................26 81 8.1. Forwarding Burdened Multicast Latency.......................26 82 8.2. Forwarding Burdened Group Join Delay........................27 83 9. SECURITY CONSIDERATIONS.......................................28 85 10. ACKNOWLEDGEMENTS.............................................29 87 11. CONTRIBUTIONS................................................29 89 12. REFERENCES...................................................30 91 13. AUTHOR'S ADDRESSES...........................................31 93 14. FULL COPYRIGHT STATEMENT.....................................31 94 1. Introduction 96 This document defines tests for measuring and reporting the 97 throughput, forwarding, latency and IGMP group membership 98 characteristics of devices that support IP multicast protocols. 99 The results of these tests will provide the user with meaningful 100 data on multicast performance. 102 A previous document, " Terminology for IP Multicast Benchmarking" 103 (RFC 2432), defined many of the terms that are used in this 104 document. The terminology document should be consulted before 105 attempting to make use of this document. 107 This methodology will focus on one source to many destinations, 108 although many of the tests described may be extended to use 109 multiple source to multiple destination topologies. 111 2. Key Words to Reflect Requirements 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 114 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 115 in this document are to be interpreted as described in RFC 2119. 116 RFC 2119 defines the use of these key words to help make the intent 117 of standards track documents as clear as possible. While this 118 document uses these keywords, this document is not a standards 119 track document. 121 3. Test set up 123 The set of methodologies presented in this document are for single 124 ingress, multiple egress multicast scenarios as exemplified by 125 Figures 1 and 2. Methodologies for multiple ingress and multiple 126 egress multicast scenarios are beyond the scope of this document. 128 Figure 1 shows a typical setup for an IP multicast test, with one 129 source to multiple destinations. 131 +------------+ +--------------+ 132 | | | destination | 133 +--------+ | Egress(-)------->| test | 134 | source | | | | port(E1) | 135 | test |------>(|)Ingress | +--------------+ 136 | port | | | +--------------+ 137 +--------+ | Egress(-)------->| destination | 138 | | | test | 139 | | | port(E2) | 140 | DUT | +--------------+ 141 | | . . . 142 | | +--------------+ 143 | | | destination | 144 | Egress(-)------->| test | 145 | | | port(En) | 146 +------------+ +--------------+ 148 Figure 1 149 --------- 151 If the multicast metrics are to be taken across multiple devices 152 forming a System Under Test (SUT), then test frames are offered to 153 a single ingress interface on a device of the SUT, subsequently 154 forwarded across the SUT topology, and finally forwarded to the 155 test apparatus' frame-receiving components by the test egress 156 interface(s) of devices in the SUT. Figure 2 offers an example SUT 157 test topology. If a SUT is tested, the test topology and all 158 relevant configuration details MUST be disclosed with the 159 corresponding test results. 161 *-----------------------------------------* 162 | | 163 +--------+ | +----------------+ | +--------+ 164 | | | +------------+ |DUT B Egress E0(-)-|->| | 165 | | | |DUT A |--->| | | | | 166 | source | | | | | Egress E1(-)-|->| dest. | 167 | test |--|->(-)Ingress, I | +----------------+ | | test | 168 | port | | | | +----------------+ | | port | 169 | | | | |--->|DUT C Egress E2(-)-|->| | 170 | | | +------------+ | | | | | 171 | | | | Egress En(-)-|->| | 172 +--------+ | +----------------+ | +--------+ 173 | | 174 *------------------SUT--------------------* 176 Figure 2 177 --------- 179 Generally, the destination test ports first join the desired number 180 of multicast groups by sending IGMP Group Report messages to the 181 DUT/SUT. To verify that all destination test ports successfully 182 joined the appropriate groups, the source test port MUST transmit 183 IP multicast frames destined for these groups. After test 184 completion, the destination test ports MAY send IGMP Leave Group 185 messages to clear the IGMP table of the DUT/SUT. 187 In addition, test equipment MUST validate the correct and proper 188 forwarding actions of the devices they test in order to ensure the 189 receipt of the frames that are involved in the test. 191 3.1. Test Considerations 193 The methodology assumes a uniform medium topology. Issues regarding 194 mixed transmission media, such as speed mismatch, headers 195 differences, etc., are not specifically addressed. Flow control, 196 QoS and other non-essential traffic or traffic-affecting mechanisms 197 affecting the variable under test MUST be disabled. Modifications 198 to the collection procedures might need to be made to accommodate 199 the transmission media actually tested. These accommodations MUST 200 be presented with the test results. 202 An actual flow of test traffic MAY be required to prime related 203 mechanisms, (e.g., process RPF events, build device caches, etc.) 204 to optimally forward subsequent traffic. Therefore, prior to 205 running any tests that require forwarding of multicast or unicast 206 packets, the test apparatus MUST generate test traffic utilizing 207 the same addressing characteristics to the DUT/SUT that will 208 subsequently be used to measure the DUT/SUT response. The test 209 monitor should ensure the correct forwarding of traffic by the 210 DUT/SUT. The priming action need only be repeated to keep the 211 associated information current. 213 It is the intent of this memo to provide the methodology for basic 214 characterizations regarding the forwarding of multicast packets by 215 a device or simple system of devices. These characterizations may 216 be useful in illustrating the impact of device architectural 217 features (e.g., message passing versus shared memory; handling 218 multicast traffic as an exception by the general purpose processor 219 versus the by a primary data path, etc.) in the forwarding of 220 multicast traffic. 222 It has been noted that the formation of the multicast distribution 223 tree may be a significant component of multicast performance. 224 While this component may be present in some of the measurements or 225 scenarios presented in this memo, this memo does not seek to 226 explicitly benchmark the formation of the multicast distribution 227 tree. The benchmarking of the multicast distribution tree 228 formation is left as future, more targeted work specific to a given 229 tree formation vehicle. 231 3.1.1. IGMP Support 233 All of the ingress and egress interfaces MUST support a version of 234 IGMP. The IGMP version on the ingress interface MUST be the same 235 version of IGMP that is being tested on the egress interfaces. 237 Each of the ingress and egress interfaces SHOULD be able to respond 238 to IGMP queries during the test. 240 Each of the ingress and egress interfaces SHOULD also send LEAVE 241 (running IGMP version 2 or later) after each test. 243 3.1.2. Group Addresses 245 There is no restriction to the use of multicast addresses to 246 compose the test traffic other than those assignments imposed by 247 IANA. The IANA assignments for multicast addresses[IANA1] MUST be 248 regarded for operational consistency. Address selection does not 249 need to be restricted to Administratively Scoped IP Multicast 250 addresses[Me89]. 252 3.1.3. Frame Sizes 254 Each test SHOULD be run with different multicast frame sizes. For 255 Ethernet, the recommended sizes are 64, 128, 256, 512, 1024, 1280, 256 and 1518 byte frames. 258 Other link layer technologies MAY be used. The minimum and maximum 259 frame lengths of the link layer technology in use SHOULD be tested. 261 When testing with different frame sizes, the DUT/SUT configuration 262 MUST remain the same. 264 3.1.4. TTL 266 The data plane test traffic should have a TTL value large enough to 267 traverse the DUT/SUT. 269 The TTL in IGMP control plane messages MUST be in compliance with 270 the version of IGMP in use. 272 3.1.5. Trial Duration 274 The duration of the test portion of each trial SHOULD be at least 275 30 seconds. This parameter MUST be included as part of the results 276 reporting for each methodology. 278 4. Forwarding and Throughput 280 This section contains the description of the tests that are related 281 to the characterization of the frame forwarding of a DUT/SUT in a 282 multicast environment. Some metrics extend the concept of throughput 283 presented in RFC 1242. Forwarding Rate is cited in RFC 2285 [Ma98]. 285 4.1. Mixed Class Throughput 287 Objective: 289 To determine the throughput of a DUT/SUT when both unicast class 290 frames and multicast class frames are offered simultaneously to a 291 fixed number of interfaces as defined in RFC 2432. 293 Procedure: 295 Multicast and unicast traffic are mixed together in the same 296 aggregated traffic stream in order to simulate a heterogeneous 297 networking environment. 299 The following events MUST occur before offering test traffic: 301 o All destination test ports configured to receive multicast 302 traffic MUST join all configured multicast groups; 303 o The DUT/SUT MUST learn the appropriate unicast and 304 multicast addresses; and 305 o Group membership and unicast address learning MUST be 306 verified through some externally observable method. 308 The intended load [Ma98] SHOULD be configured as alternating 309 multicast class frames and unicast class frames to a single ingress 310 interface. The unicast class frames MUST be configured to transmit 311 in an unweighted round-robin fashion to all of the destination 312 ports. 314 For example, with six multicast groups and 3 destination ports with 315 one unicast addresses per port, the source test port will offer 316 frames in the following order: 318 m1 u1 m2 u2 m3 u3 m4 u1 m5 u2 m6 u3 m1 ... 320 Where: 322 m = Multicast Frame 323 u = Unicast Frame 325 Mixed class throughput measurement is defined in RFC2432 [Du98]. A 326 search algorithm MUST be utilized to determine the Mixed Class 327 Throughput. The ratio of unicast to multicast frames MUST remain 328 the same when varying the intended load. 330 Reporting Format: 332 The following configuration parameters MUST be reflected in the 333 test report: 335 o Frame size(s) 336 o Number of tested egress interfaces on the DUT/SUT 337 o Test duration 338 o IGMP version 339 o Total number of multicast groups 340 o Traffic distribution for unicast and multicast traffic 341 classes 342 o The ratio of multicast to unicast class traffic 344 The following results MUST be reflected in the test report: 346 o Mixed Class Throughput as defined in RFC2432 [Du98], 347 including: Throughput per unicast and multicast traffic 348 classes. 350 The Mixed Class Throughput results for each test SHOULD be reported 351 in the form of a table with a row for each of the tested frame 352 sizes per the recommendations in section 3.1.3. Each row SHOULD 353 specify the intended load, number of multicast frames offered, 354 number of unicast frames offered and measured throughput per class. 356 4.2. Scaled Group Forwarding Matrix 358 Objective: 360 To determine Forwarding Rate as a function of tested multicast 361 groups for a fixed number of tested DUT/SUT ports. 363 Procedure: 365 This is an iterative procedure. The destination test port(s) MUST 366 join an initial number of multicast groups on the first iteration. 367 All destination test ports configured to receive multicast traffic 368 MUST join all configured multicast groups. The recommended number 369 of groups to join on the first iteration is 10 groups. Multicast 370 traffic is subsequently transmitted to all groups joined on this 371 iteration and the forwarding rate is measured. 373 The number of multicast groups joined by each destination test port 374 is then incremented, or scaled, by an additional number of 375 multicast groups. The recommended granularity of additional groups 376 to join per iteration is 10, although the tester MAY choose a finer 377 granularity. Multicast traffic is subsequently transmitted to all 378 groups joined during this iteration and the forwarding rate is 379 measured. 381 The total number of multicast groups joined MUST not exceed the 382 multicast group capacity of the DUT/SUT. The Group Capacity 383 (Section 7.1) results MUST be known prior to running this test. 385 Reporting Format: 387 The following configuration parameters MUST be reflected in the 388 test report: 390 o Frame size(s) 391 o Number of tested egress interfaces on the DUT/SUT 392 o Test duration 393 o IGMP version 395 The following results MUST be reflected in the test report: 397 o The total number of multicast groups joined for that 398 iteration 399 o Forwarding rate determined for that iteration 401 The Scaled Group Forwarding results for each test SHOULD be 402 reported in the form of a table with a row representing each 403 iteration of the test. Each row or iteration SHOULD specify the 404 total number of groups joined for that iteration, offered load, 405 total number of frames transmitted, total number of frames received 406 and the aggregate forwarding rate determined for that iteration. 408 4.3. Aggregated Multicast Throughput 410 Objective: 412 To determine the maximum rate at which none of the offered frames 413 to be forwarded through N destination interfaces of the same 414 multicast groups are dropped. 416 Procedure: 418 Offer multicast traffic at an initial maximum offered load to a 419 fixed set of interfaces with a fixed number of groups at a fixed 420 frame length for a fixed duration of time. All destination test 421 ports MUST join all specified multicast groups. 423 If any frame loss is detected, the offered load is decreased and 424 the sender will transmit again. An iterative search algorithm MUST 425 be utilized to determine the maximum offered frame rate with a zero 426 frame loss. 428 Each iteration will involve varying the offered load of the 429 multicast traffic, while keeping the set of interfaces, number of 430 multicast groups, frame length and test duration fixed, until the 431 maximum rate at which none of the offered frames are dropped is 432 determined. 434 Parameters to be measured MUST include the maximum offered load at 435 which no frame loss occurred. Other offered loads MAY be measured 436 for diagnostic purposes. 438 Reporting Format: 440 The following configuration parameters MUST be reflected in the 441 test report: 443 o Frame size(s) 444 o Number of tested egress interfaces on the DUT/SUT 445 o Test duration 446 o IGMP version 447 o Total number of multicast groups 449 The following results MUST be reflected in the test report: 451 o Aggregated Multicast Throughput as defined in RFC2432 452 [Du98] 454 The Aggregated Multicast Throughput results SHOULD be reported in 455 the format of a table with a row for each of the tested frame sizes 456 per the recommendations in section 3.1.3. Each row or iteration 457 SHOULD specify offered load, total number of offered frames and the 458 measured Aggregated Multicast Throughput. 460 4.4. Encapsulation/Decapsulation (Tunneling) Throughput 462 This sub-section provides the description of tests related to the 463 determination of throughput measurements when a DUT/SUT or a set of 464 DUTs are acting as tunnel endpoints. 466 For this specific testing scenario, encapsulation or tunneling 467 refers to a packet that contains an unsupported protocol feature in 468 a format that is supported by the DUT/SUT. 470 4.4.1. Encapsulation Throughput 472 Objective: 474 To determine the maximum rate at which frames offered to one 475 ingress interface of a DUT/SUT are encapsulated and correctly 476 forwarded on one or more egress interfaces of the DUT/SUT without 477 loss. 479 Procedure: 481 Source DUT/SUT Destination 482 Test Port Test Port(s) 483 +---------+ +-----------+ +---------+ 484 | | | | | | 485 | | | Egress|--(Tunnel)-->| | 486 | | | | | | 487 | |------->|Ingress | | | 488 | | | | | | 489 | | | Egress|--(Tunnel)-->| | 490 | | | | | | 491 +---------+ +-----------+ +---------+ 493 Figure 3 494 --------- 496 Figure 3 shows the setup for testing the encapsulation throughput 497 of the DUT/SUT. One or more tunnels are created between each 498 egress interface of the DUT/SUT and a destination test port. Non- 499 Encapsulated multicast traffic will then be offered by the source 500 test port, encapsulated by the DUT/SUT and forwarded to the 501 destination test port(s). 503 The DUT/SUT SHOULD be configured such that the traffic across each 504 egress interface will consist of either: 506 a) A single tunnel encapsulating one or more multicast address 507 groups OR 508 b) Multiple tunnels, each encapsulating one or more multicast 509 address groups. 511 The number of multicast groups per tunnel MUST be the same when the 512 DUT/SUT is configured in a multiple tunnel configuration. In 513 addition, it is RECOMMENDED to test with the same number of tunnels 514 on each egress interface. All destination test ports MUST join all 515 multicast group addresses offered by the source test port. Each 516 egress interface MUST be configured with the same MTU. 518 Note: when offering large frames sizes, the encapsulation process 519 may require the DUT/SUT to fragment the IP datagrams prior to being 520 forwarded on the egress interface. It is RECOMMENDED to limit the 521 offered frame size such that no fragmentation is required by the 522 DUT/SUT. 524 A search algorithm MUST be utilized to determine the encapsulation 525 throughput as defined in [Du98]. 527 Reporting Format: 529 The following configuration parameters MUST be reflected in the 530 test report: 532 o Number of tested egress interfaces on the DUT/SUT 533 o Test duration 534 o IGMP version 535 o Total number of multicast groups 536 o MTU size of DUT/SUT interfaces 537 o Originating un-encapsulated frame size 538 o Number of tunnels per egress interface 539 o Number of multicast groups per tunnel 540 o Encapsulation algorithm or format used to tunnel the 541 packets 543 The following results MUST be reflected in the test report: 545 o Measured Encapsulated Throughput as defined in RFC2432 546 [Du98] 547 o Encapsulated frame size 549 The Encapsulated Throughput results SHOULD be reported in the form 550 of a table and specific to this test there SHOULD be rows for each 551 originating un-encapsulated frame size. Each row or iteration 552 SHOULD specify the offered load, encapsulation method, encapsulated 553 frame size, total number of offered frames, and the encapsulation 554 throughput. 556 4.4.2. Decapsulation Throughput 558 Objective: 560 To determine the maximum rate at which frames offered to one 561 ingress interface of a DUT/SUT are decapsulated and correctly 562 forwarded by the DUT/SUT on one or more egress interfaces without 563 loss. 565 Procedure: 567 Source DUT/SUT Destination 568 Test Port Test Port(s) 569 +---------+ +-----------+ +---------+ 570 | | | | | | 571 | | | Egress|------->| | 572 | | | | | | 573 | |--(Tunnel)-->|Ingress | | | 574 | | | | | | 575 | | | Egress|------->| | 576 | | | | | | 577 +---------+ +-----------+ +---------+ 579 Figure 4 580 --------- 582 Figure 4 shows the setup for testing the decapsulation throughput 583 of the DUT/SUT. One or more tunnels are created between the source 584 test port and the DUT/SUT. Encapsulated multicast traffic will 585 then be offered by the source test port, decapsulated by the 586 DUT/SUT and forwarded to the destination test port(s). 588 The DUT/SUT SHOULD be configured such that the traffic across the 589 ingress interface will consist of either: 591 a) A single tunnel encapsulating one or more multicast address 592 groups OR 593 b) Multiple tunnels, each encapsulating one or more multicast 594 address groups. 596 The number of multicast groups per tunnel MUST be the same when the 597 DUT/SUT is configured in a multiple tunnel configuration. All 598 destination test ports MUST join all multicast group addresses 599 offered by the source test port. Each egress interface MUST 600 be configured with the same MTU. 602 A search algorithm MUST be utilized to determine the decapsulation 603 throughput as defined in [Du98]. 605 When making performance comparisons between the encapsulation and 606 decapsulation process of the DUT/SUT, the offered frame sizes 607 SHOULD reflect the encapsulated frame sizes reported in the 608 encapsulation test (See section 4.4.1) in place of those noted in 609 section 3.1.3. 611 Reporting Format: 613 The following configuration parameters MUST be reflected in the 614 test report: 616 o Number of tested egress interfaces on the DUT/SUT 617 o Test duration 618 o IGMP version 619 o Total number of multicast groups 620 o Originating encapsulation algorithm or format used to 621 tunnel the packets 622 o Originating encapsulated frame size 623 o Number of tunnels 624 o Number of multicast groups per tunnel 626 The following results MUST be reflected in the test report: 628 o Measured Decapsulated Throughput as defined in RFC2432 629 [Du98] 630 o Decapsulated frame size 632 The Decapsulated Throughput results SHOULD be reported in the 633 format of a table and specific to this test there SHOULD be rows 634 for each originating encapsulated frame size. Each row or 635 iteration SHOULD specify the offered load, decapsulated frame size, 636 total number of offered frames and the decapsulation throughput. 638 4.4.3. Re-encapsulation Throughput 640 Objective: 642 To determine the maximum rate at which frames of one encapsulated 643 format offered to one ingress interface of a DUT/SUT are converted 644 to another encapsulated format and correctly forwarded by the 645 DUT/SUT on one or more egress interfaces without loss. 647 Procedure: 649 Source DUT/SUT Destination 650 Test Port Test Port(s) 651 +---------+ +---------+ +---------+ 652 | | | | | | 653 | | | Egress|-(Tunnel)->| | 654 | | | | | | 655 | |-(Tunnel)->|Ingress | | | 656 | | | | | | 657 | | | Egress|-(Tunnel)->| | 658 | | | | | | 659 +---------+ +---------+ +---------+ 661 Figure 5 662 --------- 664 Figure 5 shows the setup for testing the Re-encapsulation 665 throughput of the DUT/SUT. The source test port will offer 666 encapsulated traffic of one type to the DUT/SUT, which has been 667 configured to re-encapsulate the offered frames using a different 668 encapsulation format. The DUT/SUT will then forward the re- 669 encapsulated frames to the destination test port(s). 671 The DUT/SUT SHOULD be configured such that the traffic across the 672 ingress and each egress interface will consist of either: 674 a) A single tunnel encapsulating one or more multicast address 675 groups OR 676 b) Multiple tunnels, each encapsulating one or more multicast 677 address groups. 679 The number of multicast groups per tunnel MUST be the same when the 680 DUT/SUT is configured in a multiple tunnel configuration. In 681 addition, the DUT/SUT SHOULD be configured such that the number of 682 tunnels on the ingress and each egress interface are the same. All 683 destination test ports MUST join all multicast group addresses 684 offered by the source test port. Each egress interface MUST be 685 configured with the same MTU. 687 Note that when offering large frames sizes, the encapsulation 688 process may require the DUT/SUT to fragment the IP datagrams prior 689 to being forwarded on the egress interface. It is RECOMMENDED to 690 limit the offered frame sizes, such that no fragmentation is 691 required by the DUT/SUT. 693 A search algorithm MUST be utilized to determine the re- 694 encapsulation throughput as defined in [Du98]. 696 Reporting Format: 698 The following configuration parameters MUST be reflected in the 699 test report: 701 o Number of tested egress interfaces on the DUT/SUT 702 o Test duration 703 o IGMP version 704 o Total number of multicast groups 705 o MTU size of DUT/SUT interfaces 706 o Originating encapsulation algorithm or format used to 707 tunnel the packets 708 o Re-encapsulation algorithm or format used to tunnel the 709 packets 710 o Originating encapsulated frame size 711 o Number of tunnels per interface 712 o Number of multicast groups per tunnel 714 The following results MUST be reflected in the test report: 716 o Measured Re-encapsulated Throughput as defined in RFC2432 717 [Du98] 718 o Re-encapsulated frame size 720 The Re-encapsulated Throughput results SHOULD be reported in the 721 format of a table and specific to this test there SHOULD be rows 722 for each originating encapsulated frame size. Each row or 723 iteration SHOULD specify the offered load, decapsulated frame size, 724 total number of offered frames and the Re-encapsulated Throughput. 726 5. Forwarding Latency 728 This section presents methodologies relating to the 729 characterization of the forwarding latency of a DUT/SUT in a 730 multicast environment. It extends the concept of latency 731 characterization presented in RFC 2544. 733 The offered load accompanying the latency-measured packet can 734 affect the DUT/SUT packet buffering, which may subsequently impact 735 measured packet latency. This SHOULD be a consideration when 736 selecting the intended load for the described methodologies below. 738 RFC 1242 and RFC 2544 draw a distinction between device types: 739 "store and forward" and "bit-forwarding." Each type impacts how 740 latency is collected and subsequently presented. See the related 741 RFCs for more information. 743 5.1. Multicast Latency 745 Objective: 747 To produce a set of multicast latency measurements from a single, 748 multicast ingress interface of a DUT/SUT through multiple, egress 749 multicast interfaces of that same DUT/SUT as provided for by the 750 metric "Multicast Latency" in RFC 2432 [Du98]. 752 The procedures below draw from the collection methodology for 753 latency in RFC 2544 [Br96]. The methodology addresses two 754 topological scenarios: one for a single device (DUT) 755 characterization; a second scenario is presented or multiple device 756 (SUT) characterization. 758 Procedure: 760 If the test trial is to characterize latency across a single Device 761 Under Test (DUT), an example test topology might take the form of 762 Figure 1 in section 3. That is, a single DUT with one ingress 763 interface receiving the multicast test traffic from frame- 764 transmitting component of the test apparatus and n egress 765 interfaces on the same DUT forwarding the multicast test traffic 766 back to the frame-receiving component of the test apparatus. Note 767 that n reflects the number of TESTED egress interfaces on the DUT 768 actually expected to forward the test traffic (as opposed to 769 configured but untested, non-forwarding interfaces, for example). 771 If the multicast latencies are to be taken across multiple devices 772 forming a System Under Test (SUT), an example test topology might 773 take the form of Figure 2 in section 3. 775 The trial duration SHOULD be 120 seconds to be consistent with RFC 776 2544 [Br96]. The nature of the latency measurement, "store and 777 forward" or "bit forwarding," MUST be associated with the related 778 test trial(s) and disclosed in the results report. 780 A test traffic stream is presented to the DUT. It is RECOMMENDED to 781 offer traffic at the measured aggregated multicast throughput rate 782 (Section 4.3). At the mid-point of the trial's duration, the test 783 apparatus MUST inject a uniquely identifiable ("tagged") frame into 784 the test traffic frames being presented. This tagged frame will be 785 the basis for the latency measurements. By "uniquely identifiable," 786 it is meant that the test apparatus MUST be able to discern the 787 "tagged" frame from the other frames comprising the test traffic 788 set. A frame generation timestamp, Timestamp A, reflecting the 789 completion of the transmission of the tagged frame by the test 790 apparatus, MUST be determined. 792 The test apparatus will monitor frames from the DUT's tested egress 793 interface(s) for the expected tagged frame(s) and MUST record the 794 time of the successful detection of a tagged frame from a tested 795 egress interface with a timestamp, Timestamp B. A set of Timestamp 796 B values MUST be collected for all tested egress interfaces of the 797 DUT/SUT. See RFC 1242 [Br91] for additional discussion regarding 798 store and forward devices and bit forwarding devices. 800 A trial MUST be considered INVALID should any of the following 801 conditions occur in the collection of the trial data: 803 o Unexpected differences between Intended Load and Offered 804 Load or unexpected differences between Offered Load and the 805 resulting Forwarding Rate(s) on the DUT/SUT egress ports. 806 o Forwarded test frames improperly formed or frame header 807 fields improperly manipulated. 808 o Failure to forward required tagged frame(s) on all expected 809 egress interfaces. 810 o Reception of tagged frames by the test apparatus more than 811 5 seconds after the cessation of test traffic by the source 812 test port. 814 The set of latency measurements, M, composed from each latency 815 measurement taken from every ingress/tested egress interface 816 pairing MUST be determined from a valid test trial: 818 M = { (Timestamp B(E0) - Timestamp A), 819 (Timestamp B(E1) - Timestamp A), ... 820 (Timestamp B(En) - Timestamp A) } 822 where (E0 ... En) represents the range of all tested egress 823 interfaces and Timestamp B represents a tagged frame detection 824 event for a given DUT/SUT tested egress interface. 826 A more continuous profile MAY be built from a series of individual 827 measurements. 829 Reporting Format: 831 The following configuration parameters MUST be reflected in the 832 test report: 834 o Frame size(s) 835 o Number of tested egress interfaces on the DUT/SUT 836 o Test duration 837 o IGMP version 838 o Offered load 839 o Total number of multicast groups 841 The following results MUST be reflected in the test report: 843 o The set of all latencies with respective time units related 844 to the tested ingress and each tested egress DUT/SUT 845 interface. 847 The time units of the presented latency MUST be uniform and with 848 sufficient precision for the medium or media being tested. 850 The results MAY be offered in a tabular format and should preserve 851 the relationship of latency to ingress/egress interface for each 852 multicast group to assist in trending across multiple trials. 854 5.2. Min/Max Multicast Latency 856 Objective: 858 To determine the difference between the maximum latency measurement 859 and the minimum latency measurement from a collected set of 860 latencies produced by the Multicast Latency benchmark. 862 Procedure: 864 Collect a set of multicast latency measurements over a single test 865 duration, as prescribed in section 5.1. This will produce a set of 866 multicast latencies, M, where M is composed of individual 867 forwarding latencies between DUT frame ingress and DUT frame egress 868 port pairs. E.g.: 870 M = {L(I,E1),L(I,E2), ..., L(I,En)} 872 where L is the latency between a tested ingress interface, I, of 873 the DUT, and Ex a specific, tested multicast egress interface of 874 the DUT. E1 through En are unique egress interfaces on the DUT. 876 From the collected multicast latency measurements in set M, 877 identify MAX(M), where MAX is a function that yields the largest 878 latency value from set M. 880 Identify MIN(M), when MIN is a function that yields the smallest 881 latency value from set M. 883 The Max/Min value is determined from the following formula: 885 Result = MAX(M) - MIN(M) 887 Reporting Format: 889 The following configuration parameters MUST be reflected in the 890 test report: 892 o Frame size(s) 893 o Number of tested egress interfaces on the DUT/SUT 894 o Test duration 895 o IGMP version 896 o Offered load 897 o Total number of multicast groups 899 The following results MUST be reflected in the test report: 901 o The Max/Min value 903 The following results SHOULD be reflected in the test report: 905 o The set of all latencies with respective time units related 906 to the tested ingress and each tested egress DUT/SUT 907 interface. 909 The time units of the presented latency MUST be uniform and with 910 sufficient precision for the medium or media being tested. 912 The results MAY be offered in a tabular format and should preserve 913 the relationship of latency to ingress/egress interface for each 914 multicast group. 916 6. Overhead 918 This section presents methodology relating to the characterization 919 of the overhead delays associated with explicit operations found in 920 multicast environments. 922 6.1. Group Join Delay 924 Objective: 926 To determine the time duration it takes a DUT/SUT to start 927 forwarding multicast frames from the time a successful IGMP group 928 membership report has been issued to the DUT/SUT. 930 Procedure: 932 The Multicast Group Join Delay measurement may be influenced by the 933 state of the Multicast Forwarding Database of the DUT/SUT. 934 The states of the MFDB may be described as follows: 936 . State 0, where the MFDB does not contain the specified 937 multicast group address. In this state, the delay measurement 938 includes the time the DUT/SUT requires to add the address to 939 the MFDB and begin forwarding. Delay measured from State 0 940 provides information about how the DUT/SUT is able to add new 941 addresses into MFDB. 943 . State 1, where the MFDB does contain the specified multicast 944 group address. In this state, the delay measurement includes 945 the time the DUT/SUT requires to update the MFDB with the 946 newly joined node and begin forwarding to the new node 947 plus packet replication time. Delay measured from State 1 948 provides information about how well the DUT/SUT is able to 949 update the MFDB for new nodes while transmitting packets to 950 other nodes for the same IP multicast address. Examples 951 include adding a new user to an event that is being promoted 952 via multicast packets. 954 The methodology for the Multicast Group Join Delay measurement 955 provides two alternate methods, based on the state of the MFDB, to 956 measure the delay metric. The methods MAY be used independently or 957 in conjunction to provide meaningful insight into the DUT/SUT 958 ability to manage the MFDB. 960 Users MAY elect to use either method to determine the Multicast 961 Group Join Delay; however the collection method MUST be specified 962 as part of the reporting format. 964 In order to minimize the variation in delay calculations as well as 965 minimize burden on the DUT/SUT, the test SHOULD be performed with 966 one multicast group. In addition, all destination test ports MUST 967 join the specified multicast group offered to the ingress interface 968 of the DUT/SUT. 970 Method A: 972 Method A assumes that the Multicast Forwarding Database of 973 the DUT/SUT does not contain or has not learned the specified 974 multicast group address; specifically, the MFDB MUST be in State 0. 975 In this scenario, the metric represents the time the DUT/SUT takes 976 to add the multicast address to the MFDB and begin forwarding the 977 multicast packet. Only one ingress and one egress MUST be used to 978 determine this metric. 980 Prior to sending any IGMP Group Membership Reports used to 981 calculate the Multicast Group Join Delay, it MUST be verified 982 through externally observable means that the destination test port 983 is not currently a member of the specified multicast group. In 984 addition, it MUST be verified through externally observable means 985 that the MFDB of the DUT/SUT does not contain the specified 986 multicast address. 988 Method B: 990 Method B assumes that the MFDB of the DUT/SUT does contain the 991 specified multicast group address; specifically, the MFDB MUST be 992 in State 1. In this scenario, the metric represents the time the 993 DUT/SUT takes to update the MFDB with the additional nodes and 994 their corresponding interfaces and to begin forwarding the 995 multicast packet. One or more egress ports MAY be used to 996 determine this metric. 998 Prior to sending any IGMP Group Membership Reports used to 999 calculate the Group Join Delay, it MUST be verified through 1000 externally observable means that the MFDB contains the specified 1001 multicast group address. A single un-instrumented test port MUST 1002 be used to join the specified multicast group address prior to 1003 sending any test traffic. This port will be used only for insuring 1004 that the MFDB has been populated with the specified multicast group 1005 address and can successfully forward traffic to the un-instrumented 1006 port. 1008 Join Delay Calculation 1010 Once verification is complete, multicast traffic for the specified 1011 multicast group address MUST be offered to the ingress interface 1012 prior to the DUT/SUT receiving any IGMP Group Membership Report 1013 messages. It is RECOMMENDED to offer traffic at the measured 1014 aggregated multicast throughput rate (Section 4.3). 1016 After the multicast traffic has been started, the destination test 1017 port (See Figure 1) MUST send one IGMP Group Membership Report for 1018 the specified multicast group. 1020 The join delay is the difference in time from when the IGMP Group 1021 Membership message is sent (timestamp A) and the first frame of the 1022 multicast group is forwarded to a receiving egress interface 1023 (timestamp B). 1025 Group Join delay time = timestamp B - timestamp A 1027 Timestamp A MUST be the time the last bit of the IGMP group 1028 membership report is sent from the destination test port; timestamp 1029 B MUST be the time the first bit of the first valid multicast frame 1030 is forwarded on the egress interface of the DUT/SUT. 1032 Reporting Format: 1034 The following configuration parameters MUST be reflected in the 1035 test report: 1037 o Frame size(s) 1038 o Number of tested egress interfaces on the DUT/SUT 1039 o IGMP version 1040 o Total number of multicast groups 1041 o Offered load to ingress interface 1042 o Method used to measure the join delay metric 1044 The following results MUST be reflected in the test report: 1046 o The group join delay time in microseconds per egress 1047 interface(s) 1049 The Group Join Delay results for each test MAY be reported in the 1050 form of a table, with a row for each of the tested frame sizes per 1051 the recommendations in section 3.1.3. Each row or iteration MAY 1052 specify the group join delay time per egress interface for that 1053 iteration. 1055 6.2. Group Leave Delay 1057 Objective: 1059 To determine the time duration it takes a DUT/SUT to cease 1060 forwarding multicast frames after a corresponding IGMP Leave Group 1061 message has been successfully offered to the DUT/SUT. 1063 Procedure: 1065 In order to minimize the variation in delay calculations as well as 1066 minimize burden on the DUT/SUT, the test SHOULD be performed with 1067 one multicast group. In addition, all destination test ports MUST 1068 join the specified multicast group offered to the ingress interface 1069 of the DUT/SUT. 1071 Prior to sending any IGMP Leave Group messages used to calculate 1072 the group leave delay, it MUST be verified through externally 1073 observable means that the destination test ports are currently 1074 members of the specified multicast group. If any of the egress 1075 interfaces do not forward validation multicast frames then the test 1076 is invalid. 1078 Once verification is complete, multicast traffic for the specified 1079 multicast group address MUST be offered to the ingress interface 1080 prior to receipt or processing of any IGMP Leave Group messages. 1082 It is RECOMMENDED to offer traffic at the measured aggregated 1083 multicast throughput rate (Section 4.3). 1085 After the multicast traffic has been started, each destination test 1086 port (See Figure 1) MUST send one IGMP Leave Group message for the 1087 specified multicast group. 1089 The leave delay is the difference in time from when the IGMP Leave 1090 Group message is sent (timestamp A) and the last frame of the 1091 multicast group is forwarded to a receiving egress interface 1092 (timestamp B). 1094 Group Leave delay time = timestamp B - timestamp A 1096 Timestamp A MUST be the time the last bit of the IGMP Leave Group 1097 message is sent from the destination test port; timestamp B MUST be 1098 the time the last bit of the last valid multicast frame is 1099 forwarded on the egress interface of the DUT/SUT. 1101 Reporting Format: 1103 The following configuration parameters MUST be reflected in the 1104 test report: 1106 o Frame size(s) 1107 o Number of tested egress interfaces on the DUT/SUT 1108 o IGMP version 1109 o Total number of multicast groups 1110 o Offered load to ingress interface 1112 The following results MUST be reflected in the test report: 1114 o The group leave delay time in microseconds per egress 1115 interface(s) 1117 The Group Leave Delay results for each test MAY be reported in the 1118 form of a table, with a row for each of the tested frame sizes per 1119 the recommendations in section 3.1.3. Each row or iteration MAY 1120 specify the group leave delay time per egress interface for that 1121 iteration. 1123 7. Capacity 1125 This section offers a procedure relating to the identification of 1126 multicast group limits of a DUT/SUT. 1128 7.1. Multicast Group Capacity 1130 Objective: 1132 To determine the maximum number of multicast groups a DUT/SUT can 1133 support while maintaining the ability to forward multicast frames 1134 to all multicast groups registered to that DUT/SUT. 1136 Procedure: 1138 One or more destination test ports of DUT/SUT will join an initial 1139 number of multicast groups. 1141 After a minimum delay as measured by section 6.1, the source test 1142 ports MUST transmit to each group at a specified offered load. 1144 If at least one frame for each multicast group is forwarded 1145 properly by the DUT/SUT on each participating egress interface, the 1146 iteration is said to pass at the current capacity. 1148 For each successful iteration, each destination test port will join 1149 an additional user-defined number of multicast groups and the test 1150 repeats. The test stops iterating when one or more of the egress 1151 interfaces fails to forward traffic on one or more of the 1152 configured multicast groups. 1154 Once the iteration fails, the last successful iteration is the 1155 stated Maximum Group Capacity result. 1157 Reporting Format: 1159 The following configuration parameters MUST be reflected in the 1160 test report: 1162 o Frame size(s) 1163 o Number of tested egress interfaces on the DUT/SUT 1164 o IGMP version 1165 o Offered load 1167 The following results MUST be reflected in the test report: 1169 o The total number of multicast group addresses that were 1170 successfully forwarded through the DUT/SUT 1172 The Multicast Group Capacity results for each test SHOULD be 1173 reported in the form of a table, with a row for each of the tested 1174 frame sizes per the recommendations in section 3.1.3. Each row or 1175 iteration SHOULD specify the number of multicast groups joined per 1176 destination interface, number of frames transmitted and number of 1177 frames received for that iteration. 1179 8. Interaction 1181 Network forwarding devices are generally required to provide more 1182 functionality than just the forwarding of traffic. Moreover, 1183 network-forwarding devices may be asked to provide those functions 1184 in a variety of environments. This section offers procedures to 1185 assist in the characterization of DUT/SUT behavior in consideration 1186 of potentially interacting factors. 1188 8.1. Forwarding Burdened Multicast Latency 1190 Objective: 1192 To produce a set of multicast latency measurements from a single 1193 multicast ingress interface of a DUT/SUT through multiple egress 1194 multicast interfaces of that same DUT/SUT as provided for by the 1195 metric "Multicast Latency" in RFC 2432 [Du96] while forwarding 1196 meshed unicast traffic. 1198 Procedure: 1200 The Multicast Latency metrics can be influenced by forcing the 1201 DUT/SUT to perform extra processing of packets while multicast 1202 class traffic is being forwarded for latency measurements. 1204 The Burdened Forwarding Multicast Latency test MUST follow the 1205 described setup for the Multicast Latency test in Section 5.1. In 1206 addition, another set of test ports MUST be used to burden the 1207 DUT/SUT (burdening ports). The burdening ports will be used to 1208 transmit unicast class traffic to the DUT/SUT in a fully meshed 1209 traffic distribution as described in RFC 2285 [Ma98]. The DUT/SUT 1210 MUST learn the appropriate unicast addresses and verified through 1211 some externally observable method. 1213 Perform a baseline measurement of Multicast Latency as described in 1214 Section 5.1. After the baseline measurement is obtained, start 1215 transmitting the unicast class traffic at a user-specified offered 1216 load on the set of burdening ports and rerun the Multicast Latency 1217 test. The offered load to the ingress port MUST be the same as was 1218 used in the baseline measurement. 1220 Reporting Format: 1222 Similar to Section 5.1, the following configuration parameters MUST 1223 be reflected in the test report: 1225 o Frame size(s) 1226 o Number of tested egress interfaces on the DUT/SUT 1227 o Test duration 1228 o IGMP version 1229 o Offered load to ingress interface 1230 o Total number of multicast groups 1231 o Offered load to burdening ports 1232 o Total number of burdening ports 1234 The following results MUST be reflected in the test report: 1236 o The set of all latencies related to the tested ingress and 1237 each tested egress DUT/SUT interface for both the baseline 1238 and burdened response. 1240 The time units of the presented latency MUST be uniform and with 1241 sufficient precision for the medium or media being tested. 1243 The latency results for each test SHOULD be reported in the form of 1244 a table, with a row for each of the tested frame sizes per the 1245 recommended frame sizes in section 3.1.3, and SHOULD preserve the 1246 relationship of latency to ingress/egress interface(s) to assist in 1247 trending across multiple trials. 1249 8.2. Forwarding Burdened Group Join Delay 1251 Objective: 1253 To determine the time duration it takes a DUT/SUT to start 1254 forwarding multicast frames from the time a successful IGMP Group 1255 Membership Report has been issued to the DUT/SUT while forwarding 1256 meshed unicast traffic. 1258 Procedure: 1260 The Forwarding Burdened Group Join Delay test MUST follow the 1261 described setup for the Group Join Delay test in Section 6.1. In 1262 addition, another set of test ports MUST be used to burden the 1263 DUT/SUT (burdening ports). The burdening ports will be used to 1264 transmit unicast class traffic to the DUT/SUT in a fully meshed 1265 traffic pattern as described in RFC 2285 [Ma98]. The DUT/SUT MUST 1266 learn the appropriate unicast addresses and verified through some 1267 externally observable method. 1269 Perform a baseline measurement of Group Join Delay as described in 1270 Section 6.1. After the baseline measurement is obtained, start 1271 transmitting the unicast class traffic at a user-specified offered 1272 load on the set of burdening ports and rerun the Group Join Delay 1273 test. The offered load to the ingress port MUST be the same as was 1274 used in the baseline measurement. 1276 Reporting Format: 1278 Similar to Section 6.1, the following configuration parameters MUST 1279 be reflected in the test report: 1281 o Frame size(s) 1282 o Number of tested egress interfaces on the DUT/SUT 1283 o IGMP version 1284 o Offered load to ingress interface 1285 o Total number of multicast groups 1286 o Offered load to burdening ports 1287 o Total number of burdening ports 1288 o Method used to measure the join delay metric 1290 The following results MUST be reflected in the test report: 1292 o The group join delay time in microseconds per egress 1293 interface(s) for both the baseline and burdened response. 1295 The Group Join Delay results for each test MAY be reported in the 1296 form of a table, with a row for each of the tested frame sizes per 1297 the recommendations in section 3.1.3. Each row or iteration MAY 1298 specify the group join delay time per egress interface, number of 1299 frames transmitted and number of frames received for that 1300 iteration. 1302 9. Security Considerations 1304 As this document is solely for the purpose of providing metric 1305 methodology and describes neither a protocol nor a protocol's 1306 implementation, there are no security considerations associated 1307 with this document specifically. Results from these methodologies 1308 may identify a performance capability or limit of a device or 1309 system in a particular test context. However, such results might 1310 not be representative of the tested entity in an operational 1311 network. 1313 10. Acknowledgements 1315 The Benchmarking Methodology Working Group of the IETF and 1316 particularly Kevin Dubray, Juniper Networks, are to be thanked for 1317 the many suggestions they collectively made to help complete this 1318 document. 1320 11. Contributions 1322 The authors would like to acknowledge the following individuals for 1323 their help and participation of the compilation of this document: 1324 Hardev Soor, Ixia, and Ralph Daniels, Spirent Communications, both 1325 who made significant contributions to the earlier versions of this 1326 document. In addition, the authors would like to acknowledge the 1327 members of the task team who helped bring this document to 1328 fruition: Michele Bustos, Tony De La Rosa, David Newman and Jerry 1329 Perser. 1331 12. References 1333 Normative References 1335 [Br91] Bradner, S., "Benchmarking Terminology for Network 1336 Interconnection Devices", RFC 1242, July 1991. 1338 [Br96] Bradner, S., and J. McQuaid, "Benchmarking Methodology for 1339 Network Interconnect Devices", RFC 2544, March 1999. 1341 [Br97] Bradner, S. "Use of Keywords in RFCs to Reflect Requirement 1342 Levels, RFC 2119, March 1997 1344 [Du98] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC 1345 2432, October 1998. 1347 [IANA1] IANA multicast address assignments, 1348 http://www.iana.org/assignments/multicast-addresses 1350 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching 1351 Devices", RFC 2285, February 1998. 1353 Informative References 1355 [Ca02] Cain, B., et al., "Internet Group Management Protocol, Version 1356 3", RFC 3376, October 2002. 1358 [De89] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1359 1112, August 1989. 1361 [Fe97] Fenner, W., "Internet Group Management Protocol, Version 2", 1362 RFC 2236, November 1997. 1364 [Hu95] Huitema, C. "Routing in the Internet." Prentice-Hall, 1995. 1366 [Ka98] Kosiur, D., "IP Multicasting: the Complete Guide to 1367 Interactive Corporate Networks", John Wiley & Sons, Inc, 1998. 1369 [Mt98] Maufer, T. "Deploying IP Multicast in the Enterprise." 1370 Prentice-Hall, 1998. 1372 13. Author's Addresses 1374 Debra Stopp 1375 Ixia 1376 26601 W. Agoura Rd. 1377 Calabasas, CA 91302 1378 USA 1380 Phone: + 1 818 871 1800 1381 EMail: debby@ixiacom.com 1383 Brooks Hickman 1384 Spirent Communications 1385 26750 Agoura Rd. 1386 Calabasas, CA 91302 1387 USA 1389 Phone: + 1 818 676 2412 1390 EMail: brooks.hickman@spirentcom.com 1392 14. Full Copyright Statement 1394 "Copyright (C) The Internet Society (2004). All Rights Reserved. 1395 This document and translations of it may be copied and furnished to 1396 others, and derivative works that comment on or otherwise explain 1397 it or assist in its implementation may be prepared, copied, 1398 published and distributed, in whole or in part, without restriction 1399 of any kind, provided that the above copyright notice and this 1400 paragraph are included on all such copies and derivative works. 1401 However, this document itself may not be modified in any way, such 1402 as by removing the copyright notice or references to the Internet 1403 Society or other Internet organizations, except as needed for the 1404 purpose of developing Internet standards in which case the 1405 procedures for copyrights defined in the Internet Standards process 1406 must be followed, or as required to translate it into.�