idnits 2.17.1 draft-ietf-bmwg-ipv6-meth-04.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 830. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 841. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 848. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 854. 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 ([8]), 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 720 has weird spacing: '... Bytes pps...' == Line 763 has weird spacing: '... Bytes fps ...' == 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 'SHOULD not' in this paragraph: Special care needs to be taken about the neighbor unreachability detection (NUD) [3] process. The IPv6 prefix reachable time in the router advertisement SHOULD be set to 30 seconds and allow 50% jitter. The IPv6 source and destination addresses SHOULD not appear to be directly connected to the DUT to avoid neighbor solicitation (NS) and neighbor advertisement (NA) storms due to multiple test traffic flows. == 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: Tests with traffic containing each individual extension header MUST be complemented with tests containing a chain of two or more extension headers (the chain MUST not contain the hop-by-hop extension header). This chain should also exclude the ESP [5] extension header since traffic with an encrypted payload can not be used in tests with modifiers such as filters based on upper layer information (see Section 5). Since the DUT is not analyzing the content of the extension headers, any combination of extension headers can be used in testing. The extension header chain recommended for testing is: o Routing header - 24-32 bytes o Destination options header - 8 bytes o Fragment header - 8 bytes -- 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 8, 2007) is 6039 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'SA' on line 441 -- Looks like a reference, but probably isn't: 'DA' on line 441 ** 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. '9') (Obsoleted by RFC 5735) Summary: 4 errors (**), 0 flaws (~~), 6 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: April 10, 2008 Cisco Systems 6 D. Dugatkin 7 IXIA 8 October 8, 2007 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 April 10, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 The Benchmarking Methodologies defined in RFC2544 [8] 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 . . . . . . . . . . . . . . . . . 4 60 5.1.1. Frame Sizes to be used on Ethernet . . . . . . . . . . 5 61 5.1.2. Frame Sizes to be used on SONET . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6.2.1. Filter Format . . . . . . . . . . . . . . . . . . . . 9 71 6.2.2. Filter Types . . . . . . . . . . . . . . . . . . . . . 10 72 7. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . . 11 73 7.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 12 74 7.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 7.3. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 12 76 7.4. Back-to-Back Frames . . . . . . . . . . . . . . . . . . . 13 77 7.5. System Recovery . . . . . . . . . . . . . . . . . . . . . 13 78 7.6. Reset . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 85 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 86 Appendix A. Theoretical Maximum Frame Rates Reference . . . . . . 15 87 A.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 A.2. Packet over SONET . . . . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 90 Intellectual Property and Copyright Statements . . . . . . . . . . 19 92 1. Introduction 94 The benchmarking methodologies defined by RFC2544 [8] 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 [6]. 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 DUT can be monitored for relevant resource 150 (Processor, Memory, etc.) utilization. This data could be beneficial 151 in understanding traffic processing by each DUT and the resources 152 that must be allocated for IPv6. It could reveal if the IPv6 traffic 153 is processed in hardware, by applicable devices, under all test 154 conditions or it is punted in the software switched path. If such 155 data is considered of interest, it MUST be collected out of band and 156 independent of any management data collected through the interfaces 157 forwarding the test traffic. 159 Note: During testing, either static or dynamic options for neighbor 160 discovery can be used. The static option can be used as long as it 161 is supported by the test tool. The dynamic option is preferred 162 wherein the test tool interacts with the DUT for the duration of the 163 test to maintain the respective neighbor caches in an active state. 164 To avoid neighbor solicitation (NS) and neighbor advertisement (NA) 165 storms due to the neighbor unreachability detection (NUD) mechanism 166 [3], the test scenarios assume test traffic simulates end points and 167 IPv6 source and destination addresses are one hop beyond the DUT. 169 5. Test Traffic 171 Traffic used for all tests described in this document SHOULD meet the 172 requirements described in this section. These requirements are 173 designed to reflect the characteristics of IPv6 unicast traffic. 174 Using the recommended IPv6 traffic profile leads to a complete 175 evaluation of the network element performance. 177 5.1. Frame Formats and Sizes 179 Two types of media are commonly deployed and each SHOULD be tested if 180 the network element supports that type of media: Ethernet and SONET. 181 This section identifies the frame sizes that SHOULD be used for each 182 media type. Refer to recommendations in RFC2544 for all other media 183 types. 185 Similar to IPv4, small frame sizes help characterize the per-frame 186 processing overhead of the DUT. Note that the minimum IPv6 packet 187 size (40 bytes) is larger than that of an IPv4 packet (20 bytes). 188 Tests should compensate for this difference. 190 The frame sizes listed for IPv6 include the extension headers used in 191 testing (see section 5.3). By definition, extension headers are part 192 of the IPv6 packet payload. Depending on the total length of the 193 extension headers, their use might not be possible at the smallest 194 frame sizes. 196 Note: Test tools are commonly using signatures to identify test 197 traffic packets to verify that there are no packet drops, out of 198 order packets or to calculate various statistics such as delay and 199 jitter. This could be the reason why the minimum frame size 200 selectable through the test tool might not be as low as the 201 theoretical one presented in this document. 203 5.1.1. Frame Sizes to be used on Ethernet 205 Ethernet in all its types has become the most commonly deployed media 206 in today's networks. The following frame sizes SHOULD be used for 207 benchmarking over this media type: 64, 128, 256, 512, 1024, 1280, 208 1518 bytes. 210 Note: The recommended 1518 bytes frame size represents the maximum 211 size of an untagged Ethernet frame. According to the IEEE 802.3as 212 standard [12], the frame size can be increased up to 2048 bytes to 213 accommodate frame tags. 215 Note: While jumbo frames are outside the scope of the 802.3 IEEE 216 standard, tests SHOULD be executed with frame sizes selected based on 217 the values supported by the device under test. Examples of commonly 218 used jumbo frame sizes are: 4096, 8192, 9216 bytes. 220 The maximum frame rates for each frame size and the various Ethernet 221 interface types are provided in Appendix A. 223 5.1.2. Frame Sizes to be used on SONET 225 Packet over SONET (PoS) interfaces are commonly used for edge uplinks 226 and high bandwidth core links. Evaluating the forwarding performance 227 of PoS interfaces supported by the DUT is recommended. The following 228 frame sizes SHOULD be used for this media type: 47, 64, 128, 256, 229 512, 1024, 1280, 1518, 2048, 4096 bytes. 231 The theoretical maximum frame rates for each frame size and the 232 various PoS interface types are provided in Appendix A. 234 5.2. Protocol Addresses Selection 236 There are two aspects of IPv6 benchmarking testing where IP address 237 selection considerations MUST be analyzed: The selection of IP 238 addresses for the DUT and the selection of addresses for test 239 traffic. 241 5.2.1. DUT Protocol Addresses 243 IANA reserved an IPv6 address block for use with IPv6 benchmark 244 testing (see section 8). It MAY be assumed that addresses in this 245 block are not globally routable and they MUST NOT be used as Internet 246 source or destination addresses. 248 Similar to RFC2544, Appendix C, addresses from the first half of this 249 range SHOULD be used for the ports viewed as input and addresses from 250 the other half of the range for the output ports. 252 The prefix length of the IPv6 addresses configured on the DUT 253 interfaces MUST fall into either of the following: 254 o Prefix length is /126 which would simulate a point-to-point link 255 for a core router. 256 o Prefix length is smaller or equal to /64. 257 No prefix lengths SHOULD be selected in the range between 64 and 128 258 except the 126 value mentioned above. 260 Note that /126 prefixes might not be always the best choice for 261 addressing point-to-point links such as back-to-back Ethernet unless 262 the autoprovisioning mechanism is disabled. Also, not all network 263 elements support addresses of this prefix length. 265 While with IPv6, the DUT interfaces can be configured with multiple 266 global unicast addresses, the methodology described in this document 267 does not require testing such a scenario. It is not expected that 268 such an evaluation would bring additional data regarding the 269 performance of the network element. 271 The Interface ID portion of global unicast IPv6 DUT addresses SHOULD 272 be set to ::1. There are no requirements in the selection of the 273 Interface ID portion of the link local IPv6 addresses. 275 It is recommended that multiple iterations of the benchmark tests be 276 conducted using the following prefix lengths: 48, 64, 126 and 128 for 277 the advertised traffic destination prefix. Other prefix lengths can 278 be used. However the indicated range reflects major prefix 279 boundaries expected to be present in IPv6 routing tables and they 280 should be representative to establish baseline performance metrics. 282 5.2.2. Test Traffic Protocol Addresses 284 IPv6 source and destination addresses for the test streams SHOULD 285 belong to the IPv6 range assigned by IANA as defined in section 8. 286 The source addresses SHOULD belong to one half of the range and the 287 destination addresses to the other, reflecting the DUT interface IPv6 288 address selection. 290 Tests SHOULD first be executed with a single stream leveraging a 291 single source-destination address pair. The tests SHOULD then be 292 repeated with traffic using a random destination address in the 293 corresponding range. If the network element prefix lookup 294 capabilities are evaluated, the tests SHOULD focus on the IPv6 295 relevant prefix boundaries: 0-64, 126 and 128. 297 Special care needs to be taken about the neighbor unreachability 298 detection (NUD) [3] process. The IPv6 prefix reachable time in the 299 router advertisement SHOULD be set to 30 seconds and allow 50% 300 jitter. The IPv6 source and destination addresses SHOULD not appear 301 to be directly connected to the DUT to avoid neighbor solicitation 302 (NS) and neighbor advertisement (NA) storms due to multiple test 303 traffic flows. 305 5.3. Traffic with Extension Headers 307 Extension headers are an intrinsic part of the IPv6 architecture [2]. 308 They are used with various types of practical traffic such as: 309 fragmented traffic, mobile IP based traffic, authenticated and 310 encrypted traffic. For these reasons, all tests described in this 311 document SHOULD be performed with both traffic that has no extension 312 headers and traffic that has a set of extension headers. Extension 313 header types can be selected from the following list [2] which 314 reflects the recommended order of multiple extension headers in a 315 packet: 316 o Hop-by-hop header 317 o Destination options header 318 o Routing header 319 o Fragment header 320 o Authentication header 321 o Encapsulating security payload (ESP) header 322 o Destination options header 323 o Mobility header 325 Since extension headers are an intrinsic part of the protocol and 326 that they fulfill different roles, benchmarking of traffic containing 327 each extension header SHOULD be executed individually. 329 The special processing rules for the hop-by-hop extension header 330 require a specific benchmarking approach. Unlike other extension 331 headers, this header must be processed by each node that forwards the 332 traffic. Tests with traffic containing these extension header types 333 will not measure the forwarding performance of the DUT, but rather 334 its extension header processing capability, which is dependent on the 335 information contained in the extension headers. The concern is that 336 this traffic, at high rates, could have a negative impact on the 337 operational resources of the router and could be used as a security 338 threat. When benchmarking with traffic that contains the hop-by-hop 339 extension header, the goal is not to measure throughput [8] as in the 340 case of the other extension headers, but rather to evaluate the 341 impact of such traffic on the router. In this case, traffic with the 342 hop-by-hop extension headers should be sent at 1%, 10% and 50% of the 343 interface total bandwidth. Device resources must be monitored at 344 each traffic rate to determine the impact. 346 Tests with traffic containing each individual extension header MUST 347 be complemented with tests containing a chain of two or more 348 extension headers (the chain MUST not contain the hop-by-hop 349 extension header). This chain should also exclude the ESP [5] 350 extension header since traffic with an encrypted payload can not be 351 used in tests with modifiers such as filters based on upper layer 352 information (see Section 5). Since the DUT is not analyzing the 353 content of the extension headers, any combination of extension 354 headers can be used in testing. The extension header chain 355 recommended for testing is: 356 o Routing header - 24-32 bytes 357 o Destination options header - 8 bytes 358 o Fragment header - 8 bytes 360 This is a real life extension header chain that would be found in an 361 IPv6 packet between two mobile nodes exchanged over an optimized path 362 that requires fragmentation. The listed extension headers lengths 363 represent test tool defaults. The total length of the extension 364 header chain SHOULD be larger than 32 bytes. 366 Extension headers add extra bytes to the payload size of the IP 367 packets which MUST be factored in when used in testing at low frame 368 sizes. Their presence will modify the minimum packet size used in 369 testing. For direct comparison between the data obtained with 370 traffic that has extension headers and with traffic that doesn't have 371 them at low frame size, a common value SHOULD be selected for the 372 smallest frame size of both types of traffic. 374 For most cases, the network elements ignore the extension headers 375 when forwarding IPv6 traffic. For these reasons it is likely the 376 performance impact related to extension headers will be observed only 377 when testing the DUT with traffic filters that contain matching 378 conditions for the upper layer protocol information. In those cases, 379 the DUT MUST traverse the chain of extension headers, a process that 380 could impact performance. 382 5.4. Traffic set up 384 All tests recommended in this document SHOULD be performed with bi- 385 directional traffic. For asymmetric situations, tests MAY be 386 performed with unidirectional traffic for a more granular 387 characterization of the DUT performance. In these cases, the 388 bidirectional traffic testing would reveal only the lowest 389 performance between the two directions. 391 All other traffic profile characteristics described in RFC2544 SHOULD 392 be applied in this testing as well. IPv6 multicast benchmarking is 393 outside the scope of this document. 395 6. Modifiers 397 RFC2544 underlines the importance of evaluating the performance of 398 network elements under certain operational conditions. The 399 conditions defined in RFC2544 section 11 are common to IPv4 and IPv6, 400 except that IPv6 does not employ layer 2 or 3 broadcast frames. IPv6 401 does not use layer 2 or layer 3 broadcasts. This section provides 402 additional conditions that are specific to IPv6. The suite of tests 403 recommended in this document SHOULD be first executed in the absence 404 of these conditions and then repeated under each of these conditions 405 separately. 407 6.1. Management and Routing Traffic 409 The procedures defined in RFC2544 sections 11.2 and 11.3 are 410 applicable for IPv6 management and routing update frames as well. 412 6.2. Filters 414 The filters defined in Section 11.4 of RFC2544 apply to IPv6 415 benchmarking as well. The filter definitions must be expanded to 416 include upper layer protocol information matching in order to analyze 417 the handling of traffic with extension headers which are an important 418 architectural component of IPv6. 420 6.2.1. Filter Format 422 The filter format defined in RFC2544 is applicable to IPv6 as well 423 except that the source addresses (SA) and destination addresses (DA) 424 are IPv6 addresses. In addition to these basic filters, the 425 evaluation of IPv6 performance SHOULD analyze the correct filtering 426 and handling of traffic with extension headers. 428 While the intent is not to evaluate a platform's capability to 429 process the various extension header types, the goal is to measure 430 performance impact when the network element must parse through the 431 extension headers to reach upper layer information. In IPv6, routers 432 do not have to parse through the extension headers (other than hop- 433 by-hop) unless, for example, upper layer information has to be 434 analyzed due to filters. 436 To evaluate the network element handling of IPv6 traffic with 437 extension headers, the definition of the filters must be extended to 438 include conditions applied to upper layer protocol information. The 439 following filter format SHOULD be used for this type of evaluation: 441 [permit|deny] [protocol] [SA] [DA] 443 where permit or deny indicates the action to allow or deny a packet 444 through the interface the filter is applied to. The protocol field 445 is defined as: 446 o ipv6: any IP Version 6 traffic 447 o tcp: Transmission Control Protocol 448 o udp: User Datagram Protocol 449 and SA stands for the source address and DA for the destination 450 address. 452 The upper layer protocols listed above are recommended selection. 453 However, they do not represent an all-inclusive list of upper layer 454 protocols which could be used in defining filters. 456 6.2.2. Filter Types 458 Based on RFC2544 recommendations, two types of tests are executed 459 when evaluating performance in the presence of modifiers: One with a 460 single filter and another with 25 filters. Examples of recommended 461 filters are illustrated using the IPv6 documentation prefix [10] 462 2001:DB8::. 464 Examples of single filters are: 466 Filter for TCP traffic - permit tcp 2001:DB8::1 2001:DB8::2 467 Filter for UDP traffic - permit udp 2001:DB8::1 2001:DB8::2 468 Filter for IPv6 traffic - permit ipv6 2001:DB8::1 2001:DB8::2 470 The single line filter case SHOULD verify that the network element 471 permits all TCP/UDP/IPv6 traffic with or without any number of 472 extension headers from IPv6 SA 2001:DB8::1 to IPv6 DA 2001:DB8::2 and 473 deny all other traffic. 475 Example of 25 filters: 477 deny tcp 2001:DB8:1::1 2001:DB8:1::2 478 deny tcp 2001:DB8:2::1 2001:DB8:2::2 479 deny tcp 2001:DB8:3::1 2001:DB8:3::2 480 ... 481 deny tcp 2001:DB8:C::1 2001:DB8:C::2 482 permit tcp 2001:DB8:99::1 2001:DB8:99::2 483 deny tcp 2001:DB8:D::1 2001:DB8:D::2 484 deny tcp 2001:DB8:E::1 2001:DB8:E::2 485 ... 486 deny tcp 2001:DB8:19::1 2001:DB8:19::2 487 deny ipv6 any any 489 The router SHOULD deny all traffic with or without extension headers 490 except TCP traffic with SA 2001:DB8:99::1 and DA 2001:DB8:99::2. 492 7. Benchmarking Tests 494 This document recommends the same benchmarking tests described in 495 RFC2544 while observing the DUT setup and the traffic setup 496 considerations described above. The following sections state the 497 test types explicitly and highlight only the methodology differences 498 that might exist with respect to those described in Section 26 of 499 RFC2544. 501 The specificities of IPv6, particularly the definition of extension 502 headers processing, require additional benchmarking steps. The tests 503 recommended by RFC2544 MUST be repeated for IPv6 traffic without 504 extension headers and for IPv6 traffic with one or multiple extension 505 headers. 507 IPv6's deployment in existing IPv4 environments and the expected long 508 co-existence of the two protocols leads network operators to place 509 great emphasis on understanding the performance of platforms 510 processing both types of traffic. While device resources are shared 511 between the two protocols, it is important that IPv6-enabled 512 platforms not experience degraded IPv4 performance. Thus, IPv6 513 benchmarking SHOULD be performed in the context of a stand alone 514 protocol as well as in the context of its co-existence with IPv4. 516 The modifiers defined are independent of extension header type so 517 they can be applied equally to each one of the above tests. 519 The benchmarking tests described in this section SHOULD be performed 520 under each of the following conditions: 522 Extension header specific conditions: 523 i) IPv6 traffic with no extension headers 524 ii) IPv6 traffic with one extension header from the list in 525 section 5.3 526 iii) IPv6 traffic with the chain of extension headers described in 527 section 5.3 529 Co-existence specific conditions: 530 iv) IPv4 ONLY traffic benchmarking 531 v) IPv6 ONLY traffic benchmarking 532 vi) IPv4-IPv6 traffic mix with the ratio 90% vs 10% 533 vii) IPv4-IPv6 traffic mix with the ratio 50% vs 50% 534 viii) IPv4-IPv6 traffic mix with the ratio 10% vs 90% 536 Combining the test conditions listed for benchmarking IPv6 as a 537 stand-alone protocol and the co-existence tests leads to a large 538 coverage matrix. At a minimum requirement, the co-existence tests 539 should use IPv6 traffic with no extension headers and the 10%-90%, 540 90%-10% IPv4/IPv6 traffic mix. 542 The subsequent sections each describe specific tests that MUST be 543 executed under the conditions listed above for a complete 544 benchmarking of IPv6 forwarding performance. 546 7.1. Throughput 548 Objective: To determine the DUT throughput as defined in RFC1242. 550 Procedure: Same as RFC2544. 552 Reporting Format: Same as RFC2544. 554 7.2. Latency 556 Objective: To determine the latency as defined in RFC1242. 558 Procedure: Same as RFC2544. 560 Reporting Format: Same as RFC2544. 562 7.3. Frame Loss 564 Objective: To determine the frame loss rate, as defined in RFC1242, 565 of a DUT throughout the entire range of input data rates and frame 566 sizes. 568 Procedure: Same as RFC2544. 570 Reporting Format: Same as RFC2544. 572 7.4. Back-to-Back Frames 574 Based on the IPv4 experience, the back-to-back frames test is 575 characterized by significant variance due to short term variations in 576 the processing flow. For these reasons, this test is no longer 577 recommended for IPv6 benchmarking. 579 7.5. System Recovery 581 Objective: To characterize the speed at which a DUT recovers from an 582 overload condition. 584 Procedure: Same as RFC2544. 586 Reporting Format: Same as RFC2544. 588 7.6. Reset 590 Objective: To characterize the speed at which a DUT recovers from a 591 device or software reset. 593 Procedure: Same as RFC2544. 595 Reporting Format: Same as RFC2544. 597 8. IANA Considerations 599 IANA reserved prefix xxxxx/48 for IPv6 benchmarking similar to 600 198.18.0.0/15 in RFC 3330 [9]. This prefix length provides similar 601 flexibility as the range allocated for IPv4 benchmarking and it is 602 taking into consideration address conservation and simplicity of 603 usage concerns. The requested size meets the requirements for 604 testing large network elements and large emulated networks. 606 Note to IANA: Replace "xxxxx" with assigned prefix. 608 9. Security Considerations 610 Benchmarking activities as described in this memo are limited to 611 technology characterization using controlled stimuli in a laboratory 612 environment, with dedicated address space and the constraints 613 specified in the sections above. 615 The benchmarking network topology will be an independent test setup 616 and MUST NOT be connected to devices that may forward the test 617 traffic into a production network, or misroute traffic to the test 618 management network. 620 Further, benchmarking is performed on a "black-box" basis, relying 621 solely on measurements observable external to the DUT/SUT. 623 Special capabilities SHOULD NOT exist in the DUT/SUT specifically for 624 benchmarking purposes. Any implications for network security arising 625 from the DUT/SUT SHOULD be identical in the lab and in production 626 networks. 628 The isolated nature of the benchmarking environments and the fact 629 that no special features or capabilities, other than those used in 630 operational networks, are enabled on the DUT/SUT requires no security 631 considerations specific to the benchmarking process. 633 10. Conclusions 635 The Benchmarking Methodology for Network Interconnect Devices 636 document, RFC2544 [8], is for the most part applicable to evaluating 637 the IPv6 performance of network elements. This document addresses 638 the IPv6 specific requirements that MUST be observed when applying 639 the recommendations of RFC2544. These additional requirements stem 640 from the architecture characteristics of IPv6. This document is not 641 a replacement of but a complement to RFC2544. 643 11. Acknowledgements 645 Scott Bradner provided valuable guidance and recommendations for this 646 document. The authors acknowledge the work done by Cynthia Martin 647 and Jeff Dunn with respect to defining the terminology for IPv6 648 benchmarking. The authors would like to thank Bill Kine for his 649 contribution to the initial document and to Tom Alexander, Bill 650 Cerveny, Silvija Dry, Sven Lanckmans, Dean Lee, Athanassios 651 Liakopoulos, Benoit Lourdelet, Al Morton, David Newman, Rajiv 652 Papejna, Dan Romascanu and Pekka Savola for their very helpful 653 feedback. Maryam Hamza inspired the authors in completing this 654 document. 656 12. References 657 12.1. Normative References 659 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 660 Levels", BCP 14, RFC 2119, March 1997. 662 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 663 Specification", RFC 2460, December 1998. 665 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 666 for IP Version 6 (IPv6)", RFC 2461, December 1998. 668 [4] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, 669 June 1999. 671 [5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 672 December 2005. 674 12.2. Informative References 676 [6] Bradner, S., "Benchmarking terminology for network 677 interconnection devices", RFC 1242, July 1991. 679 [7] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, 680 July 1994. 682 [8] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 683 Network Interconnect Devices", RFC 2544, March 1999. 685 [9] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. 687 [10] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 688 Reserved for Documentation", RFC 3849, July 2004. 690 [11] Newman, D. and T. Player, "Hash and Stuffing: Overlooked 691 Factors in Network Device Benchmarking", RFC 4814, March 2007. 693 [12] LAN/MAN Standards Committee of the IEEE Computer Society, "IEEE 694 Std 802.3as-2006, Part 3: Carrier Sense Multiple Access with 695 Collision Detection (CSMA/CD) Access Method and Physical Layer 696 Specifications, Amendment 3: Frame format extensions", 697 November 2006. 699 Appendix A. Theoretical Maximum Frame Rates Reference 701 This appendix provides the formulas to calculate and the values for 702 the theoretical maximum frame rates for two media types: Ethernet and 703 SONET. 705 A.1. Ethernet 707 The throughput in frames per second (fps) for various Ethernet 708 interface types and for a frame size X can be calculated with the 709 following formula: 711 Line Rate (bps) 712 ------------------------------ 713 (8bits/byte)*(X+20)bytes/frame 715 The 20 bytes in the formula is the sum of the preamble (8 bytes) and 716 the inter frame gap (12 bytes). The throughput for various Ethernet 717 interface types and frame sizes: 719 Size 10Mb/s 100Mb/s 1000Mb/s 10000Mb/s 720 Bytes pps pps pps pps 722 64 14,880 148,809 1,488,095 14,880,952 723 128 8,445 84,459 844,594 8,445,945 724 256 4,528 45,289 452,898 4,528,985 725 512 2,349 23,496 234,962 2,349,624 726 1024 1,197 11,973 119,731 1,197,318 727 1280 961 9,615 96,153 961,538 728 1518 812 8,127 81,274 812,743 729 2048 604 6,044 60,444 604,448 730 4096 303 3,036 30,396 303,691 731 8192 152 1,522 15,221 152,216 732 9216 135 1,353 13,534 135,339 734 Note: Ethernet's maximum frame rates are subject to variances due to 735 clock slop. The listed rates are theoretical maximums and actual 736 tests should account for a +/- 100 ppm tolerance. 738 A.2. Packet over SONET 740 ANSI T1.105 SONET provides the formula for calculating the maximum 741 available bandwidth for the various Packet over SONET (PoS) interface 742 types: 744 STS-Nc (N = 3Y, where Y=1,2,3,etc) 746 [(N*87) - N/3]*(9 rows)*(8 bit/byte)*(8000 frames/sec) 748 Packets over SONET can use various encapsulations: PPP [4], HDLC [7] 749 and Frame Relay. All these encapsulations use a 4-byte header, a 2- 750 or 4-byte FCS field and a 1-byte Flag which are all accounted for in 751 the overall frame size. The maximum frame rate for various interface 752 types can be calculated with the formula (where X represents the 753 frame size in bytes): 755 Line Rate (bps) 756 ------------------------------ 757 (8bits/byte)*(X+1)bytes/frame 759 The theoretical maximum frame rates for various PoS interface types 760 and frame sizes: 762 Size OC-3c OC-12c OC-48c OC-192c OC-768c 763 Bytes fps fps fps fps fps 765 47 390,000 1,560,000 6,240,000 24,960,000 99,840,000 766 64 288,000 1,152,000 4,608,000 18,432,000 73,728,000 767 128 145,116 580,465 2,321,860 9,287,441 37,149,767 768 256 72,840 291,361 1,165,447 4,661,789 18,647,159 769 512 36,491 145,964 583,859 2,335,438 9,341,754 770 1024 18,263 73,053 292,214 1,168,858 4,675,434 771 2048 9,136 36,544 146,178 584,714 2,338,857 772 4096 4,569 18,276 73,107 292,428 1,169,714 774 It is important to note that throughput test results may vary from 775 the values presented in appendices A.1 and A.2 due to bit stuffing 776 performed by various media types [11]. The theoretical throughput 777 numbers were rounded down. 779 Authors' Addresses 781 Ciprian Popoviciu 782 Cisco Systems 783 Kit Creek Road 784 RTP, North Carolina 27709 785 USA 787 Phone: 919 787 8162 788 Email: cpopovic@cisco.com 790 Ahmed Hamza 791 Cisco Systems 792 3000 Innovation Drive 793 Kanata K2K 3E8 794 Canada 796 Phone: 613 254 3656 797 Email: ahamza@cisco.com 798 Gunter Van de Velde 799 Cisco Systems 800 De Kleetlaan 6a 801 Diegem 1831 802 Belgium 804 Phone: +32 2704 5473 805 Email: gunter@cisco.com 807 Diego Dugatkin 808 IXIA 809 26601 West Agoura Rd 810 Calabasas 91302 811 USA 813 Phone: 818 444 3124 814 Email: diego@ixiacom.com 816 Full Copyright Statement 818 Copyright (C) The IETF Trust (2007). 820 This document is subject to the rights, licenses and restrictions 821 contained in BCP 78, and except as set forth therein, the authors 822 retain all their rights. 824 This document and the information contained herein are provided on an 825 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 826 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 827 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 828 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 829 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 830 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 832 Intellectual Property 834 The IETF takes no position regarding the validity or scope of any 835 Intellectual Property Rights or other rights that might be claimed to 836 pertain to the implementation or use of the technology described in 837 this document or the extent to which any license under such rights 838 might or might not be available; nor does it represent that it has 839 made any independent effort to identify any such rights. Information 840 on the procedures with respect to rights in RFC documents can be 841 found in BCP 78 and BCP 79. 843 Copies of IPR disclosures made to the IETF Secretariat and any 844 assurances of licenses to be made available, or the result of an 845 attempt made to obtain a general license or permission for the use of 846 such proprietary rights by implementers or users of this 847 specification can be obtained from the IETF on-line IPR repository at 848 http://www.ietf.org/ipr. 850 The IETF invites any interested party to bring to its attention any 851 copyrights, patents or patent applications, or other proprietary 852 rights that may cover technology that may be required to implement 853 this standard. Please address the information to the IETF at 854 ietf-ipr@ietf.org. 856 Acknowledgment 858 Funding for the RFC Editor function is provided by the IETF 859 Administrative Support Activity (IASA).