idnits 2.17.1 draft-ietf-bmwg-ipv6-meth-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 854. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 865. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 872. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 878. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([9]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 743 has weird spacing: '... Bytes pps...' == Line 787 has weird spacing: '... Bytes fps ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2008) is 5939 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'SA' on line 446 -- Looks like a reference, but probably isn't: 'DA' on line 446 ** Obsolete normative reference: RFC 2460 (ref. '2') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3330 (ref. '10') (Obsoleted by RFC 5735) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Popoviciu 3 Internet-Draft A. Hamza 4 Intended status: Informational G. Van de Velde 5 Expires: July 4, 2008 Cisco Systems 6 D. Dugatkin 7 IXIA 8 January 2008 10 IPv6 Benchmarking Methodology for Network Interconnect Devices 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 4, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 The Benchmarking Methodologies defined in RFC2544 [9] are IP version 45 independent. However, RFC 2544 does not address some of the 46 specificities of IPv6. This document provides additional 47 benchmarking guidelines, which in conjunction with RFC2544, lead to a 48 more complete and realistic evaluation of the IPv6 performance of 49 network interconnect devices. IPv6 transition mechanisms are outside 50 the scope of this document. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 3 56 3. Tests and Results Evaluation . . . . . . . . . . . . . . . . . 3 57 4. Test Environment Set Up . . . . . . . . . . . . . . . . . . . 4 58 5. Test Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5.1. Frame Formats and Sizes . . . . . . . . . . . . . . . . . 5 60 5.1.1. Frame Sizes to be used on Ethernet . . . . . . . . . . 5 61 5.1.2. Frame Sizes to be used on SONET . . . . . . . . . . . 6 62 5.2. Protocol Addresses Selection . . . . . . . . . . . . . . . 6 63 5.2.1. DUT Protocol Addresses . . . . . . . . . . . . . . . . 6 64 5.2.2. Test Traffic Protocol Addresses . . . . . . . . . . . 7 65 5.3. Traffic with Extension Headers . . . . . . . . . . . . . . 7 66 5.4. Traffic set up . . . . . . . . . . . . . . . . . . . . . . 9 67 6. Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.1. Management and Routing Traffic . . . . . . . . . . . . . . 9 69 6.2. Filters . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 6.2.1. Filter Format . . . . . . . . . . . . . . . . . . . . 10 71 6.2.2. Filter Types . . . . . . . . . . . . . . . . . . . . . 11 72 7. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . . 11 73 7.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 12 74 7.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 7.3. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 13 76 7.4. Back-to-Back Frames . . . . . . . . . . . . . . . . . . . 13 77 7.5. System Recovery . . . . . . . . . . . . . . . . . . . . . 13 78 7.6. Reset . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 85 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 86 Appendix A. Theoretical Maximum Frame Rates Reference . . . . . . 16 87 A.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 A.2. Packet over SONET . . . . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 90 Intellectual Property and Copyright Statements . . . . . . . . . . 20 92 1. Introduction 94 The benchmarking methodologies defined by RFC2544 [9] are proving to 95 be useful in consistently evaluating IPv4 forwarding performance of 96 network elements. Adherence to these testing and result analysis 97 procedures facilitates objective comparison of IPv4 performance data 98 measured on various products and by various individuals. While the 99 principles behind the methodologies introduced in RFC2544 are largely 100 IP version independent, the protocol continued to evolve, 101 particularly in its version 6 (IPv6). 103 This document provides benchmarking methodology recommendations that 104 address IPv6 specific aspects such as evaluating the forwarding 105 performance of traffic containing extension headers as defined in 106 RFC2460 [2]. These recommendations are defined within the RFC2544 107 framework and complement the test and result analysis procedures as 108 described in RFC2544. 110 The terms used in this document remain consistent with those defined 111 in "Benchmarking Terminology for Network Interconnect Devices" 112 RFC1242 [7]. This terminology SHOULD be consulted before using or 113 applying the recommendations of this document. 115 Any methodology aspects not covered in this document SHOULD be 116 assumed to be treated based on the RFC2544 recommendations. 118 2. Existing Definitions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in BCP 14, RFC 2119 [1]. 123 RFC 2119 defines the use of these key words to help make the intent 124 of standards track documents as clear as possible. While this 125 document uses these keywords, this document is not a standards track 126 document. 128 3. Tests and Results Evaluation 130 The recommended performance evaluation tests are described in Section 131 7 of this document. Not all of these tests are applicable to all 132 network element types. Nevertheless, for each evaluated device, it 133 is recommended to perform as many of the applicable tests described 134 in Section 6 as possible. 136 Test execution and results analysis MUST be performed while observing 137 generally accepted testing practices regarding repeatability, 138 variance and statistical significance of small numbers of trials. 140 4. Test Environment Set Up 142 The test environment setup options recommended for the IPv6 143 performance evaluation are the same as those described in Section 6 144 of RFC2544, in both single-port and multi-port scenarios. Single- 145 port testing measures per-interface forwarding performance while 146 multi-port testing measures the scalability of forwarding performance 147 across the entire platform. 149 Throughout the test, the Device Under Test (DUT) can be monitored for 150 relevant resource (Processor, Memory, etc.) utilization. This data 151 could be beneficial in understanding traffic processing by each DUT 152 and the resources that must be allocated for IPv6. It could reveal 153 if the IPv6 traffic is processed in hardware, by applicable devices, 154 under all test conditions or it is punted in the software switched 155 path. If such data is considered of interest, it MUST be collected 156 out of band and independent of any management data collected through 157 the interfaces forwarding the test traffic. 159 Note: During testing, either static or dynamic options for neighbor 160 discovery can be used. In the static case the IPv6 neighbor 161 information for the test tool is manually configured on the DUT and 162 the IPv6 neighbor information for the DUT is manually configured on 163 the test tool. In the dynamic case, the IPv6 neighbor information is 164 dynamically discovered by each device through the neighbor discovery 165 protocol. The static option can be used as long as it is supported 166 by the test tool. The dynamic option is preferred wherein the test 167 tool interacts with the DUT for the duration of the test to maintain 168 the respective neighbor caches in an active state. To avoid neighbor 169 solicitation (NS) and neighbor advertisement (NA) storms due to the 170 neighbor unreachability detection (NUD) mechanism [3], the test 171 scenarios assume test traffic simulates end points and IPv6 source 172 and destination addresses are one hop beyond the DUT. 174 5. Test Traffic 176 Traffic used for all tests described in this document SHOULD meet the 177 requirements described in this section. These requirements are 178 designed to reflect the characteristics of IPv6 unicast traffic. 179 Using the recommended IPv6 traffic profile leads to a complete 180 evaluation of the network element performance. 182 5.1. Frame Formats and Sizes 184 Two types of media are commonly deployed and each SHOULD be tested if 185 the network element supports that type of media: Ethernet and SONET. 186 This section identifies the frame sizes that SHOULD be used for each 187 media type. Refer to recommendations in RFC2544 for all other media 188 types. 190 Similar to IPv4, small frame sizes help characterize the per-frame 191 processing overhead of the DUT. Note that the minimum IPv6 packet 192 size (40 bytes) is larger than that of an IPv4 packet (20 bytes). 193 Tests should compensate for this difference. 195 The frame sizes listed for IPv6 include the extension headers used in 196 testing (see section 5.3). By definition, extension headers are part 197 of the IPv6 packet payload. Depending on the total length of the 198 extension headers, their use might not be possible at the smallest 199 frame sizes. 201 Note: Test tools are commonly using signatures to identify test 202 traffic packets to verify that there are no packet drops, out of 203 order packets or to calculate various statistics such as delay and 204 jitter. This could be the reason why the minimum frame size 205 selectable through the test tool might not be as low as the 206 theoretical one presented in this document. 208 5.1.1. Frame Sizes to be used on Ethernet 210 Ethernet in all its types has become the most commonly deployed media 211 in today's networks. The following frame sizes SHOULD be used for 212 benchmarking over this media type: 64, 128, 256, 512, 1024, 1280, 213 1518 bytes. 215 Note: The recommended 1518 bytes frame size represents the maximum 216 size of an untagged Ethernet frame. According to the IEEE 802.3as 217 standard [13], the frame size can be increased up to 2048 bytes to 218 accommodate frame tags and other encapsulation required by the IEEE 219 802.1AE MAC [14] security protocol. A frame size commonly used in 220 operational environments is 1522 bytes, max length for a VLAN-tagged 221 frame as per 802.1D [15]. 223 Note: While jumbo frames are outside the scope of the 802.3 IEEE 224 standard, tests SHOULD be executed with frame sizes selected based on 225 the values supported by the device under test. Examples of commonly 226 used jumbo frame sizes are: 4096, 8192, 9216 bytes. 228 The maximum frame rates for each frame size and the various Ethernet 229 interface types are provided in Appendix A. 231 5.1.2. Frame Sizes to be used on SONET 233 Packet over SONET (PoS) interfaces are commonly used for edge uplinks 234 and high bandwidth core links. Evaluating the forwarding performance 235 of PoS interfaces supported by the DUT is recommended. The following 236 frame sizes SHOULD be used for this media type: 47, 64, 128, 256, 237 512, 1024, 1280, 1518, 2048, 4096 bytes. 239 The theoretical maximum frame rates for each frame size and the 240 various PoS interface types are provided in Appendix A. 242 5.2. Protocol Addresses Selection 244 There are two aspects of IPv6 benchmarking testing where IP address 245 selection considerations MUST be analyzed: The selection of IP 246 addresses for the DUT and the selection of addresses for test 247 traffic. 249 5.2.1. DUT Protocol Addresses 251 IANA reserved an IPv6 address block for use with IPv6 benchmark 252 testing (see section 8). It MAY be assumed that addresses in this 253 block are not globally routable and they MUST NOT be used as Internet 254 source or destination addresses. 256 Similar to RFC2544, Appendix C, addresses from the first half of this 257 range SHOULD be used for the ports viewed as input and addresses from 258 the other half of the range for the output ports. 260 The prefix length of the IPv6 addresses configured on the DUT 261 interfaces MUST fall into either of the following: 262 o Prefix length is /126 which would simulate a point-to-point link 263 for a core router. 264 o Prefix length is smaller or equal to /64. 265 No prefix lengths SHOULD be selected in the range between 64 and 128 266 except the 126 value mentioned above. 268 Note that /126 prefixes might not be always the best choice for 269 addressing point-to-point links such as back-to-back Ethernet unless 270 the autoprovisioning mechanism is disabled. Also, not all network 271 elements support addresses of this prefix length. 273 While with IPv6, the DUT interfaces can be configured with multiple 274 global unicast addresses, the methodology described in this document 275 does not require testing such a scenario. It is not expected that 276 such an evaluation would bring additional data regarding the 277 performance of the network element. 279 The Interface ID portion of global unicast IPv6 DUT addresses SHOULD 280 be set to ::1. There are no requirements in the selection of the 281 Interface ID portion of the link local IPv6 addresses. 283 It is recommended that multiple iterations of the benchmark tests be 284 conducted using the following prefix lengths: 48, 64, 126 and 128 for 285 the advertised traffic destination prefix. Other prefix lengths can 286 be used. However the indicated range reflects major prefix 287 boundaries expected to be present in IPv6 routing tables and they 288 should be representative to establish baseline performance metrics. 290 5.2.2. Test Traffic Protocol Addresses 292 IPv6 source and destination addresses for the test streams SHOULD 293 belong to the IPv6 range assigned by IANA as defined in section 8. 294 The source addresses SHOULD belong to one half of the range and the 295 destination addresses to the other, reflecting the DUT interface IPv6 296 address selection. 298 Tests SHOULD first be executed with a single stream leveraging a 299 single source-destination address pair. The tests SHOULD then be 300 repeated with traffic using a random destination address in the 301 corresponding range. If the network element prefix lookup 302 capabilities are evaluated, the tests SHOULD focus on the IPv6 303 relevant prefix boundaries: 0-64, 126 and 128. 305 Note: When statically defined neighbors are not used, the parameters 306 affecting Neighbor Unreachability Detection should be consistently 307 set. The IPv6 prefix reachable time in the router advertisement 308 SHOULD be set to 30 seconds. 310 5.3. Traffic with Extension Headers 312 Extension headers are an intrinsic part of the IPv6 architecture [2]. 313 They are used with various types of practical traffic such as: 314 fragmented traffic, mobile IP based traffic, authenticated and 315 encrypted traffic. For these reasons, all tests described in this 316 document SHOULD be performed with both traffic that has no extension 317 headers and traffic that has a set of extension headers. Extension 318 header types can be selected from the following list [2] which 319 reflects the recommended order of multiple extension headers in a 320 packet: 321 o Hop-by-hop header 322 o Destination options header 323 o Routing header 324 o Fragment header 325 o Authentication header 326 o Encapsulating security payload (ESP) header 327 o Destination options header 328 o Mobility header 330 Since extension headers are an intrinsic part of the protocol and 331 that they fulfill different roles, benchmarking of traffic containing 332 each extension header SHOULD be executed individually. 334 The special processing rules for the hop-by-hop extension header 335 require a specific benchmarking approach. Unlike other extension 336 headers, this header must be processed by each node that forwards the 337 traffic. Tests with traffic containing these extension header types 338 will not measure the forwarding performance of the DUT, but rather 339 its extension header processing capability, which is dependent on the 340 information contained in the extension headers. The concern is that 341 this traffic, at high rates, could have a negative impact on the 342 operational resources of the router and could be used as a security 343 threat. When benchmarking with traffic that contains the hop-by-hop 344 extension header, the goal is not to measure throughput [9] as in the 345 case of the other extension headers, but rather to evaluate the 346 impact of such traffic on the router. In this case, traffic with the 347 hop-by-hop extension headers should be sent at 1%, 10% and 50% of the 348 interface total bandwidth. Device resources must be monitored at 349 each traffic rate to determine the impact. 351 Tests with traffic containing each individual extension header MUST 352 be complemented with tests containing a chain of two or more 353 extension headers (the chain MUST NOT contain the hop-by-hop 354 extension header). This chain should also exclude the ESP [6] 355 extension header since traffic with an encrypted payload can not be 356 used in tests with modifiers such as filters based on upper layer 357 information (see Section 5). Since the DUT is not analyzing the 358 content of the extension headers, any combination of extension 359 headers can be used in testing. The extension header chain 360 recommended for testing is: 361 o Routing header - 24-32 bytes 362 o Destination options header - 8 bytes 363 o Fragment header - 8 bytes 365 This is a real life extension header chain that would be found in an 366 IPv6 packet between two mobile nodes exchanged over an optimized path 367 that requires fragmentation. The listed extension headers lengths 368 represent test tool defaults. The total length of the extension 369 header chain SHOULD be larger than 32 bytes. 371 Extension headers add extra bytes to the payload size of the IP 372 packets which MUST be factored in when used in testing at low frame 373 sizes. Their presence will modify the minimum packet size used in 374 testing. For direct comparison between the data obtained with 375 traffic that has extension headers and with traffic that doesn't have 376 them at low frame size, a common value SHOULD be selected for the 377 smallest frame size of both types of traffic. 379 For most cases, the network elements ignore the extension headers 380 when forwarding IPv6 traffic. For these reasons it is likely the 381 performance impact related to extension headers will be observed only 382 when testing the DUT with traffic filters that contain matching 383 conditions for the upper layer protocol information. In those cases, 384 the DUT MUST traverse the chain of extension headers, a process that 385 could impact performance. 387 5.4. Traffic set up 389 All tests recommended in this document SHOULD be performed with bi- 390 directional traffic. For asymmetric situations, tests MAY be 391 performed with unidirectional traffic for a more granular 392 characterization of the DUT performance. In these cases, the 393 bidirectional traffic testing would reveal only the lowest 394 performance between the two directions. 396 All other traffic profile characteristics described in RFC2544 SHOULD 397 be applied in this testing as well. IPv6 multicast benchmarking is 398 outside the scope of this document. 400 6. Modifiers 402 RFC2544 underlines the importance of evaluating the performance of 403 network elements under certain operational conditions. The 404 conditions defined in RFC2544 section 11 are common to IPv4 and IPv6, 405 except that IPv6 does not employ layer 2 or 3 broadcast frames. IPv6 406 does not use layer 2 or layer 3 broadcasts. This section provides 407 additional conditions that are specific to IPv6. The suite of tests 408 recommended in this document SHOULD be first executed in the absence 409 of these conditions and then repeated under each of these conditions 410 separately. 412 6.1. Management and Routing Traffic 414 The procedures defined in RFC2544 sections 11.2 and 11.3 are 415 applicable for IPv6 management and routing update frames as well. 417 6.2. Filters 419 The filters defined in Section 11.4 of RFC2544 apply to IPv6 420 benchmarking as well. The filter definitions must be expanded to 421 include upper layer protocol information matching in order to analyze 422 the handling of traffic with extension headers which are an important 423 architectural component of IPv6. 425 6.2.1. Filter Format 427 The filter format defined in RFC2544 is applicable to IPv6 as well 428 except that the source addresses (SA) and destination addresses (DA) 429 are IPv6 addresses. In addition to these basic filters, the 430 evaluation of IPv6 performance SHOULD analyze the correct filtering 431 and handling of traffic with extension headers. 433 While the intent is not to evaluate a platform's capability to 434 process the various extension header types, the goal is to measure 435 performance impact when the network element must parse through the 436 extension headers to reach upper layer information. In IPv6, routers 437 do not have to parse through the extension headers (other than hop- 438 by-hop) unless, for example, upper layer information has to be 439 analyzed due to filters. 441 To evaluate the network element handling of IPv6 traffic with 442 extension headers, the definition of the filters must be extended to 443 include conditions applied to upper layer protocol information. The 444 following filter format SHOULD be used for this type of evaluation: 446 [permit|deny] [protocol] [SA] [DA] 448 where permit or deny indicates the action to allow or deny a packet 449 through the interface the filter is applied to. The protocol field 450 is defined as: 451 o ipv6: any IP Version 6 traffic 452 o tcp: Transmission Control Protocol 453 o udp: User Datagram Protocol 454 and SA stands for the source address and DA for the destination 455 address. 457 The upper layer protocols listed above are a recommended selection. 458 However, they do not represent an all-inclusive list of upper layer 459 protocols which could be used in defining filters. The filters 460 described in these benchmarking recommendations apply to native IPv6 461 traffic and upper layer protocols (tcp, udp) transported in native 462 IPv6 packets. 464 6.2.2. Filter Types 466 Based on RFC2544 recommendations, two types of tests are executed 467 when evaluating performance in the presence of modifiers: One with a 468 single filter and another with 25 filters. Examples of recommended 469 filters are illustrated using the IPv6 documentation prefix [11] 470 2001:DB8::. 472 Examples of single filters are: 474 Filter for TCP traffic - permit tcp 2001:DB8::1 2001:DB8::2 475 Filter for UDP traffic - permit udp 2001:DB8::1 2001:DB8::2 476 Filter for IPv6 traffic - permit ipv6 2001:DB8::1 2001:DB8::2 478 The single line filter case SHOULD verify that the network element 479 permits all TCP/UDP/IPv6 traffic with or without any number of 480 extension headers from IPv6 SA 2001:DB8::1 to IPv6 DA 2001:DB8::2 and 481 deny all other traffic. 483 Example of 25 filters: 485 deny tcp 2001:DB8:1::1 2001:DB8:1::2 486 deny tcp 2001:DB8:2::1 2001:DB8:2::2 487 deny tcp 2001:DB8:3::1 2001:DB8:3::2 488 ... 489 deny tcp 2001:DB8:C::1 2001:DB8:C::2 490 permit tcp 2001:DB8:99::1 2001:DB8:99::2 491 deny tcp 2001:DB8:D::1 2001:DB8:D::2 492 deny tcp 2001:DB8:E::1 2001:DB8:E::2 493 ... 494 deny tcp 2001:DB8:19::1 2001:DB8:19::2 495 deny ipv6 any any 497 The router SHOULD deny all traffic with or without extension headers 498 except TCP traffic with SA 2001:DB8:99::1 and DA 2001:DB8:99::2. 500 7. Benchmarking Tests 502 This document recommends the same benchmarking tests described in 503 RFC2544 while observing the DUT setup and the traffic setup 504 considerations described above. The following sections state the 505 test types explicitly and highlight only the methodology differences 506 that might exist with respect to those described in Section 26 of 507 RFC2544. 509 The specificities of IPv6, particularly the definition of extension 510 headers processing, require additional benchmarking steps. The tests 511 recommended by RFC2544 MUST be repeated for IPv6 traffic without 512 extension headers and for IPv6 traffic with one or multiple extension 513 headers. 515 IPv6's deployment in existing IPv4 environments and the expected long 516 co-existence of the two protocols leads network operators to place 517 great emphasis on understanding the performance of platforms 518 processing both types of traffic. While device resources are shared 519 between the two protocols, it is important that IPv6-enabled 520 platforms not experience degraded IPv4 performance. Thus, IPv6 521 benchmarking SHOULD be performed in the context of a stand alone 522 protocol as well as in the context of its co-existence with IPv4. 524 The modifiers defined are independent of extension header type so 525 they can be applied equally to each one of the above tests. 527 The benchmarking tests described in this section SHOULD be performed 528 under each of the following conditions: 530 Extension header specific conditions: 531 i) IPv6 traffic with no extension headers 532 ii) IPv6 traffic with one extension header from the list in 533 section 5.3 534 iii) IPv6 traffic with the chain of extension headers described in 535 section 5.3 537 Co-existence specific conditions: 538 iv) IPv4 ONLY traffic benchmarking 539 v) IPv6 ONLY traffic benchmarking 540 vi) IPv4-IPv6 traffic mix with the ratio 90% vs 10% 541 vii) IPv4-IPv6 traffic mix with the ratio 50% vs 50% 542 viii) IPv4-IPv6 traffic mix with the ratio 10% vs 90% 544 Combining the test conditions listed for benchmarking IPv6 as a 545 stand-alone protocol and the co-existence tests leads to a large 546 coverage matrix. At a minimum requirement, the co-existence tests 547 should use IPv6 traffic with no extension headers and the 10%-90%, 548 90%-10% IPv4/IPv6 traffic mix. 550 The subsequent sections each describe specific tests that MUST be 551 executed under the conditions listed above for a complete 552 benchmarking of IPv6 forwarding performance. 554 7.1. Throughput 556 Objective: To determine the DUT throughput as defined in RFC1242. 558 Procedure: Same as RFC2544. 560 Reporting Format: Same as RFC2544. 562 7.2. Latency 564 Objective: To determine the latency as defined in RFC1242. 566 Procedure: Same as RFC2544. 568 Reporting Format: Same as RFC2544. 570 7.3. Frame Loss 572 Objective: To determine the frame loss rate, as defined in RFC1242, 573 of a DUT throughout the entire range of input data rates and frame 574 sizes. 576 Procedure: Same as RFC2544. 578 Reporting Format: Same as RFC2544. 580 7.4. Back-to-Back Frames 582 Based on the IPv4 experience, the back-to-back frames test is 583 characterized by significant variance due to short term variations in 584 the processing flow. For these reasons, this test is no longer 585 recommended for IPv6 benchmarking. 587 7.5. System Recovery 589 Objective: To characterize the speed at which a DUT recovers from an 590 overload condition. 592 Procedure: Same as RFC2544. 594 Reporting Format: Same as RFC2544. 596 7.6. Reset 598 Objective: To characterize the speed at which a DUT recovers from a 599 device or software reset. 601 Procedure: Same as RFC2544. 603 Reporting Format: Same as RFC2544. 605 8. IANA Considerations 607 The IANA was instructed to allocate for IPv6 benchmarking a 48 bits 608 prefix from the RFC 4773 pool. This allocation is similar to 609 198.18.0.0/15 defined in RFC 3330 [10]. This prefix length (48) 610 provides similar flexibility as the range allocated for IPv4 611 benchmarking and it is taking into consideration address conservation 612 and simplicity of usage concerns. The requested size meets the 613 requirements for testing large network elements and large emulated 614 networks. 616 Note: Similar to RFC 2544 avoiding the use of RFC 1918 address space 617 for benchmarking tests, this document does not recommend the use of 618 RFC 4193 [5] (Unique Local Addresses) in order to minimize the 619 possibility of conflicts with operational traffic. 621 9. Security Considerations 623 Benchmarking activities as described in this memo are limited to 624 technology characterization using controlled stimuli in a laboratory 625 environment, with dedicated address space and the constraints 626 specified in the sections above. 628 The benchmarking network topology will be an independent test setup 629 and MUST NOT be connected to devices that may forward the test 630 traffic into a production network, or misroute traffic to the test 631 management network. 633 Further, benchmarking is performed on a "black-box" basis, relying 634 solely on measurements observable external to the DUT/SUT. 636 Special capabilities SHOULD NOT exist in the DUT/SUT specifically for 637 benchmarking purposes. Any implications for network security arising 638 from the DUT/SUT SHOULD be identical in the lab and in production 639 networks. 641 The isolated nature of the benchmarking environments and the fact 642 that no special features or capabilities, other than those used in 643 operational networks, are enabled on the DUT/SUT requires no security 644 considerations specific to the benchmarking process. 646 10. Conclusions 648 The Benchmarking Methodology for Network Interconnect Devices 649 document, RFC2544 [9], is for the most part applicable to evaluating 650 the IPv6 performance of network elements. This document addresses 651 the IPv6 specific requirements that MUST be observed when applying 652 the recommendations of RFC2544. These additional requirements stem 653 from the architecture characteristics of IPv6. This document is not 654 a replacement of but a complement to RFC2544. 656 11. Acknowledgements 658 Scott Bradner provided valuable guidance and recommendations for this 659 document. The authors acknowledge the work done by Cynthia Martin 660 and Jeff Dunn with respect to defining the terminology for IPv6 661 benchmarking. The authors would like to thank Bill Kine for his 662 contribution to the initial document and to Tom Alexander, Bill 663 Cerveny, Silvija Dry, Sven Lanckmans, Dean Lee, Athanassios 664 Liakopoulos, Benoit Lourdelet, Al Morton, David Newman, Rajiv 665 Papejna, Dan Romascanu and Pekka Savola for their very helpful 666 feedback. Maryam Hamza inspired the authors in completing this 667 document. 669 12. References 671 12.1. Normative References 673 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 674 Levels", BCP 14, RFC 2119, March 1997. 676 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 677 Specification", RFC 2460, December 1998. 679 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 680 for IP Version 6 (IPv6)", RFC 2461, December 1998. 682 [4] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, 683 June 1999. 685 [5] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 686 Addresses", RFC 4193, October 2005. 688 [6] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 689 December 2005. 691 12.2. Informative References 693 [7] Bradner, S., "Benchmarking terminology for network 694 interconnection devices", RFC 1242, July 1991. 696 [8] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, 697 July 1994. 699 [9] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 700 Network Interconnect Devices", RFC 2544, March 1999. 702 [10] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. 704 [11] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 705 Reserved for Documentation", RFC 3849, July 2004. 707 [12] Newman, D. and T. Player, "Hash and Stuffing: Overlooked 708 Factors in Network Device Benchmarking", RFC 4814, March 2007. 710 [13] LAN/MAN Standards Committee of the IEEE Computer Society, "IEEE 711 Std 802.3as-2006, Part 3: Carrier Sense Multiple Access with 712 Collision Detection (CSMA/CD) Access Method and Physical Layer 713 Specifications, Amendment 3: Frame format extensions", 714 November 2006. 716 [14] Allyn Romanow (editor), "IEEE Std 802.3ae, Media Access Control 717 (MAC) Security", June 2006. 719 [15] Mick Seaman (editor), "IEEE Std 802.1D-2004, MAC Bridges", 720 February 2004. 722 Appendix A. Theoretical Maximum Frame Rates Reference 724 This appendix provides the formulas to calculate and the values for 725 the theoretical maximum frame rates for two media types: Ethernet and 726 SONET. 728 A.1. Ethernet 730 The throughput in frames per second (fps) for various Ethernet 731 interface types and for a frame size X can be calculated with the 732 following formula: 734 Line Rate (bps) 735 ------------------------------ 736 (8bits/byte)*(X+20)bytes/frame 738 The 20 bytes in the formula is the sum of the preamble (8 bytes) and 739 the inter frame gap (12 bytes). The throughput for various Ethernet 740 interface types and frame sizes: 742 Size 10Mb/s 100Mb/s 1000Mb/s 10000Mb/s 743 Bytes pps pps pps pps 745 64 14,880 148,809 1,488,095 14,880,952 746 128 8,445 84,459 844,594 8,445,945 747 256 4,528 45,289 452,898 4,528,985 748 512 2,349 23,496 234,962 2,349,624 749 1024 1,197 11,973 119,731 1,197,318 750 1280 961 9,615 96,153 961,538 751 1518 812 8,127 81,274 812,743 752 1522 810 8,106 81,063 810,635 753 2048 604 6,044 60,444 604,448 754 4096 303 3,036 30,396 303,691 755 8192 152 1,522 15,221 152,216 756 9216 135 1,353 13,534 135,339 758 Note: Ethernet's maximum frame rates are subject to variances due to 759 clock slop. The listed rates are theoretical maximums and actual 760 tests should account for a +/- 100 ppm tolerance. 762 A.2. Packet over SONET 764 ANSI T1.105 SONET provides the formula for calculating the maximum 765 available bandwidth for the various Packet over SONET (PoS) interface 766 types: 768 STS-Nc (N = 3Y, where Y=1,2,3,etc) 770 [(N*87) - N/3]*(9 rows)*(8 bit/byte)*(8000 frames/sec) 772 Packets over SONET can use various encapsulations: PPP [4], HDLC [8] 773 and Frame Relay. All these encapsulations use a 4-byte header, a 2- 774 or 4-byte FCS field and a 1-byte Flag which are all accounted for in 775 the overall frame size. The maximum frame rate for various interface 776 types can be calculated with the formula (where X represents the 777 frame size in bytes): 779 Line Rate (bps) 780 ------------------------------ 781 (8bits/byte)*(X+1)bytes/frame 783 The theoretical maximum frame rates for various PoS interface types 784 and frame sizes: 786 Size OC-3c OC-12c OC-48c OC-192c OC-768c 787 Bytes fps fps fps fps fps 789 47 390,000 1,560,000 6,240,000 24,960,000 99,840,000 790 64 288,000 1,152,000 4,608,000 18,432,000 73,728,000 791 128 145,116 580,465 2,321,860 9,287,441 37,149,767 792 256 72,840 291,361 1,165,447 4,661,789 18,647,159 793 512 36,491 145,964 583,859 2,335,438 9,341,754 794 1024 18,263 73,053 292,214 1,168,858 4,675,434 795 2048 9,136 36,544 146,178 584,714 2,338,857 796 4096 4,569 18,276 73,107 292,428 1,169,714 798 It is important to note that throughput test results may vary from 799 the values presented in appendices A.1 and A.2 due to bit stuffing 800 performed by various media types [12]. The theoretical throughput 801 numbers were rounded down. 803 Authors' Addresses 805 Ciprian Popoviciu 806 Cisco Systems 807 Kit Creek Road 808 RTP, North Carolina 27709 809 USA 811 Phone: 919 787 8162 812 Email: cpopovic@cisco.com 814 Ahmed Hamza 815 Cisco Systems 816 3000 Innovation Drive 817 Kanata K2K 3E8 818 Canada 820 Phone: 613 254 3656 821 Email: ahamza@cisco.com 822 Gunter Van de Velde 823 Cisco Systems 824 De Kleetlaan 6a 825 Diegem 1831 826 Belgium 828 Phone: +32 2704 5473 829 Email: gunter@cisco.com 831 Diego Dugatkin 832 IXIA 833 26601 West Agoura Rd 834 Calabasas 91302 835 USA 837 Phone: 818 444 3124 838 Email: diego@ixiacom.com 840 Full Copyright Statement 842 Copyright (C) The IETF Trust (2008). 844 This document is subject to the rights, licenses and restrictions 845 contained in BCP 78, and except as set forth therein, the authors 846 retain all their rights. 848 This document and the information contained herein are provided on an 849 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 850 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 851 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 852 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 853 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 854 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 856 Intellectual Property 858 The IETF takes no position regarding the validity or scope of any 859 Intellectual Property Rights or other rights that might be claimed to 860 pertain to the implementation or use of the technology described in 861 this document or the extent to which any license under such rights 862 might or might not be available; nor does it represent that it has 863 made any independent effort to identify any such rights. Information 864 on the procedures with respect to rights in RFC documents can be 865 found in BCP 78 and BCP 79. 867 Copies of IPR disclosures made to the IETF Secretariat and any 868 assurances of licenses to be made available, or the result of an 869 attempt made to obtain a general license or permission for the use of 870 such proprietary rights by implementers or users of this 871 specification can be obtained from the IETF on-line IPR repository at 872 http://www.ietf.org/ipr. 874 The IETF invites any interested party to bring to its attention any 875 copyrights, patents or patent applications, or other proprietary 876 rights that may cover technology that may be required to implement 877 this standard. Please address the information to the IETF at 878 ietf-ipr@ietf.org. 880 Acknowledgment 882 Funding for the RFC Editor function is provided by the IETF 883 Administrative Support Activity (IASA).