idnits 2.17.1 draft-ietf-bmwg-mcastm-02.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 == 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 177 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == 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...' == Line 24 has weird spacing: '...opriate to u...' == (16 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 (October 1999) is 8960 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 708, but no explicit reference was found in the text == Unused Reference: 'Br96' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'Br97' is defined on line 714, but no explicit reference was found in the text == Unused Reference: 'Du98' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'Hu95' is defined on line 720, but no explicit reference was found in the text == Unused Reference: 'Ka98' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'Ma98' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'Mt98' is defined on line 728, but no explicit reference was found in the text == Unused Reference: 'Se98' is defined on line 731, 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 (~~), 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: March 2000 Ixia Communications 5 Ralph Daniels 6 Netcom Systems 7 October 1999 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 +------------+ 94 Figure 1 96 Generally , the destination ports first join the desired number of 97 multicast groups by sending IGMP Join Group messages to the DUT/SUT. 98 To verify that all destination ports successfully joined the 99 appropriate groups, the source port MUST transmit IP multicast 100 frames destined for these groups. The destination ports MAY send 101 IGMP Leave Group messages after the transmission of IP Multicast 102 frames to clear the IGMP table of the DUT/SUT. 104 In addition, all transmitted frames MUST contain a recognizable 105 pattern that can be filtered on in order to ensure the receipt of only 106 the frames that are involved in the test. 108 3.1 Test Considerations 110 3.1.1 IGMP Support 112 Each of the receiving ports of the tester should support and be 113 able to test all IGMP versions 1, 2 and 3. The minimum requirement, 114 however, is IGMP version 2. 116 Each receiving port should be able to respond to IGMP queries during the 117 test. 119 Each receiving port should also send LEAVE (running IGMP version 2) 120 after each test. 122 3.1.2 Group Addresses 124 The Class D Group address should be changed between tests. Many 125 DUTs have memory or cache that is not cleared properly and can 126 bias the results. 128 The following group addresses are recommended by use in a test: 130 224.0.1.27-224.0.1.255 131 224.0.5.128-224.0.5.255 132 224.0.6.128-224.0.6.255 134 If the number of group addresses accomodated by these ranges do not 135 satisfy the requrirements of the test, then these ranges may be 136 overlapped. 138 3.1.3 Frame Sizes 140 Each test should be run with different Multicast Frame Sizes. The 141 recommended frame sizes are 64, 128, 256, 512, 1024, 1280, and 1518 142 byte frames. 144 3.1.4 TTL 145 The source frames should have a TTL value large enough to accommodate 146 the DUT/SUT. 148 3.1.5 Layer 2 Support 150 Each of the receiving ports of the tester should support GARP/GMRP 151 protocols to join groups on Layer 2 DUTs/SUTs. 153 4. Forwarding and Throughput 155 This section contains the description of the tests that are related to 156 the characterization of the packet forwarding of a DUT/SUT in a 157 multicast environment. Some metrics extend the concept of throughput 158 presented in RFC 1242. The notion of Forwarding Rate is cited in RFC 159 2285. 161 4.1 Mixed Class Throughput 163 Definition 164 The maximum rate at which none of the offered frames, comprised from 165 a unicast Class and a multicast Class, to be forwarded are dropped 166 by the device across a fixed number of ports. 168 Procedure 170 Multicast and unicast traffic are mixed together in the same 171 aggregated traffic stream in order to simulate the non-homogenous 172 networking environment. While the multicast traffic is transmitted 173 from one source to multiple destinations, the unicast traffic MAY be 174 evenly distributed across the DUT/SUT architecture. In addition, the 175 DUT/SUT SHOULD learn the appropriate unicast IP addresses, either by 176 sending ARP frames from each unicast address, sending a RIP packet 177 or by assigning static entries into the DUT/SUT address table. 179 The rates at which traffic is transmitted for both traffic classes 180 MUST be set up in one of two ways: 182 a) A percentage of the bandwidth is allocated for each traffic class 183 and frames for each class are transmitted at the rate equal to 184 the allocated bandwidth. For example, 64 byte frames can be 185 transmitted at a theoretical maximum rate of 148810 frames/second. 186 If 80 percent of the bandwidth is allocated for unicast traffic 187 and 20 percent for multicast traffic, then unicast traffic will 188 be sent at a maximum rate of 119048 frames/second and the 189 multicast traffic at a rate of 29762 frames/second. 191 b) Transmission rate is fixed for both traffic classes and a percentage of 192 number of frames for each traffic class is specified. For example, if a 193 fixed rate of 100% of theoretical maximum is desired, then 64 byte 194 frames will be sent at 148810 frames/second for both unicast and 195 multicast traffic. If 80 percent of the frames are to be unicast and 196 20 percent multicast, then for a duration of 30 seconds, 3571440 197 frames of unicast and 892860 frames of multicast will be sent. This 198 fixed rate scenario actually over-subscribes the bandwidth, 199 potentially causing congestion in the DUT/SUT. 201 The transmission of the frames MUST be set up so that they form a 202 deterministic distribution while still maintaining the specified bandwidth 203 and transmission rates. See Appendix A for a discussion on determining an 204 even distribution. 206 Similar to the Frame loss rate test in RFC 2544, the first trial SHOULD be 207 run for the frame rate that corresponds to 100% of the maximum rate for 208 the frame size on the input media. Repeat the procedure for the rate that 209 corresponds to 90% of the maximum rate used and then for 80% of this rate. 210 This sequence SHOULD be continued (at reducing 10% intervals) until there 211 are two successive trials in which no frames are lost. The maximum 212 granularity of the trials MUST be 10% of the maximum rate, a finer 213 granularity is encouraged. 215 Result 217 Transmit and Receive rates in frames per second for each source and 218 destination port for both unicast and multicast traffic for each trial 219 percent transmit rate. The ratio of the Unicast traffic versus Multicast 220 traffic SHOULD be reported. The result report SHOULD contain the number of 221 frames transmitted and received per port per class type (unicast and 222 multicast traffic), reported in number of frames and percent loss per 223 port. 225 4.2 Scaled Group Forwarding Matrix 227 Definition: 229 A table that demonstrates Forwarding Rate as a function of tested 230 multicast groups for a fixed number of tested DUT/SUT ports. 232 Procedure: 234 Multicast traffic is sent at a fixed percent of line rate with a fixed 235 number of receive ports of the tester at a fixed frame length. 237 The receive ports will join an initial number of groups and the sender 238 will transmit to the same groups after a certain delay (a few seconds). 240 Then the receive ports will join an incremental value of groups and the 241 transmit port will send to all groups joined (initial plus incremental). 243 The receive ports will continue joining in the incremental fashion until a 244 user defined maximum is reached. 246 Results: 248 For each group load the result WILL display frame rate, frames 249 transmitted, total frames received, total frames loss, and percent 250 loss. The frame loss per receive port of the tester per group SHOULD also 251 be available. 253 4.3 Aggregated Multicast Throughput 255 Definition: 257 The maximum rate at which none of the offered frames to be 258 forwarded through N destination interfaces of the same multicast 259 group are dropped. 261 Procedure: 263 Multicast traffic is sent at a fixed percent of line rate with a fixed 264 number of groups at a fixed frame length for a fixed duration of time. 266 The initial number of receive ports of the tester will join the group(s) 267 and the sender will transmit to the same groups after a certain delay 268 (a few seconds). 270 Then the an incremental or decremental number of receive ports will 271 join the same groups and then the Multicast traffic is sent as stated. 273 The receive ports will continue to be added or deleted and the Multicast 274 traffic sent until a user defined maximum number of ports is reached. 276 Results: 278 For each number of receive ports the result WILL display frame rate, 279 frames transmitted, total frames received, total frames loss, and percent 280 loss. The frame loss per receive port per group SHOULD also be available. 282 4.4 Encapsulation (Tunneling) Throughput 284 This sub-section provides the description of tests that help in obtaining 285 throughput measurements when a DUT/SUT or a set of DUTs are acting as tunnel 286 endpoints. The following Figure 2 presents the 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 299 -------- 301 A tunnel is created between DUT/SUT A (the encapsulator) and DUT/SUT B (the 302 decapsulator). Client A is acting as a source and Client B is the 303 destination. Client B joins a multicast group (for example, 224.0.1.1) and it 304 sends an IGMP Join message to DUT/SUT B to join that group. Client A now 305 wants to transmit some traffic to Client B. It will send the multicast 306 traffic to DUT/SUT A which encapsulates the multicast frames, sends it to 307 DUT/SUT B which will decapsulate the same frames and forward them to Client 308 B. 310 4.4.1 Encapsulation Throughput 312 Definition 314 The maximum rate at which frames offered a DUT/SUT are encapsulated and 315 correctly forwarded by the DUT/SUT without loss. 317 Procedure 319 To test the forwarding rate of the DUT/SUT when it has to go through the 320 process of encapsulation, a test port B is injected at the other end of 321 DUT/SUT A (Figure B) that will receive the encapsulated frames and measure 322 the throughput. Also, a test port A is used to generate multicast frames that 323 will be passed through 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 DUT/SUT A as 340 the beginning of the tunnel (point c) and the IP address of DUT/SUT B as the 341 end of the tunnel (point d). DUT/SUT B is assumed to have the tunneling 342 protocol enabled so that the frames can be decapsulated. When the test port B 343 is inserted in between the DUT/SUT A and DUT/SUT B (Figure 3), the endpoint 344 of tunnel has to be re-configured to be directed to the test port B's IP 345 address. For example, in Figure 3, point c' would be assigned as the 346 beginning of the tunnel and point d' as the end of the tunnel. The test port 347 B is acting as the end of the tunnel, and it does not have to support any 348 tunneling protocol since the frames do not have to be decapsulated. Instead, 349 the received encapsulated frames are used to calculate the throughput and 350 other necessary measurements. 352 Result 354 Throughput in frames per second for each destination port. The results 355 should also contain the number of frames transmitted and received per port. 357 4.4.2 Decapsulation Throughput 359 Definition 360 The maximum rate at which frames offered a DUT/SUT are decapsulated and 361 correctly forwarded by the DUT/SUT without loss. 363 Procedure 365 The decapsulation process returns the tunneled unicast frames back to 366 their multicast format. This test measures the throughput of the DUT/SUT 367 when it has to perform the process of decapsulation, therefore, a test 368 port C is used at the end of the tunnel to receive the decapsulated 369 frames (Figure 4). 371 Test port A DUT/SUT A Test port B DUT/SUT B Test port C 373 ---------- ---------- 374 | | | | 375 -------(a) (b)| |(c) ------ (d)| |(e) (f)------- 376 ||||||| -----> | |----> |||||| ----->| |-----> ||||||| 377 ------- | | ------ | | ------- 378 | | | | 379 ---------- ---------- 381 Figure 4 382 -------- 384 In Figure 4, the encapsulation process takes place in DUT/SUT A. This may 385 effect the throughput of the DUT/SUT B. Therefore, two test ports should 386 be used to separate the encapsulation and decapsulation processes. 387 Client A is replaced with the test port A which will generate a 388 multicast frame that will be encapsulated by DUT/SUT A. Another test 389 port B is inserted between DUT/SUT A and DUT/SUT B that will receive the 390 encapsulated frames and forward it to DUT/SUT B. Test port C will 391 receive the decapsulated frames and measure the throughput. 393 Result 395 Throughput in frames per second for each destination port. The 396 results should also contain the number of frames transmitted and 397 received per port. 399 4.4.3 Re-encapsulation Throughput 401 Definition 403 The maximum rate at which frames of one encapsulated format offered 404 a DUT/SUT are converted to another encapsulated format and correctly 405 forwarded by the DUT/SUT without loss. 407 Procedure 409 Re-encapsulation takes place in DUT/SUT B after test port C has received 410 the decapsulated frames. These decapsulated frames will be re-inserted 411 with a new encapsulation frame and sent to test port B which will measure 412 the throughput. See Figure 5. 414 Test port A DUT/SUT A Test port B DUT/SUT B Test port C 416 ---------- ---------- 417 | | | | 418 -------(a) (b)| |(c) ------ (d)| |(e) (f)------- 419 ||||||| -----> | |----> |||||| <---->| |<----> ||||||| 420 ------- | | ------ | | ------- 421 | | | | 422 ---------- ---------- 424 Figure 5 425 -------- 426 Result 428 Throughput in frames per second for each destination port. The results 429 should also contain the number of frames transmitted and received per 430 port. 432 5. Forwarding Latency 434 This section presents methodologies relating to the characterization of 435 the forwarding latency of a DUT/SUT in a multicast environment. It 436 extends the concept of latency characterization presented in RFC 2544. 438 5.1 Multicast Latency 440 Definition 442 The set of individual latencies from a single input port on the DUT/SUT or 443 SUT to all tested ports belonging to the destination multicast group. 445 Procedure 447 According to RFC 2544, a tagged frame is sent half way through the 448 transmission that contains a timestamp used for calculation of latency. 449 In the multicast situation, a tagged frame is sent to all destinations 450 for each multicast group and latency calculated on a per multicast 451 group basis. Note that this test MUST be run using the transmission 452 rate that is less than the multicast throughput of the DUT/SUT. Also, 453 the test should take into account the DUT's/SUT's need to cache the 454 traffic in its IP cache, fastpath cache or shortcut tables since the 455 initial part of the traffic will be utilized to build these tables. 457 Result 458 The latency value for each multicast group address per port. An aggregate 459 latency MAY also be reported. 461 5.2 Min/Max/Average Multicast Latency 463 Definition: 465 The difference between the maximum latency measurement and the 466 minimum latency measurement from the set of latencies produced by 467 the Multicast Latency benchmark. 469 Procedure: 471 For the entire duration of the Latency test the smallest latency, the 472 largest latency, the sum of latencies, and the number should be tracked 473 per receive port of the tester. 475 The test can also increment bucket counters that represent a range latency 476 range. This can be used to create a histogram. From the histogram, 477 minimum, maximum, and average the test results can show the jitter. 479 Results: 481 For each port the results WILL display the number of frames, minimum 482 latency, maximum latency, and the average latency. The results SHOULD 483 also display the histogram of latencies. 485 6. Overhead 487 This section presents methodology relating to the characterization of 488 the overhead delays associated with explicit operations found in 489 multicast environments. 491 6.1 Group Join Delay 493 Definition: 495 The time duration it takes a DUT/SUT to start forwarding multicast 496 packets from the time a successful IGMP group membership report 497 has been issued to the DUT/SUT. 499 Procedure: 501 Traffic is sent on the source port at the same time as the IGMP JOIN 502 Group message is transmitted from the destination ports. The join 503 delay is the difference in time from when the IGMP Join is sent and 504 the first frame is received. 506 One of the keys is to transmit at the fastest rate the DUT/SUT can handle 507 multicast frames. This is to get the best resultion in the Join Delay. 508 However, you do not want to transmit the frames to fast that frames 509 are dropped by the DUT/SUT. Traffic should be sent at the throughput rate 510 determined by the forwarding tests of section 4. 512 Results: 514 The JOIN delay for each port. An error or granularity of the 515 timestamp should be reported. This granularity may be within 20 516 nanoseconds of the result. The granularity depends on the hardware 517 limitation of the tester. 519 6.2 Group Leave Delay 521 Definition 522 The time duration it takes a DUT/SUT to cease forwarding multicast packets 523 after a corresponding IGMP "Leave Group" message has been successfully 524 offered to the DUT/SUT. 526 Procedure 528 Traffic is sent on the source port at the same time as the IGMP Leave 529 Group messages are transmitted from the destination ports. The frames 530 on both the source and destination ports are sent with the timestamps 531 inserted. The Group Leave Delay is the difference in the value of the 532 timestamp A of the first IGMP Leave Group frame sent and the timestamp 533 B of the last frame that is received on that destination port. 535 Group Leave delay = timestamp B - timestamp A 537 Traffic should be sent at the throughput rate determined by the 538 forwarding tests of section 4. 540 Result 542 Group Leave Delay values for each multicast group address on each 543 destination port. Also, the number of frames transmitted and received, 544 and percent loss may be displayed. 546 7. Capacity 547 This section offers terms relating to the identification of multicast 548 group limits of a DUT/SUT. 550 7.1 Multicast Group Capacity 552 Definition: 554 The maximum number of multicast groups a DUT/SUT can support while 555 maintaining the ability to forward multicast frames to all 556 multicast groups registered to that DUT/SUT. 558 Procedure: 560 One or more receiving ports of DUT/SUT will join an initial number of 561 groups. Then after a delay the source port will transmit to each group 562 at a transmission rate that the DUT/SUT can handle. If all frames 563 sent are forwarded and received the receiving ports will join an 564 incremental value of groups. Then after a delay the source port will 565 transmit to all groups at a transmission rate that the DUT/SUT can 566 handle. If all frames sent are forwarded and received the receiving 567 ports will continuing joining and testing until a frame is not forwarded 568 nor received. 570 The group capacity resolution will be the incremental value. So the 571 capacity could be greater then last capacity passed but less then the 572 one that failed. 574 Once a capacity is determined the test should be re run with greater 575 delays after the JOIN and a slower transmission rate. And the initial 576 group level should be raised to about five less then the previous 577 capacity and incremental value should be set to one. 579 Results: 581 The number of groups passed vs the number of groups failed. The 582 results SHOULD give details when the frame fails to be forwarded 583 about how many frames did and did not get forwarded. Which groups 584 DID and DID NOT get forwarded. Also, the frame rate MAY be reported. 586 8. Interaction 587 Network forwarding devices are generally required to provide more 588 functionality than than the forwarding of traffic. Moreover, network 589 forwarding devices may be asked to provide those functions in a 590 variety of environments. This section offers terms to assist in the 591 charaterization of DUT/SUT behavior in consideration of potentially 592 interacting factors. 594 8.1 Forwarding Burdened Multicast Latency 596 The Multicast Latency metrics can be influenced by forcing the 597 DUT/SUT to perform extra processing of packets while multicast traffic is 598 being forwarded for latency measurements. In this test, a set of 599 ports on the tester will be designated to be source and destination 600 similar to the generic IP Multicast test setup. In addition to this 601 setup, another set of ports will be selected to transmit some multicast 602 traffic that is destined to multicast group addresses that have not 603 been joined by these additional set of ports. For example, if ports 1, 604 2, 3, and 4 form the burdened response setup (setup A) which is used to 605 obtain the latency metrics and ports 5, 6, 7, and 8 form the non-burdened 606 response setup (setup B) which will afflict the burdened response setup, 607 then setup B traffic will join multicast group addresses not joined by 608 the ports in this setup. By sending such multicast traffic, the DUT/SUT 609 will perform a lookup on the packets that will affect the processing of 610 setup A traffic. 612 8.2 Forwarding Burdened Group Join Delay 614 The port configuration in this test is similar to the one described in 615 section 8.1, but in this test, the multicast traffic is not sent by the 616 ports in setup B. In this test, the setup A traffic must be influenced 617 in such a way that will affect the DUT's/SUT's ability to process Group 618 Join messages. Therefore, in this test, the ports in setup B will send 619 a set of IGMP Group Join messages while the ports in setup A are also 620 joining its own set of group addresses. Since the two sets of group 621 addresses are independent of each other, the group join delay for 622 setup A may be different than in the case when there were no other 623 group addresses being joined. 625 Appendix A: Determining an even distribution 627 A.1 Scope Of This Appendix 629 This appendix discusses the suggested approach to configuring the 630 deterministic distribution methodology for tests that involve both 631 multicast and unicast traffic classes in an aggregated traffic stream. 632 As such, this appendix MUST not be read as an amendment to the 633 methodology described in the body of this document but as a guide 634 to testing practice. 636 It is important to understand and fully define the distribution of 637 frames among all multicast and unicast destinations. If the 638 distribution is not well defined or understood, the throughput and 639 forwarding metrics are not meaningful. 641 In a homogeneous environment, a large, single burst of multicast 642 frames may be followed by a large burst of unicast frames. This is a 643 very different distribution than that of a non-homogeneous 644 environment, where the multicast and unicast frames are intermingled 645 throughout the entire transmission. 647 The recommended distribution is that of the non-homogeneous 648 environment because it more closely represents a real-world 649 scenario. The distribution is modeled by calculating the number of 650 multicast frames per destination port as a burst, then calculating 651 the number of unicast frames to transmit as a percentage of the total 652 frames transmitted. The overall effect of the distribution is small 653 bursts of multicast frames intermingled with small bursts of unicast 654 frames. 656 Example 658 This example illustrates the distribution algorithm for a 100 Mbps rate. 660 Frame size = 64 661 Duration of test = 30 seconds 662 Intended Load (ILOAD) = 100% of maximum rate 663 Mapping for unicast traffic: Port 1 to Port 2 664 Port 3 to port 4 665 Mapping for multicast traffic: Port 1 to Ports 2,3,4 666 Number of Multicast group addresses per destination port = 3 667 Multicast groups joined by Port 2: 224.0.1.27 668 224.0.1.28 669 224,0.1.29 670 Multicast groups joined by Port 3: 224.0.1.30 671 224.0.1.31 672 224,0.1.32 674 Multicast groups joined by Port 4: 224.0.1.33 675 224.0.1.34 676 224,0.1.35 678 Percentage of Unicast frames = 20 679 Percentage of Multicast frames = 80 680 Total number of frames to be transmitted = 148810 fps * 30 sec 681 = 4464300 frames 682 Number of unicast frames = 20/100 * 4464300 = 892860 frames 683 Number of multicast frames = 80/100 * 4464300 = 3571440 frames 685 Unicast burst size = 20 * 9 = 180 686 Multicast burst size = 80 * 9 = 720 687 Loop counter = 4464300 / 900 = 4960.3333 (round it off to 4960) 689 Therefore, the actual number of frames that will be transmitted: 690 Unicast frames = 4960 * 180 = 892800 frames 691 Multicast frames = 4960 * 720 = 3571200 frames 693 The following pattern will be established: 695 UUUMMMMMMMMMMMMUUUMMMMMMMMMMMMUUUMMMMMMMMMMMMUUUMMMMMMMMMMMM 697 where U represents 60 Unicast frames (UUU = 180 frames) 698 M represents 60 Multicast frames (MMMMMMMMMMMM = 720 frames) 700 8. Security Considerations. 702 As this document is solely for the purpose of providing metric methodology 703 and describes neither a protocol nor a protocol's implementation, there 704 are no security considerations associated with this document. 706 9. References 708 [Br91] Bradner, S., "Benchmarking Terminology for Network 709 Interconnection Devices", RFC 1242, July 1991. 711 [Br96] Bradner, S., and J. McQuaid, "Benchmarking Methodology for 712 Network Interconnect Devices", RFC 2544, March 1999. 714 [Br97] Bradner, S. "Use of Keywords in RFCs to Reflect Requirement 715 Levels, RFC 2119, March 1997 717 [Du98] Dubray, K., "Terminology for IP Multicast Benchmarking", 718 RFC 2432, October 1998. 720 [Hu95] Huitema, C. "Routing in the Internet." Prentice-Hall, 1995. 722 [Ka98] Kosiur, D., "IP Multicasting: the Complete Guide to Interactive 723 Corporate Networks", John Wiley & Sons, Inc, 1998. 725 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching 726 Devices", RFC 2285, February 1998. 728 [Mt98] Maufer, T. "Deploying IP Multicast in the Enterprise." 729 Prentice-Hall, 1998. 731 [Se98] Semeria, C. and Maufer, T. "Introduction to IP Multicast 732 Routing." http://www.3com.com/nsc/501303.html 3Com Corp., 733 1998. 735 6. Author's Address 737 Hardev Soor 738 Ixia Communications 739 4505 Las Virgenes Road, Suite 209 740 Calabasas, CA 91302 741 USA 743 Phone: 818 871 1800 744 EMail: hardev@ixiacom.com 746 Debra Stopp 747 Ixia Communications 748 4505 Las Virgenes Road, Suite 209 749 Calabasas, CA 91302 750 USA 752 Phone: 818 871 1800 753 EMail: debby@ixiacom.com 755 Ralph Daniels 756 Netcom Systems 757 948 Loop Road 758 Clayton, NC 27520 759 USA 761 Phone: 919 550 9475 763 EMail: Ralph_Daniels@NetcomSystems.com