idnits 2.17.1 draft-ietf-bmwg-mcastm-04.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 6) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages 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. == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '...d is in full ...' == Line 18 has weird spacing: '...), its areas...' == Line 19 has weird spacing: '...ups may also ...' == Line 23 has weird spacing: '... and may be ...' == Line 24 has weird spacing: '...opriate to u...' == (17 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2000) is 8684 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 677, but no explicit reference was found in the text == Unused Reference: 'Br96' is defined on line 680, but no explicit reference was found in the text == Unused Reference: 'Br97' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'Du98' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'Hu95' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'Ka98' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'Ma98' is defined on line 694, but no explicit reference was found in the text == Unused Reference: 'Mt98' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'Se98' is defined on line 700, 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. 'Hu95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ka98' ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. 'Ma98') -- Possible downref: Non-RFC (?) normative reference: ref. 'Mt98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Se98' Summary: 8 errors (**), 0 flaws (~~), 19 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Hardev Soor 2 INTERNET-DRAFT Debra Stopp 3 Expires in: January 2001 IXIA 5 Ralph Daniels 6 Netcom Systems 7 July 2000 9 Methodology for IP Multicast Benchmarking 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 The purpose of this draft is to describe methodology specific to the 36 benchmarking of multicast IP forwarding devices. It builds upon the 37 tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking 38 Methodology Working Group (BMWG) efforts. This document seeks to 39 extend these efforts to the multicast paradigm. 41 The BMWG produces two major classes of documents: Benchmarking 42 Terminology documents and Benchmarking Methodology documents. The 43 Terminology documents present the benchmarks and other related terms. 44 The Methodology documents define the procedures required to collect 45 the benchmarks cited in the corresponding Terminology documents. 47 1 Introduction 49 This document defines a specific set of tests that vendors can use to 50 measure and report the performance characteristics and forwarding 51 capabilities of network devices that support IP multicast protocols. 52 The results of these tests will provide the user comparable data from 53 different vendors with which to evaluate these devices. 55 A previous document, " Terminology for IP Multicast Benchmarking" 56 (RFC 2432), defined many of the terms that are used in this document. 57 The terminology document should be consulted before attempting to 58 make use of this document. 60 This methodology will focus on one source to many destinations, 61 although many of the tests described may be extended to use multiple 62 source to multiple destination IP multicast communication. 64 2 Key Words to Reflect Requirements 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119. 70 3 Test set up 72 Figure 1 shows a typical setup for an IP multicast test, with one 73 source to multiple destinations, although this MAY be extended to 74 multiple source to multiple destinations. 76 +----------------+ 77 +------------+ | | 78 +--------+ | |--------->| destination(1) | 79 | | | | | | 80 | source |-------->| | +----------------+ 81 | | | | +----------------+ 82 +--------+ | D U T |--------->| | 83 | | | destination(2) | 84 | | | | 85 | | +----------------+ 86 | | . . . 87 | | +----------------+ 88 | | | | 89 | |--------->| destination(n) | 90 | | | | 91 | | +----------------+ 92 | | 93 +------------+ 95 Figure 1 97 Generally , the destination ports first join the desired number of 98 multicast groups by sending IGMP Join Group messages to the DUT/SUT. 99 To verify that all destination ports successfully joined the 100 appropriate groups, the source port MUST transmit IP multicast frames 101 destined for these groups. The destination ports MAY send IGMP Leave 102 Group messages after the transmission of IP Multicast frames to clear 103 the IGMP table of the DUT/SUT. 105 In addition, all transmitted frames MUST contain a recognizable 106 pattern that can be filtered on in order to ensure the receipt of 107 only the frames that are involved in the test. 109 3.1 Test Considerations 111 3.2 IGMP Support 113 Each of the destination ports should support and be able to test all 114 IGMP versions 1, 2 and 3. The minimum requirement, however, is IGMP 115 version 2. 117 Each destination port should be able to respond to IGMP queries 118 during the test. 120 Each destination port should also send LEAVE (running IGMP version 2) 121 after each test. 123 3.3 Group Addresses 125 The Class D Group address SHOULD be changed between tests. Many DUTs 126 have memory or cache that is not cleared properly and can bias the 127 results. 129 The following group addresses are recommended by use in a test: 131 224.0.1.27-224.0.1.255 132 224.0.5.128-224.0.5.255 133 224.0.6.128-224.0.6.255 135 If the number of group addresses accommodated by these ranges do not 136 satisfy the requirements of the test, then these ranges may be 137 overlapped. The total number of configured group addresses must be 138 less than or equal to the IGMP table size of the DUT/SUT. 140 3.4 Frame Sizes 142 Each test SHOULD be run with different Multicast Frame Sizes. The 143 recommended frame sizes are 64, 128, 256, 512, 1024, 1280, and 1518 144 byte frames. 146 3.5 TTL 147 The source frames should have a TTL value large enough to accommodate 148 the DUT/SUT. 150 3.6 Layer 2 Support 152 Each of the destination ports should support GARP/GMRP protocols to 153 join groups on Layer 2 DUTs/SUTs. 155 4 Forwarding and Throughput 157 This section contains the description of the tests that are related 158 to the characterization of the packet forwarding of a DUT/SUT in a 159 multicast environment. Some metrics extend the concept of throughput 160 presented in RFC 1242. The notion of Forwarding Rate is cited in RFC 161 2285. 163 4.1 Mixed Class Throughput 165 Objective 167 To determine the maximum throughput rate at which none of the offered 168 frames, comprised from a unicast Class and a multicast Class, to be 169 forwarded are dropped by the device across a fixed number of ports as 170 defined in RFC 2432. 172 Procedure 174 Multicast and unicast traffic are mixed together in the same 175 aggregated traffic stream in order to simulate the non-homogenous 176 networking environment. While the multicast traffic is transmitted 177 from one source to multiple destinations, the unicast traffic MAY be 178 evenly distributed across the DUT/SUT architecture. In addition, the 179 DUT/SUT SHOULD learn the appropriate unicast IP addresses, either by 180 sending ARP frames from each unicast address, sending a RIP packet or 181 by assigning static entries into the DUT/SUT address table. 183 The mixture of multicast and unicast traffic MUST be set up in one of 184 two ways: 186 a) As a percent of the total traffic flow resulting in a ratio. 187 For example, 20 percent multicast traffic to 80 percent unicast 188 traffic. 190 b) In evenly distributed bursts of multicast and unicast 191 traffic, resulting in a 50-50 ratio of multicast to unicast 192 traffic. 194 The transmission of the frames MUST be set up so that they form a 195 deterministic distribution while still maintaining the specified 196 forwarding rates. See Appendix A for a discussion on non-homogenous 197 vs. homogenous packet distribution. 199 Similar to the Frame loss rate test in RFC 2544, the first trial 200 SHOULD be run for the frame rate that corresponds to 100% of the 201 maximum rate for the frame size on the input media. Repeat the 202 procedure for the rate that corresponds to 90% of the maximum rate 203 used and then for 80% of this rate. This sequence SHOULD be continued 204 (at reducing 10% intervals) until there are two successive trials in 205 which no frames are lost. The maximum granularity of the trials MUST 206 be 10% of the maximum rate, a finer granularity is encouraged. 208 Result 210 Parameters to be measured SHOULD include the frame loss and percent 211 loss for each class of traffic per destination port. The ratio of 212 unicast traffic to multicast traffic MUST be reported. 214 In addition, the transmit and receive rates in frames per second for 215 each source and destination port for both unicast and multicast 216 traffic, together with the number of frames transmitted and received 217 per port per class type traffic SHOULD be reported. 219 4.2 Scaled Group Forwarding Matrix 221 Definition 223 A table that demonstrates Forwarding Rate as a function of tested 224 multicast groups for a fixed number of tested DUT/SUT ports. 226 Procedure 228 Multicast traffic is sent at a fixed percent of maximum offered load 229 with a fixed number of receive ports of the tester at a fixed frame 230 length. 232 The receive ports SHOULD continue joining incrementally by 10 233 multicast groups until a user defined maximum is reached. 235 The receive ports will continue joining in the incremental fashion 236 until a user defined maximum is reached. 238 Results 240 Parameters to be measured SHOULD include the frame loss and percent 241 loss per destination port for each multicast group address. 243 In addition, the transmit and receive rates in frames per second for 244 each source and destination port for all multicast groups, together 245 with the number of frames transmitted and received per port per 246 multicast groups SHOULD be reported. 248 4.3 Aggregated Multicast Throughput 250 Definition 251 The maximum rate at which none of the offered frames to be forwarded 252 through N destination interfaces of the same multicast group are 253 dropped. 255 Procedure 257 Multicast traffic is sent at a fixed percent of maximum offered load 258 with a fixed number of groups at a fixed frame length for a fixed 259 duration of time. 261 The initial number of receive ports of the tester will join the 262 group(s) and the sender will transmit to the same groups after a 263 certain delay (a few seconds). 265 Then the an incremental number of receive ports will join the same 266 groups and then the Multicast traffic is sent as stated. 268 The receive ports will continue to be added and multicast traffic 269 sent until a user defined maximum number of ports is reached. 271 Results 273 Parameters to be measured SHOULD include the frame loss and percent 274 loss per destination port for each multicast group address. 276 In addition, the transmit and receive rates in frames per second for 277 each source and destination port for all multicast groups, together 278 with the number of frames transmitted and received per port per 279 multicast groups SHOULD be reported. 281 4.4 Encapsulation (Tunneling) Throughput 283 This sub-section provides the description of tests that help in 284 obtaining throughput measurements when a DUT/SUT or a set of DUTs are 285 acting as tunnel endpoints. The following Figure 2 presents the 286 scenario for the tests. 288 Client A DUT/SUT A Network DUT/SUT B Client B 290 ---------- ---------- 291 | | ------ | | 292 -----(a) (b)| |(c) ( ) (d)| |(e) (f)----- 293 ||||| -----> | |---->( )----->| |-----> ||||| 294 ----- | | ------ | | ----- 295 | | | | 296 ---------- ---------- 298 Figure 2 300 -------- 302 A tunnel is created between DUT/SUT A (the encapsulator) and DUT/SUT 303 B (the decapsulator). Client A is acting as a source and Client B is 304 the destination. Client B joins a multicast group (for example, 305 224.0.1.1) and it sends an IGMP Join message to DUT/SUT B to join 306 that group. Client A now wants to transmit some traffic to Client B. 307 It will send the multicast traffic to DUT/SUT A which encapsulates 308 the multicast frames, sends it to DUT/SUT B which will decapsulate 309 the same frames and forward them to Client B. 311 4.4.1 Encapsulation Throughput 313 Definition 315 The maximum rate at which frames offered a DUT/SUT are 316 encapsulated and correctly forwarded by the DUT/SUT without loss. 318 Procedure 320 To test the forwarding rate of the DUT/SUT when it has to go 321 through the process of encapsulation, a test port B is injected at 322 the other end of DUT/SUT A (Figure B) that will receive the 323 encapsulated frames and measure the throughput. Also, a test port 324 A is used to generate multicast frames that will be passed through 325 the tunnel. 327 The following is the test setup: 329 Test port A DUT/SUT A Test port B 331 ---------- (c') (d')--------- 332 | |-------------->| | 333 -------(a) (b)| | | | 334 ||||||| -----> | | ------ --------- 335 ------- | |(c) ( N/W ) 336 | |---->( ) 337 ---------- ------ 338 Figure 3 339 -------- 341 In Figure 2, a tunnel is created with the local IP address of 342 DUT/SUT A as the beginning of the tunnel (point c) and the IP 343 address of DUT/SUT B as the end of the tunnel (point d). DUT/SUT B 344 is assumed to have the tunneling protocol enabled so that the 345 frames can be decapsulated. When the test port B is inserted in 346 between the DUT/SUT A and DUT/SUT B (Figure 3), the endpoint of 347 tunnel has to be re-configured to be directed to the test port B's 348 IP address. For example, in Figure 3, point c' would be assigned 349 as the beginning of the tunnel and point d' as the end of the 350 tunnel. The test port B is acting as the end of the tunnel, and it 351 does not have to support any tunneling protocol since the frames 352 do not have to be decapsulated. Instead, the received encapsulated 353 frames are used to calculate the throughput and other necessary 354 measurements. 356 Result 358 Parameters to be measured SHOULD include the frame loss and 359 percent loss per destination port for each multicast group 360 address. 362 In addition, the transmit and receive rates in frames per second 363 for each source and destination port for all multicast groups, 364 together with the number of frames transmitted and received per 365 port per multicast groups SHOULD be reported. 367 4.4.2 Decapsulation Throughput 369 Definition 371 The maximum rate at which frames offered a DUT/SUT are 372 decapsulated and correctly forwarded by the DUT/SUT without loss. 374 Procedure 376 The decapsulation process returns the tunneled unicast frames back 377 to their multicast format. This test measures the throughput of 378 the DUT/SUT when it has to perform the process of decapsulation, 379 therefore, a test port C is used at the end of the tunnel to 380 receive the decapsulated frames (Figure 4). 382 Test port A DUT/SUT A Test port B DUT/SUT B Test port C 384 ---------- ---------- 385 | | | | 386 -----(a) (b)| |(c) ---- (d)| |(e) (f)----- 387 ||||| -----> | |----> |||| ----->| |-----> ||||| 388 ----- | | ---- | | ----- 389 | | | | 390 ---------- ---------- 392 Figure 4 393 -------- 395 In Figure 4, the encapsulation process takes place in DUT/SUT A. 396 This may effect the throughput of the DUT/SUT B. Therefore, two 397 test ports should be used to separate the encapsulation and 398 decapsulation processes. Client A is replaced with the test port A 399 which will generate a multicast frame that will be encapsulated by 400 DUT/SUT A. Another test port B is inserted between DUT/SUT A and 401 DUT/SUT B that will receive the encapsulated frames and forward it 402 to DUT/SUT B. Test port C will receive the decapsulated frames and 403 measure the throughput. 405 Result 406 Parameters to be measured SHOULD include the frame loss and 407 percent loss per destination port for each multicast group 408 address. 410 In addition, the transmit and receive rates in frames per second 411 for each source and destination port for all multicast groups, 412 together with the number of frames transmitted and received per 413 port per multicast groups SHOULD be reported. 415 4.4.3 Re-encapsulation Throughput 417 Definition 419 The maximum rate at which frames of one encapsulated format 420 offered a DUT/SUT are converted to another encapsulated format and 421 correctly forwarded by the DUT/SUT without loss. 423 Procedure 425 Re-encapsulation takes place in DUT/SUT B after test port C has 426 received the decapsulated frames. These decapsulated frames will 427 be re-inserted with a new encapsulation frame and sent to test 428 port B which will measure the throughput. See Figure 5. 430 Test port A DUT/SUT A Test port B DUT/SUT B Test port 431 C 433 ---------- ---------- 434 | | | | 435 -----(a) (b)| |(c) ---- (d)| |(e) (f)----- 436 ||||| -----> | |----> |||| <---->| |<----> ||||| 437 ----- | | ---- | | ----- 438 | | | | 439 ---------- ---------- 441 Figure 5 442 -------- 443 Result 445 Parameters to be measured SHOULD include the frame loss and 446 percent loss per destination port for each multicast group 447 address. 449 In addition, the transmit and receive rates in frames per second 450 for each source and destination port for all multicast groups, 451 together with the number of frames transmitted and received per 452 port per multicast groups SHOULD be reported. 454 5 Forwarding Latency 456 This section presents methodologies relating to the characterization 457 of the forwarding latency of a DUT/SUT in a multicast environment. It 458 extends the concept of latency characterization presented in RFC 459 2544. 461 5.1 Multicast Latency 463 Definition 465 The set of individual latencies from a single input port on the 466 DUT/SUT or SUT to all tested ports belonging to the destination 467 multicast group. 469 Procedure 471 According to RFC 2544, a tagged frame is sent half way through the 472 transmission that contains a timestamp used for calculation of 473 latency. In the multicast situation, a tagged frame is sent to all 474 destinations for each multicast group and latency calculated on a per 475 multicast group basis. Note that this test MUST be run using the 476 transmission rate that is less than the multicast throughput of the 477 DUT/SUT. Also, the test should take into account the DUT's/SUT's need 478 to cache the traffic in its IP cache, fastpath cache or shortcut 479 tables since the initial part of the traffic will be utilized to 480 build these tables. 482 Result 484 The parameter to be measured is the latency value for each multicast 485 group address per destination port. An aggregate latency MAY also be 486 reported. 488 5.2 Min/Max/Average Multicast Latency 490 Definition 492 The difference between the maximum latency measurement and the 493 minimum latency measurement from the set of latencies produced by the 494 Multicast Latency benchmark. 496 Procedure 498 First determine the throughput for DUT/SUT at each of the listed 499 frame sizes determined by the forwarding and throughput tests of 500 section 4. Send a stream of frames to a fixed number of multicast 501 groups through the DUT at the determined throughput rate. An 502 identifying tag SHOULD be included in all frames to ensure proper 503 identification of the transmitted frame on the receive side, the type 504 of tag being implementation dependent. 506 Latencies for each transmitted frame are calculated based on the 507 description of latencies in RFC 2544. The average latency is the 508 total of all accumulated latency values divided by the total number 509 of those values. The minimum latency is the smallest latency; the 510 maximum latency is the largest latency of all accumulated latency 511 values. 513 Results 515 The parameters to be measured are the minium, maximum and average 516 latency values for each multicast group address per destination port. 518 6 Overhead 520 This section presents methodology relating to the characterization of 521 the overhead delays associated with explicit operations found in 522 multicast environments. 524 6.1 Group Join Delay 526 Definition 528 The time duration it takes a DUT/SUT to start forwarding multicast 529 packets from the time a successful IGMP group membership report has 530 been issued to the DUT/SUT. 532 Procedure 534 Traffic is sent on the source port at the same time as the IGMP JOIN 535 Group message is transmitted from the destination ports. The join 536 delay is the difference in time from when the IGMP Join is sent 537 (timestamp A) and the first frame is forwarded to a receiving member 538 port (timestamp B). 540 Group Join delay = timestamp B - timestamp A 542 One of the keys is to transmit at the fastest rate the DUT/SUT can 543 handle multicast frames. This is to get the best resolution and the 544 least margin of error in the Join Delay. 546 However, you do not want to transmit the frames so fast that frames 547 are dropped by the DUT/SUT. Traffic should be sent at the throughput 548 rate determined by the forwarding tests of section 4. 550 Results 552 The parameter to be measured is the join delay time for each 553 multicast group address per destination port. In addition, the number 554 of frames transmitted and received and percent loss may be reported. 556 6.2 Group Leave Delay 558 Definition 560 The time duration it takes a DUT/SUT to cease forwarding multicast 561 packets after a corresponding IGMP "Leave Group" message has been 562 successfully offered to the DUT/SUT. 564 Procedure 566 Traffic is sent on the source port at the same time as the IGMP Leave 567 Group messages are transmitted from the destination ports. The leave 568 delay is the difference in time from when the IGMP leave is sent 569 (timestamp A) and the last frame is forwarded to a receiving member 570 port (timestamp B). 572 Group Leave delay = timestamp B - timestamp A 574 One of the keys is to transmit at the fastest rate the DUT/SUT can 575 handle multicast frames. This is to get the best resolution and 576 least margin of error in the Leave Delay. However, you do not want 577 to transmit the frames too fast that frames are dropped by the 578 DUT/SUT. Traffic should be sent at the throughput rate determined by 579 the forwarding tests of section 4. 581 Result 583 The parameter to be measured is the leave delay time for each 584 multicast group address per destination port. In addition, the number 585 of frames transmitted and received and percent loss may be reported. 587 7 Capacity 589 This section offers terms relating to the identification of multicast 590 group limits of a DUT/SUT. 592 7.1 Multicast Group Capacity 594 Definition 596 The maximum number of multicast groups a DUT/SUT can support while 597 maintaining the ability to forward multicast frames to all multicast 598 groups registered to that DUT/SUT. 600 Procedure 602 One or more destination ports of DUT/SUT will join an initial number 603 of groups. 605 Then after a delay (enough time for all ports to join) the source 606 port will transmit to each group at a transmission rate that the 607 DUT/SUT can handle without dropping IP Multicast frames. 609 If all frames sent are forwarded by the DUT/SUT and received the test 610 iteration is said to pass at the current capacity. 612 If the iteration passes at the capacity the test will add an user 613 defined incremental value of groups to each receive port. 615 The iteration is to run again at the new group level and capacity 616 tested as stated above. 618 Once the test fails at a capacity the capacity is stated to be the 619 last Iteration that pass at a giving capacity. 621 Results 623 The parameter to be measured is the total number of group addresses 624 that were successfully forwarded with no loss. 626 8 Interaction 628 Network forwarding devices are generally required to provide more 629 functionality than just the forwarding of traffic. Moreover, network 630 forwarding devices may be asked to provide those functions in a 631 variety of environments. This section offers terms to assist in the 632 characterization of DUT/SUT behavior in consideration of potentially 633 interacting factors. 635 8.1 Forwarding Burdened Multicast Latency 637 The Multicast Latency metrics can be influenced by forcing the 638 DUT/SUT to perform extra processing of packets while multicast 639 traffic is being forwarded for latency measurements. In this test, a 640 set of ports on the tester will be designated to be source and 641 destination similar to the generic IP Multicast test setup. In 642 addition to this setup, another set of ports will be selected to 643 transmit some multicast traffic that is destined to multicast group 644 addresses that have not been joined by these additional set of ports. 646 For example, if ports 1,2, 3, and 4 form the burdened response setup 647 (setup A) which is used to obtain the latency metrics and ports 5, 6, 648 7, and 8 form the non-burdened response setup (setup B) which will 649 afflict the burdened response setup, then setup B traffic will join 650 multicast group addresses not joined by the ports in this setup. By 651 sending such multicast traffic, the DUT/SUT will perform a lookup on 652 the packets that will affect the processing of setup A traffic. 654 8.2 Forwarding Burdened Group Join Delay 656 The port configuration in this test is similar to the one described 657 in section 8.1, but in this test, the multicast traffic is not sent 658 by the ports in setup B. In this test, the setup A traffic must be 659 influenced in such a way that will affect the DUT's/SUT's ability to 660 process Group Join messages. Therefore, in this test, the ports in 661 setup B will send a set of IGMP Group Join messages while the ports 662 in setup A are also joining its own set of group addresses. Since the 663 two sets of group addresses are independent of each other, the group 664 join delay for setup A may be different than in the case when there 665 were no other group addresses being joined. 667 9 Security Considerations 669 As this document is solely for the purpose of providing metric 670 methodology and describes neither a protocol nor a protocol's 671 implementation, there are no security considerations associated with 672 this document. 674 10 675 References 677 [Br91] Bradner, S., "Benchmarking Terminology for Network 678 Interconnection Devices", RFC 1242, July 1991. 680 [Br96] Bradner, S., and J. McQuaid, "Benchmarking Methodology for 681 Network Interconnect Devices", RFC 2544, March 1999. 683 [Br97] Bradner, S. "Use of Keywords in RFCs to Reflect Requirement 684 Levels, RFC 2119, March 1997 686 [Du98] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC 687 2432, October 1998. 689 [Hu95] Huitema, C. "Routing in the Internet." Prentice-Hall, 1995. 691 [Ka98] Kosiur, D., "IP Multicasting: the Complete Guide to Interactive 692 Corporate Networks", John Wiley & Sons, Inc, 1998. 694 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching 695 Devices", RFC 2285, February 1998. 697 [Mt98] Maufer, T. "Deploying IP Multicast in the Enterprise." Prentice- 698 Hall, 1998. 700 [Se98] Semeria, C. and Maufer, T. "Introduction to IP Multicast 701 Routing." http://www.3com.com/nsc/501303.html 3Com Corp., 1998. 703 11 704 Author's Addresses 706 Hardev Soor 707 IXIA 708 26601 W. Agoura Rd. 709 Calabasas, CA 91302 710 USA 712 Phone: 818 871 1800 713 EMail: hardev@ixiacom.com 715 Debra Stopp 716 IXIA 717 26601 W. Agoura Rd. 718 Calabasas, CA 91302 719 USA 721 Phone: 818 871 1800 722 EMail: debby@ixiacom.com 724 Ralph Daniels 725 Netcom Systems 726 948 Loop Road 727 Clayton, NC 27520 728 USA 730 Phone: 919 550 9475 731 EMail: Ralph_Daniels@NetcomSystems.com 733 Appendix A: Determining an even distribution 735 It is important to understand and fully define the distribution of 736 frames among all multicast and unicast destinations. If the 737 distribution is not well defined or understood, the throughput and 738 forwarding metrics are not meaningful. 740 In a homogeneous environment, a large single burst of multicast 741 frames may be followed by a large burst of unicast frames. This is a 742 very different distribution than that of a non-homogeneous 743 environment, where the multicast and unicast frames are intermingled 744 throughout the entire transmission. 746 The recommended distribution is that of the non-homogeneous 747 environment because it more closely represents a real-world scenario. 748 The distribution is modeled by calculating the number of multicast 749 frames per destination port as a burst, then calculating the number 750 of unicast frames to transmit as a percentage of the total frames 751 transmitted. The overall effect of the distribution is small bursts 752 of multicast frames intermingled with small bursts of unicast frames. 754 12 755 Full Copyright Statement 757 "Copyright (C) The Internet Society (date). All Rights Reserved. This 758 document and translations of it may be copied and furnished to 759 others, and derivative works that comment on or otherwise explain it 760 or assist in its implementation may be prepared, copied, published 761 and distributed, in whole or in part, without restriction of any 762 kind, provided that the above copyright notice and this paragraph are 763 included on all such copies and derivative works. However, this 764 document itself may not be modified in any way, such as by removing 765 the copyright notice or references to the Internet Society or other 766 Internet organizations, except as needed for the purpose of 767 developing Internet standards in which case the procedures for 768 copyrights defined in the Internet Standards process must be 769 followed, or as required to translate it into.