idnits 2.17.1 draft-ietf-bmwg-mcastm-03.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? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 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 18 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 10 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 up...' == Line 24 has weird spacing: '...opriate to u...' == (17 more instances...) == 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: This appendix discusses the suggested approach to configuring the deterministic distribution methodology for tests that involve both multicast and unicast traffic classes in an aggregated traffic stream. As such, this appendix MUST not be read as an amendment to the methodology described in the body of this document but as a guide to testing practice. -- 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 (March 2000) is 8808 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 672, but no explicit reference was found in the text == Unused Reference: 'Br96' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'Br97' is defined on line 678, but no explicit reference was found in the text == Unused Reference: 'Du98' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'Hu95' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'Ka98' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'Ma98' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'Mt98' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'Se98' is defined on line 695, 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: 9 errors (**), 0 flaws (~~), 20 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: August 2000 Ixia Communications 5 Ralph Daniels 6 Netcom Systems 7 March 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. To 99 verify that all destination ports successfully joined the appropriate 100 groups, the source port MUST transmit IP multicast frames destined for 101 these groups. The destination ports MAY send IGMP Leave Group messages 102 after the transmission of IP Multicast frames to clear the IGMP table of 103 the DUT/SUT. 105 In addition, all transmitted frames MUST contain a recognizable pattern 106 that can be filtered on in order to ensure the receipt of only the 107 frames that are involved in the test. 109 3.1 Test Considerations 111 3.2 IGMP Support 113 Each of the receiving ports of the tester should support and be able 114 to test all IGMP versions 1, 2 and 3. The minimum requirement, 115 however, is IGMP version 2. 117 Each receiving port should be able to respond to IGMP queries during 118 the test. 120 Each receiving 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 receiving ports of the tester should support GARP/GMRP 153 protocols to join groups on Layer 2 DUTs/SUTs. 155 4 Forwarding and Throughput 157 This section contains the description of the tests that are related to 158 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 Definition 167 The maximum rate at which none of the offered frames, comprised from 168 a unicast Class and a multicast Class, to be forwarded are dropped by 169 the device across a fixed number of ports. 171 Procedure 173 Multicast and unicast traffic are mixed together in the same 174 aggregated traffic stream in order to simulate the non-homogenous 175 networking environment. While the multicast traffic is transmitted 176 from one source to multiple destinations, the unicast traffic MAY be 177 evenly distributed across the DUT/SUT architecture. In addition, the 178 DUT/SUT SHOULD learn the appropriate unicast IP addresses, either by 179 sending ARP frames from each unicast address, sending a RIP packet or 180 by assigning static entries into the DUT/SUT address table. 182 The mixture of multicast and unicast traffic MUST be set up in one of 183 two ways: 185 a) As a percent of the total bandwidth resulting in a ratio. For 186 example, 20 percent multicast traffic to 80 percent unicast 187 traffic. 189 b) In evenly distributed bursts of multicast and unicast 190 traffic, resulting in a 50-50 ratio of multicast to unicast 191 traffic. 193 The transmission of the frames MUST be set up so that they form a 194 deterministic distribution while still maintaining the specified 195 bandwidth and transmission rates. See Appendix A for a discussion on 196 determining an even distribution. 198 Similar to the Frame loss rate test in RFC 2544, the first trial 199 SHOULD be run for the frame rate that corresponds to 100% of the 200 maximum rate for the frame size on the input media. Repeat the 201 procedure for the rate that corresponds to 90% of the maximum rate 202 used and then for 80% of this rate. This sequence SHOULD be continued 203 (at reducing 10% intervals) until there are two successive trials in 204 which no frames are lost. The maximum granularity of the trials MUST 205 be 10% of the maximum rate, a finer granularity is encouraged. 207 Result 209 Parameters to be measured SHOULD include the frame loss and percent 210 loss for each class of traffic per destination port. The ratio of 211 unicast traffic to multicast traffic MUST be reported. 213 In addition, the transmit and receive rates in frames per second for 214 each source and destination port for both unicast and multicast 215 traffic, together with the number of frames transmitted and received 216 per port per class type traffic SHOULD be reported. 218 4.2 Scaled Group Forwarding Matrix 220 Definition 222 A table that demonstrates Forwarding Rate as a function of tested 223 multicast groups for a fixed number of tested DUT/SUT ports. 225 Procedure 227 Multicast traffic is sent at a fixed percent of line rate with a 228 fixed number of receive ports of the tester at a fixed frame length. 230 The receive ports SHOULD continue joining incrementally by 10 231 multicast groups until a user defined maximum is reached. 233 The receive ports will continue joining in the incremental fashion 234 until a user defined maximum is reached. 236 Results 238 Parameters to be measured SHOULD include the frame loss and percent 239 loss per destination port for each multicast group address. 241 In addition, the transmit and receive rates in frames per second for 242 each source and destination port for all multicast groups, together 243 with the number of frames transmitted and received per port per 244 multicast groups SHOULD be reported. 246 4.3 Aggregated Multicast Throughput 248 Definition 249 The maximum rate at which none of the offered frames to be forwarded 250 through N destination interfaces of the same multicast group are 251 dropped. 253 Procedure 255 Multicast traffic is sent at a fixed percent of line rate with a 256 fixed number of groups at a fixed frame length for a fixed duration 257 of time. 259 The initial number of receive ports of the tester will join the 260 group(s) and the sender will transmit to the same groups after a 261 certain delay (a few seconds). 263 Then the an incremental number of receive ports will join the same 264 groups and then the Multicast traffic is sent as stated. 266 The receive ports will continue to be added and multicast traffic 267 sent until a user defined maximum number of ports is reached. 269 Results 271 Parameters to be measured SHOULD include the frame loss and percent 272 loss per destination port for each multicast group address. 274 In addition, the transmit and receive rates in frames per second for 275 each source and destination port for all multicast groups, together 276 with the number of frames transmitted and received per port per 277 multicast groups SHOULD be reported. 279 4.4 Encapsulation (Tunneling) Throughput 281 This sub-section provides the description of tests that help in 282 obtaining throughput measurements when a DUT/SUT or a set of DUTs are 283 acting as tunnel endpoints. The following Figure 2 presents the 284 scenario for the tests. 286 Client A DUT/SUT A Network DUT/SUT B Client B 288 ---------- ---------- 289 | | ------ | | 290 -----(a) (b)| |(c) ( ) (d)| |(e) (f)----- 291 ||||| -----> | |---->( )----->| |-----> ||||| 292 ----- | | ------ | | ----- 293 | | | | 294 ---------- ---------- 296 Figure 2 298 -------- 300 A tunnel is created between DUT/SUT A (the encapsulator) and DUT/SUT 301 B (the decapsulator). Client A is acting as a source and Client B is 302 the destination. Client B joins a multicast group (for example, 303 224.0.1.1) and it sends an IGMP Join message to DUT/SUT B to join 304 that group. Client A now wants to transmit some traffic to Client B. 305 It will send the multicast traffic to DUT/SUT A which encapsulates 306 the multicast frames, sends it to DUT/SUT B which will decapsulate 307 the same frames and forward them to Client B. 309 4.4.1 Encapsulation Throughput 311 Definition 313 The maximum rate at which frames offered a DUT/SUT are 314 encapsulated and correctly forwarded by the DUT/SUT without loss. 316 Procedure 318 To test the forwarding rate of the DUT/SUT when it has to go 319 through the process of encapsulation, a test port B is injected at 320 the other end of DUT/SUT A (Figure B) that will receive the 321 encapsulated frames and measure the throughput. Also, a test port 322 A is used to generate multicast frames that will be passed through 323 the tunnel. 325 The following is the test setup: 327 Test port A DUT/SUT A Test port B 329 ---------- (c') (d')--------- 330 | |-------------->| | 331 -------(a) (b)| | | | 332 ||||||| -----> | | ------ --------- 333 ------- | |(c) ( N/W ) 334 | |---->( ) 335 ---------- ------ 336 Figure 3 337 -------- 339 In Figure 2, a tunnel is created with the local IP address of 340 DUT/SUT A as the beginning of the tunnel (point c) and the IP 341 address of DUT/SUT B as the end of the tunnel (point d). DUT/SUT B 342 is assumed to have the tunneling protocol enabled so that the 343 frames can be decapsulated. When the test port B is inserted in 344 between the DUT/SUT A and DUT/SUT B (Figure 3), the endpoint of 345 tunnel has to be re-configured to be directed to the test port B's 346 IP address. For example, in Figure 3, point c' would be assigned 347 as the beginning of the tunnel and point d' as the end of the 348 tunnel. The test port B is acting as the end of the tunnel, and it 349 does not have to support any tunneling protocol since the frames 350 do not have to be decapsulated. Instead, the received encapsulated 351 frames are used to calculate the throughput and other necessary 352 measurements. 354 Result 356 Parameters to be measured SHOULD include the frame loss and 357 percent loss per destination port for each multicast group 358 address. 360 In addition, the transmit and receive rates in frames per second 361 for each source and destination port for all multicast groups, 362 together with the number of frames transmitted and received per 363 port per multicast groups SHOULD be reported. 365 4.4.2 Decapsulation Throughput 367 Definition 369 The maximum rate at which frames offered a DUT/SUT are 370 decapsulated and correctly forwarded by the DUT/SUT without loss. 372 Procedure 374 The decapsulation process returns the tunneled unicast frames back 375 to their multicast format. This test measures the throughput of 376 the DUT/SUT when it has to perform the process of decapsulation, 377 therefore, a test port C is used at the end of the tunnel to 378 receive the decapsulated frames (Figure 4). 380 Test port A DUT/SUT A Test port B DUT/SUT B Test port C 382 ---------- ---------- 383 | | | | 384 -----(a) (b)| |(c) ---- (d)| |(e) (f)----- 385 ||||| -----> | |----> |||| ----->| |-----> ||||| 386 ----- | | ---- | | ----- 387 | | | | 388 ---------- ---------- 390 Figure 4 391 -------- 393 In Figure 4, the encapsulation process takes place in DUT/SUT A. 394 This may effect the throughput of the DUT/SUT B. Therefore, two 395 test ports should be used to separate the encapsulation and 396 decapsulation processes. Client A is replaced with the test port A 397 which will generate a multicast frame that will be encapsulated by 398 DUT/SUT A. Another test port B is inserted between DUT/SUT A and 399 DUT/SUT B that will receive the encapsulated frames and forward it 400 to DUT/SUT B. Test port C will receive the decapsulated frames and 401 measure the throughput. 403 Result 404 Parameters to be measured SHOULD include the frame loss and 405 percent loss per destination port for each multicast group 406 address. 408 In addition, the transmit and receive rates in frames per second 409 for each source and destination port for all multicast groups, 410 together with the number of frames transmitted and received per 411 port per multicast groups SHOULD be reported. 413 4.4.3 Re-encapsulation Throughput 415 Definition 417 The maximum rate at which frames of one encapsulated format 418 offered a DUT/SUT are converted to another encapsulated format and 419 correctly forwarded by the DUT/SUT without loss. 421 Procedure 423 Re-encapsulation takes place in DUT/SUT B after test port C has 424 received the decapsulated frames. These decapsulated frames will 425 be re-inserted with a new encapsulation frame and sent to test 426 port B which will measure the throughput. See Figure 5. 428 Test port A DUT/SUT A Test port B DUT/SUT B Test port C 430 ---------- ---------- 431 | | | | 432 -----(a) (b)| |(c) ---- (d)| |(e) (f)----- 433 ||||| -----> | |----> |||| <---->| |<----> ||||| 434 ----- | | ---- | | ----- 435 | | | | 436 ---------- ---------- 438 Figure 5 439 -------- 440 Result 442 Parameters to be measured SHOULD include the frame loss and 443 percent loss per destination port for each multicast group 444 address. 446 In addition, the transmit and receive rates in frames per second 447 for each source and destination port for all multicast groups, 448 together with the number of frames transmitted and received per 449 port per multicast groups SHOULD be reported. 451 5 Forwarding Latency 453 This section presents methodologies relating to the characterization of 454 the forwarding latency of a DUT/SUT in a multicast environment. It 455 extends the concept of latency characterization presented in RFC 2544. 457 5.1 Multicast Latency 459 Definition 461 The set of individual latencies from a single input port on the 462 DUT/SUT or SUT to all tested ports belonging to the destination 463 multicast group. 465 Procedure 467 According to RFC 2544, a tagged frame is sent half way through the 468 transmission that contains a timestamp used for calculation of 469 latency. In the multicast situation, a tagged frame is sent to all 470 destinations for each multicast group and latency calculated on a per 471 multicast group basis. Note that this test MUST be run using the 472 transmission rate that is less than the multicast throughput of the 473 DUT/SUT. Also, the test should take into account the DUT's/SUT's need 474 to cache the traffic in its IP cache, fastpath cache or shortcut 475 tables since the initial part of the traffic will be utilized to 476 build these tables. 478 Result 480 The parameter to be measured is the latency value for each multicast 481 group address per destination port. An aggregate latency MAY also be 482 reported. 484 5.2 Min/Max/Average Multicast Latency 486 Definition 488 The difference between the maximum latency measurement and the 489 minimum latency measurement from the set of latencies produced by the 490 Multicast Latency benchmark. 492 Procedure 494 First determine the throughput for DUT/SUT at each of the listed 495 frame sizes determined by the forwarding and throughput tests of 496 section 4. Send a stream of frames to a fixed number of multicast 497 groups through the DUT at the determined throughput rate. An 498 identifying tag SHOULD be included in all frames to ensure proper 499 identification of the transmitted frame on the receive side, the type 500 of tag being implementation dependent. 502 Latencies for each transmitted frame are calculated based on the 503 description of latencies in RFC 2544. The average latency is the 504 total of all accumulated latency values divided by the total number 505 of those values. The minimum latency is the smallest latency; the 506 maximum latency is the largest latency of all accumulated latency 507 values. 509 Results 511 The parameters to be measured are the minium, maximum and average 512 latency values for each multicast group address per destination port. 514 6 Overhead 516 This section presents methodology relating to the characterization of 517 the overhead delays associated with explicit operations found in 518 multicast environments. 520 6.1 Group Join Delay 522 Definition 524 The time duration it takes a DUT/SUT to start forwarding multicast 525 packets from the time a successful IGMP group membership report has 526 been issued to the DUT/SUT. 528 Procedure 530 Traffic is sent on the source port at the same time as the IGMP JOIN 531 Group message is transmitted from the destination ports. The join 532 delay is the difference in time from when the IGMP Join is sent 533 (timestamp A) and the first frame is forwarded to a receiving member 534 port (timestamp B). 536 Group Join delay = timestamp B - timestamp A 538 One of the keys is to transmit at the fastest rate the DUT/SUT can 539 handle multicast frames. This is to get the best resolution and the 540 least margin of error in the Join Delay. 542 However, you do not want to transmit the frames so fast that frames 543 are dropped by the DUT/SUT. Traffic should be sent at the throughput 544 rate determined by the forwarding tests of section 4. 546 Results 548 The parameter to be measured is the join delay time for each 549 multicast group address per destination port. In addition, the number 550 of frames transmitted and received and percent loss may be reported. 552 6.2 Group Leave Delay 554 Definition 555 The time duration it takes a DUT/SUT to cease forwarding multicast 556 packets after a corresponding IGMP "Leave Group" message has been 557 successfully offered to the DUT/SUT. 559 Procedure 561 Traffic is sent on the source port at the same time as the IGMP Leave 562 Group messages are transmitted from the destination ports. The leave 563 delay is the difference in time from when the IGMP leave is sent 564 (timestamp A) and the last frame is forwarded to a receiving member 565 port (timestamp B). 567 Group Leave delay = timestamp B - timestamp A 569 One of the keys is to transmit at the fastest rate the DUT/SUT can 570 handle multicast frames. This is to get the best resolution and 571 least margin of error in the Leave Delay. However, you do not want 572 to transmit the frames too fast that frames are dropped by the 573 DUT/SUT. Traffic should be sent at the throughput rate determined by 574 the forwarding tests of section 4. 576 Result 578 The parameter to be measured is the leave delay time for each 579 multicast group address per destination port. In addition, the number 580 of frames transmitted and received and percent loss may be reported. 582 7 Capacity 584 This section offers terms relating to the identification of multicast 585 group limits of a DUT/SUT. 587 7.1 Multicast Group Capacity 589 Definition 591 The maximum number of multicast groups a DUT/SUT can support while 592 maintaining the ability to forward multicast frames to all multicast 593 groups registered to that DUT/SUT. 595 Procedure 597 One or more receiving ports of DUT/SUT will join an initial number of 598 groups. 600 Then after a delay (enough time for all ports to join) the source 601 port will transmit to each group at a transmission rate that the 602 DUT/SUT can handle without dropping IP Multicast frames. 604 If all frames sent are forwarded by the DUT/SUT and received the test 605 iteration is said to pass at the current capacity. 607 If the iteration passes at the capacity the test will add an user 608 defined incremental value of groups to each receive port. 610 The iteration is to run again at the new group level and capacity 611 tested as stated above. 613 Once the test fails at a capacity the capacity is stated to be the 614 last Iteration that pass at a giving capacity. 616 Results 618 The parameter to be measured is the total number of group addresses 619 that were successfully forwarded with no loss. 621 8 Interaction 623 Network forwarding devices are generally required to provide more 624 functionality than just the forwarding of traffic. Moreover, network 625 forwarding devices may be asked to provide those functions in a variety 626 of environments. This section offers terms to assist in the 627 characterization of DUT/SUT behavior in consideration of potentially 628 interacting factors. 630 8.1 Forwarding Burdened Multicast Latency 632 The Multicast Latency metrics can be influenced by forcing the 633 DUT/SUT to perform extra processing of packets while multicast 634 traffic is being forwarded for latency measurements. In this test, a 635 set of ports on the tester will be designated to be source and 636 destination similar to the generic IP Multicast test setup. In 637 addition to this setup, another set of ports will be selected to 638 transmit some multicast traffic that is destined to multicast group 639 addresses that have not been joined by these additional set of ports. 641 For example, if ports 1,2, 3, and 4 form the burdened response setup 642 (setup A) which is used to obtain the latency metrics and ports 5, 6, 643 7, and 8 form the non-burdened response setup (setup B) which will 644 afflict the burdened response setup, then setup B traffic will join 645 multicast group addresses not joined by the ports in this setup. By 646 sending such multicast traffic, the DUT/SUT will perform a lookup on 647 the packets that will affect the processing of setup A traffic. 649 8.2 Forwarding Burdened Group Join Delay 651 The port configuration in this test is similar to the one described 652 in section 8.1, but in this test, the multicast traffic is not sent 653 by the ports in setup B. In this test, the setup A traffic must be 654 influenced in such a way that will affect the DUT's/SUT's ability to 655 process Group Join messages. Therefore, in this test, the ports in 656 setup B will send a set of IGMP Group Join messages while the ports 657 in setup A are also joining its own set of group addresses. Since the 658 two sets of group addresses are independent of each other, the group 659 join delay for setup A may be different than in the case when there 660 were no other group addresses being joined. 662 9 Security Considerations 664 As this document is solely for the purpose of providing metric 665 methodology and describes neither a protocol nor a protocol's 666 implementation, there are no security considerations associated with 667 this document. 669 10 670 References 672 [Br91] Bradner, S., "Benchmarking Terminology for Network 673 Interconnection Devices", RFC 1242, July 1991. 675 [Br96] Bradner, S., and J. McQuaid, "Benchmarking Methodology for 676 Network Interconnect Devices", RFC 2544, March 1999. 678 [Br97] Bradner, S. "Use of Keywords in RFCs to Reflect Requirement 679 Levels, RFC 2119, March 1997 681 [Du98] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC 682 2432, October 1998. 684 [Hu95] Huitema, C. "Routing in the Internet." Prentice-Hall, 1995. 686 [Ka98] Kosiur, D., "IP Multicasting: the Complete Guide to Interactive 687 Corporate Networks", John Wiley & Sons, Inc, 1998. 689 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching 690 Devices", RFC 2285, February 1998. 692 [Mt98] Maufer, T. "Deploying IP Multicast in the Enterprise." Prentice- 693 Hall, 1998. 695 [Se98] Semeria, C. and Maufer, T. "Introduction to IP Multicast 696 Routing." http://www.3com.com/nsc/501303.html 3Com Corp., 1998. 698 11 699 Author's Addresses 701 Hardev Soor 702 Ixia Communications 703 4505 Las Virgenes Road, Suite 209 704 Calabasas, CA 91302 705 USA 707 Phone: 818 871 1800 708 EMail: hardev@ixia.com 709 Debra Stopp 710 Ixia Communications 711 4505 Las Virgenes Road, Suite 209 712 Calabasas, CA 91302 713 USA 715 Phone: 818 871 1800 716 EMail: debby@ixia.com 718 Ralph Daniels 719 Netcom Systems 720 948 Loop Road 721 Clayton, NC 27520 722 USA 724 Phone: 919 550 9475 725 EMail: Ralph_Daniels@NetcomSystems.com 726 Appendix A: Determining an even distribution 728 A.1 Scope Of This Appendix 730 This appendix discusses the suggested approach to configuring the 731 deterministic distribution methodology for tests that involve both 732 multicast and unicast traffic classes in an aggregated traffic stream. 733 As such, this appendix MUST not be read as an amendment to the 734 methodology described in the body of this document but as a guide to 735 testing practice. 737 It is important to understand and fully define the distribution of 738 frames among all multicast and unicast destinations. If the 739 distribution is not well defined or understood, the throughput and 740 forwarding metrics are not meaningful. 742 In a homogeneous environment, a large, single burst of multicast frames 743 may be followed by a large burst of unicast frames. This is a very 744 different distribution than that of a non-homogeneous environment, where 745 the multicast and unicast frames are intermingled 746 throughout the entire transmission. 748 The recommended distribution is that of the non-homogeneous environment 749 because it more closely represents a real-world scenario. The 750 distribution is modeled by calculating the number of multicast frames 751 per destination port as a burst, then calculating the number of unicast 752 frames to transmit as a percentage of the total frames transmitted. The 753 overall effect of the distribution is small bursts of multicast frames 754 intermingled with small bursts of unicast frames. 756 Example 758 This example illustrates the distribution algorithm for a 100 Mbps rate. 760 Frame size = 64 761 Duration of test = 30 seconds 762 Intended Load (ILOAD) = 100% of maximum rate 763 Mapping for unicast traffic: Port 1 to Port 2 764 Port 3 to port 4 765 Mapping for multicast traffic: Port 1 to Ports 2,3,4 766 Number of Multicast group addresses per destination port = 3 767 Multicast groups joined by Port 2: 224.0.1.27 768 224.0.1.28 769 224,0.1.29 770 Multicast groups joined by Port 3: 224.0.1.30 771 224.0.1.31 772 224,0.1.32 774 Multicast groups joined by Port 4: 224.0.1.33 775 224.0.1.34 776 224,0.1.35 778 Percentage of Unicast frames = 20 779 Percentage of Multicast frames = 80 780 Total number of frames to be transmitted = 148810 fps * 30 sec 781 = 4464300 frames 782 Number of unicast frames = 20/100 * 4464300 = 892860 frames 783 Number of multicast frames = 80/100 * 4464300 = 3571440 frames 785 Unicast burst size = 20 * 9 = 180 786 Multicast burst size = 80 * 9 = 720 787 Loop counter = 4464300 / 900 = 4960.3333 (round it off to 4960) 789 Therefore, the actual number of frames that will be transmitted: 790 Unicast frames = 4960 * 180 = 892800 frames 791 Multicast frames = 4960 * 720 = 3571200 frames 793 The following pattern will be established: 795 UUUMMMMMMMMMMMMUUUMMMMMMMMMMMMUUUMMMMMMMMMMMMUUUMMMMMMMMMMMM 797 where U represents 60 Unicast frames (U = 180 frames) 798 M represents 60 Multicast frames (M = 720 frames) 800 12 801 Full Copyright Statement 803 "Copyright (C) The Internet Society (date). All Rights Reserved. This 804 document and translations of it may be copied and furnished to others, 805 and derivative works that comment on or otherwise explain it or assist 806 in its implementation may be prepared, copied, published and 807 distributed, in whole or in part, without restriction of any kind, 808 provided that the above copyright notice and this paragraph are 809 included on all such copies and derivative works. However, this 810 document itself may not be modified in any way, such as by removing the 811 copyright notice or references to the Internet Society or other 812 Internet organizations, except as needed for the purpose of developing 813 Internet standards in which case the procedures for copyrights defined 814 in the Internet Standards process must be followed, or as required to 815 translate it into.