idnits 2.17.1 draft-ietf-bmwg-ipv6-meth-02.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 816. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 840. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 707 has weird spacing: '... Bytes pps...' == Line 749 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 'MUST not' in this paragraph: IANA reserved the IPv6 address block xxxxx/48 for use with IPv6 benchmark testing. These addresses MUST be assumed to be not routable on the Internet and MUST not be used as Internet source or destination addresses. == 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: The 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). The 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 to be used in 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 (July 2, 2007) is 6114 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) -- Looks like a reference, but probably isn't: 'SA' on line 434 -- Looks like a reference, but probably isn't: 'DA' on line 434 ** 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 (~~), 8 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 Expires: January 3, 2008 G. Van de Velde 5 Cisco Systems 6 D. Dugatkin 7 IXIA 8 July 2, 2007 10 IPv6 Benchmarking Methodology 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 January 3, 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, they do not address some of the specificities of 46 IPv6. This document provides additional benchmarking guidelines 47 which in conjunction with RFC2544 lead to a more complete and 48 realistic evaluation of the IPv6 performance of network elements. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 3 54 3. Tests and Results Evaluation . . . . . . . . . . . . . . . . . 3 55 4. Test Environment Set Up . . . . . . . . . . . . . . . . . . . 4 56 5. Test Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5.1. Frame Formats and Sizes . . . . . . . . . . . . . . . . . 4 58 5.1.1. Frame Sizes to be used on Ethernet . . . . . . . . . . 5 59 5.1.2. Frame Sizes to be used on SONET . . . . . . . . . . . 5 60 5.2. Protocol Addresses Selection . . . . . . . . . . . . . . . 5 61 5.2.1. DUT Protocol Addresses . . . . . . . . . . . . . . . . 6 62 5.2.2. Test Traffic Protocol Addresses . . . . . . . . . . . 7 63 5.3. Traffic with Extension Headers . . . . . . . . . . . . . . 7 64 5.4. Traffic set up . . . . . . . . . . . . . . . . . . . . . . 9 65 6. Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6.1. Management and Routing Traffic . . . . . . . . . . . . . . 9 67 6.2. Filters . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.2.1. Filter Format . . . . . . . . . . . . . . . . . . . . 9 69 6.2.2. Filter Types . . . . . . . . . . . . . . . . . . . . . 10 70 7. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . . 11 71 7.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 12 72 7.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 7.3. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 12 74 7.4. Back-to-Back Frames . . . . . . . . . . . . . . . . . . . 13 75 7.5. System Recovery . . . . . . . . . . . . . . . . . . . . . 13 76 7.6. Reset . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 83 12.2. Informative References . . . . . . . . . . . . . . . . . . 15 84 Appendix A. Theoretical Maximum Frame Rates Reference . . . . . . 15 85 A.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 A.2. Packet over SONET . . . . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 88 Intellectual Property and Copyright Statements . . . . . . . . . . 19 90 1. Introduction 92 The benchmarking methodologies defined by RFC2544 [8] are proving to 93 be useful in consistently evaluating IPv4 forwarding performance of 94 network elements. Adherence to these testing and result analysis 95 procedures facilitates objective comparison of IPv4 performance data 96 measured on various products and by various individuals. While the 97 principles behind the methodologies introduced in RFC2544 are largely 98 IP version independent, the protocol continued to evolve, 99 particularly in its version 6 (IPv6). 101 This document provides benchmarking methodology recommendations that 102 address IPv6 specific aspects such as evaluating the forwarding 103 performance of traffic containing extension headers as defined in 104 RFC2460 [2]. These recommendations are defined within the RFC2544 105 framework and are meant to complement the test and result analysis 106 procedures as described in RFC2544 and not replace them. 108 The terms used in this document remain consistent with those defined 109 in "Benchmarking Terminology for Network Interconnect Devices" [6]. 110 This terminology SHOULD be consulted before using or applying the 111 recommendations of this document. 113 Any methodology aspects not covered in this document SHOULD be 114 assumed to be treated based on the RFC2544 recommendations. 116 2. Existing Definitions 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in BCP 14, RFC 2119 [1]. 121 RFC 2119 defines the use of these key words to help make the intent 122 of standards track documents as clear as possible. While this 123 document uses these keywords, this document is not a standards track 124 document. 126 3. Tests and Results Evaluation 128 The recommended performance evaluation tests are described in Section 129 6 of this document. Not all of these tests are applicable to all 130 network element types. Nevertheless, for each evaluated device it is 131 recommended to perform as many of the applicable tests described in 132 Section 6 as possible. 134 Test execution and the results analysis MUST be performed while 135 observing generally accepted testing practices regarding 136 repeatability, variance and statistical significance of small numbers 137 of trials. 139 4. Test Environment Set Up 141 The test environment setup options recommended for the IPv6 142 performance evaluation are the same as the ones described in Section 143 6 of RFC2544, in both single-port and multi-port scenarios. Single- 144 port testing is used in measuring per interface forwarding 145 performance while multi-port testing is used to measure the 146 scalability of forwarding performance across the entire platform. 148 Throughout the test, the DUT can be monitored for relevant resource 149 (Processor, Memory, etc.) utilization. This data could be beneficial 150 in understanding traffic processing by each DUT and the resources 151 that must be allocated for IPv6. It could reveal if the IPv6 traffic 152 is processed in hardware, by applicable devices, under all test 153 conditions or it is punted in the software switched path. If such 154 data is considered of interest, it MUST be collected out of band and 155 independent of any management data that might be recommended to be 156 collected through the interfaces forwarding the test traffic. 158 Note: During testing, either static or dynamic options for neighbor 159 discovery can be used. The static option can be used as long as it 160 is supported by the test tool. The dynamic option is preferred 161 wherein the test tool interacts with the DUT for the duration of the 162 test to maintain the respective neighbor caches in an active state. 163 To avoid neighbor solicitation (NS) and neighbor advertisement (NA) 164 storms due to the neighbor unreachability detection (NUD) mechanism 165 [3], the test scenarios assume the test traffic simulates end points 166 and the IPv6 source and destination addresses are one hop beyond the 167 DUT. 169 5. Test Traffic 171 The traffic used for all tests described in this document SHOULD meet 172 the requirements described in this section. These requirements are 173 designed to reflect the characteristics of IPv6 unicast traffic in 174 all its aspects. Using the recommended IPv6 traffic profile leads to 175 a complete 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 4.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 206 interface in today's networks. The following frame sizes SHOULD be 207 used for benchmarking over this media type: 64, 128, 256, 512, 1024, 208 1280, 1518 bytes. Tests with jumbo frames SHOULD be executed. Frame 209 sizes should be selected based on the values supported by the device 210 under test due to the absence of a common standard defining the jumbo 211 frame sizes. Examples of common jumbo frame sizes are: 4096, 8192, 212 9216 bytes. The maximum frame rates for each frame size and the 213 various Ethernet interface types are provided in Appendix A. 215 5.1.2. Frame Sizes to be used on SONET 217 Packet over SONET (PoS) interfaces are commonly used for edge uplinks 218 and high bandwidth core links. Evaluating the forwarding performance 219 of PoS interfaces supported by the DUT is recommended. The following 220 frame sizes SHOULD be used for this media type: 53, 64, 128, 256, 221 512, 1024, 1280, 1518, 2048, 4096 bytes. The maximum frame rates for 222 each frame size and the various PoS interface types are provided in 223 Appendix A. 225 5.2. Protocol Addresses Selection 227 There are two aspects of IPv6 benchmarking testing where IP address 228 selection considerations MUST be analyzed: The selection of IP 229 addresses for the DUT and the selection of addresses for the test 230 traffic. 232 5.2.1. DUT Protocol Addresses 234 IANA reserved the IPv6 address block xxxxx/48 for use with IPv6 235 benchmark testing. These addresses MUST be assumed to be not 236 routable on the Internet and MUST not be used as Internet source or 237 destination addresses. 239 Note to IANA: Replace "xxxxx" with assigned prefix. 241 Similar to RFC2544, Appendix C, addresses from the first half of this 242 range SHOULD be used for the ports viewed as input and addresses from 243 the other half of the range for the output ports. 245 The prefix length of the IPv6 addresses configured on the DUT 246 interfaces MUST fall into either one of the following: 247 o Prefix length is /126 which would simulate a point-to-point link 248 for a core router. 249 o Prefix length is smaller or equal to /64. 250 No prefix lengths SHOULD be selected in the range between 64 and 128 251 except the 126 value mentioned above. 253 Note that /126 prefixes might not be always the best choice for 254 addressing point-to-point links such as back-to-back Ethernet unless 255 the autoprovisioning mechanism is disabled. Also, not all network 256 elements support addresses of this prefix length. 258 While with IPv6, the DUT interfaces can be configured with multiple 259 global unicast addresses, the methodology described in this document 260 does not require testing such a scenario. It is not expected that 261 such an evaluation would bring additional data with respect to the 262 performance of the network element. 264 The Interface ID portion of global unicast IPv6 DUT addresses SHOULD 265 be set to ::1. There are no requirements in the selection of the 266 Interface ID portion of the link local IPv6 addresses. 268 It is recommended that multiple iterations of the benchmark tests be 269 conducted using the following prefix lengths: 48, 64, 126 and 128 for 270 the advertised traffic destination prefix. Other prefix lengths can 271 be used. However the indicated range reflects major prefix 272 boundaries expected to be present in IPv6 routing tables and they 273 should be representative to establish baseline performance metrics. 275 5.2.2. Test Traffic Protocol Addresses 277 The IPv6 source and destination addresses for the test streams SHOULD 278 belong to the IPv6 range assigned by IANA as discussed in section 279 5.2.1. The source addresses SHOULD belong to one half of the range 280 and the destination addresses to the other, reflecting the DUT 281 interface IPv6 address selection. 283 Tests SHOULD first be executed with a single stream leveraging a 284 single source-destination address pair. The tests SHOULD then be 285 repeated with traffic using a random destination address in the 286 corresponding range. If the network element prefix lookup 287 capabilities are evaluated, the tests SHOULD focus on the IPv6 288 relevant prefix boundaries: 0-64, 126 and 128. 290 Special care needs to be taken about the neighbor unreachability 291 detection (NUD) [3] process. The IPv6 prefix reachable time in the 292 router advertisement SHOULD be set to 30 seconds and allow 50% 293 jitter. The IPv6 source and destination addresses SHOULD not appear 294 to be directly connected to the DUT to avoid neighbor solicitation 295 (NS) and neighbor advertisement (NA) storms due to multiple test 296 traffic flows. 298 5.3. Traffic with Extension Headers 300 Extension headers are an intrinsic part of the IPv6 architecture [2]. 301 They are used with various types of practical traffic such as: 302 fragmented traffic, mobile IP based traffic, authenticated and 303 encrypted traffic. For these reasons, all tests described in this 304 document SHOULD be performed with both traffic that has no extension 305 headers and traffic that has a set of extension headers. They can be 306 selected from the following list [2] which reflects the recommended 307 order of multiple extension headers in a packet: 308 o Hop-by-hop header 309 o Destination options header 310 o Routing header 311 o Fragment header 312 o Authentication header 313 o Encapsulating Security Payload header 314 o Destination options header 315 o Mobility header 317 Considering that extension headers are an intrinsic part of the 318 protocol and that they fulfill different roles, benchmarking of 319 traffic containing each extension header SHOULD be executed 320 individually. 322 The special processing rules for the Hop-by-hop extension header 323 require a specific benchmarking approach. Unlike the other extension 324 headers, this header must be processed by each node that forwards the 325 traffic. Tests with traffic containing these extension header types 326 will not measure the forwarding performance of the DUT but rather its 327 extension header processing capability, which is dependent on the 328 information contained in the extension headers. The concern is that 329 this traffic, at high rates, could have a negative impact on the 330 operational resources of the router and could be used as a security 331 threat. When benchmarking with traffic that contains the Hop-by-hop 332 extension header, the goal is not to measure throughput [8] as in the 333 case of the other extension headers but rather to evaluate the impact 334 of such traffic on the router. In this case, traffic with the Hop- 335 by-hop extension headers should be sent at 1%, 10% and 50% of the 336 interface total bandwidth. Device resources must be monitored at 337 each traffic rate to determine the impact. 339 The tests with traffic containing each individual extension header 340 MUST be complemented with tests containing a chain of two or more 341 extension headers (the chain MUST not contain the Hop-by-hop 342 extension header). The chain should also exclude the ESP [5] 343 extension header since traffic with an encrypted payload can not be 344 used in tests with modifiers such as filters based on upper layer 345 information (see Section 5). Since the DUT is not analyzing the 346 content of the extension headers, any combination of extension 347 headers can be used in testing. The extension header chain 348 recommended to be used in testing is: 349 o Routing header - 24-32 bytes 350 o Destination options header - 8 bytes 351 o Fragment header - 8 bytes 353 This is a real life extension header chain that would be found in an 354 IPv6 packet between two mobile nodes exchanged over an optimized path 355 that requires fragmentation. The listed extension headers lengths 356 represent test tool defaults. The total length of the extension 357 header chain SHOULD be larger than 32 bytes. 359 Extension headers add extra bytes to the payload size of the IP 360 packets which MUST be factored in when used in testing at low frame 361 sizes. Their presence will modify the minimum packet size used in 362 testing. For direct comparison between the data obtained with 363 traffic that has extension headers and with traffic that doesn't have 364 them at low frame size, a common value SHOULD be selected for the 365 smallest frame size both types of traffic. 367 For most cases, the network elements ignore the extension headers 368 when forwarding IPv6 traffic. For these reasons it is likely that 369 the extension headers related performance impact will be observed 370 only when testing the DUT with traffic filters that contain matching 371 conditions for the upper layer protocol information. In those cases, 372 the DUT MUST traverse the chain of extension headers, a process that 373 could impact performance. 375 5.4. Traffic set up 377 All tests recommended in this document SHOULD be performed with bi- 378 directional traffic. For asymmetric situations, tests MAY be 379 performed with unidirectional traffic for a more granular 380 characterization of the DUT performance. In these cases, the 381 bidirectional traffic testing would reveal only the lowest 382 performance between the two directions. 384 All other traffic profile characteristics described in RFC2544 SHOULD 385 be applied in this testing as well. IPv6 multicast benchmarking is 386 outside the scope of this document. 388 6. Modifiers 390 RFC2544 underlines the importance of evaluating the performance of 391 network elements under certain operational conditions. The 392 conditions defined in RFC2544 Section 11 are common to IPv4 and IPv6 393 with the exception of broadcast frames. IPv6 does not use layer 2 or 394 layer 3 broadcasts. This section provides additional conditions that 395 are specific to IPv6. The suite of tests recommended in this 396 document SHOULD be first executed in the absence of these conditions 397 and then repeated under each of these conditions separately. 399 6.1. Management and Routing Traffic 401 The procedures defined in RFC2544 sections 11.2 and 11.3 are 402 applicable for IPv6 management and routing update Frames as well. 404 6.2. Filters 406 The filters defined in Section 11.4 of RFC2544 apply to IPv6 407 benchmarking as well. The filter definitions however must be 408 expanded to include upper layer protocol information matching in 409 order to analyze the handling of traffic with extension headers which 410 are an important architectural component of IPv6. 412 6.2.1. Filter Format 414 The filter format defined in RFC2544 is applicable to IPv6 as well 415 except that the source addresses (SA) and destination addresses (DA) 416 are IPv6. In addition to these basic filters, the evaluation of IPv6 417 performance SHOULD analyze the correct filtering and handling of 418 traffic with extension headers. 420 While the intent is not to evaluate a platform's capability to 421 process the various extension header types, the goal is to measure 422 performance impact when the network element must parse through the 423 extension headers in order to reach upper layer information. In 424 IPv6, routers do not have to parse through the extension headers 425 (other than Hop-by-hop) unless, for example, the upper layer 426 information has to be analyzed due to filters. 428 For these reasons, to evaluate the network element handling of IPv6 429 traffic with extension headers, the definition of the filters must be 430 extended to include conditions applied to upper layer protocol 431 information. The following filter format SHOULD be used for this 432 type of evaluation: 434 [permit|deny] [protocol] [SA] [DA] 436 where permit or deny indicates the action to allow or deny a packet 437 through the interface the filter is applied to. The protocol field 438 is defined as: 439 o ipv6: any IP Version 6 traffic 440 o tcp: Transmission Control Protocol 441 o udp: User Datagram Protocol 442 and SA stands for the source address and DA for the destination 443 address. The upper layer protocols listed above are recommended 444 selection, however they do not represent an all-inclusive list of 445 upper layer protocols which could be used in defining filters. 447 6.2.2. Filter Types 449 Based on the RFC2544 recommendations, two types of tests are executed 450 when evaluating performance in the presence of modifiers. One with a 451 single filter and one with 25 filters. The recommended filters are 452 exemplified with the help of the IPv6 documentation prefix [10] 2001: 453 DB8::. 455 Examples of single filters are: 457 Filter for TCP traffic - permit tcp 2001:DB8::1 2001:DB8::2 458 Filter for UDP traffic - permit udp 2001:DB8::1 2001:DB8::2 459 Filter for IPv6 traffic - permit ipv6 2001:DB8::1 2001:DB8::2 461 The single line filter case SHOULD verify that the network element 462 permits all TCP/UDP/IPv6 traffic with or without any number of 463 extension headers from IPv6 SA 2001:DB8::1 to IPv6 DA 2001:DB8::2 and 464 deny all other traffic. 466 Example of 25 filters: 468 deny tcp 2001:DB8:1::1 2001:DB8:1::2 469 deny tcp 2001:DB8:2::1 2001:DB8:2::2 470 deny tcp 2001:DB8:3::1 2001:DB8:3::2 471 ... 472 deny tcp 2001:DB8:C::1 2001:DB8:C::2 473 permit tcp 2001:DB8:99::1 2001:DB8:99::2 474 deny tcp 2001:DB8:D::1 2001:DB8:D::2 475 deny tcp 2001:DB8:E::1 2001:DB8:E::2 476 ... 477 deny tcp 2001:DB8:19::1 2001:DB8:19::2 478 deny ipv6 any any 480 The router SHOULD deny all traffic with or without extension headers 481 except TCP traffic with SA 2001:DB8:99::1 and DA 2001:DB8:99::2. 483 7. Benchmarking Tests 485 This document recommends the same benchmarking tests described in 486 RFC2544 while observing the DUT setup and the traffic setup 487 considerations described above. The following sections state the 488 test types explicitly and highlight only the methodology differences 489 that might exist with respect to those described in Section 26 of 490 RFC2544. 492 The specificities of IPv6, particularly the definition of extension 493 headers processing, require additional benchmarking steps. In this 494 sense, the tests recommended by RFC2544 MUST be repeated for IPv6 495 traffic without extension headers and with one or multiple extension 496 headers. 498 IPv6's deployment in existing IPv4 environments and the expected long 499 co-existence of the two protocols leads network operators to place 500 great emphasis on understanding the performance of platforms 501 forwarding both types of traffic. While device resources are shared 502 between the two protocols, it is important for IPv6 enabled platforms 503 to not experience degraded IPv4 performance. Thus, IPv6 benchmarking 504 SHOULD be performed in the context of a stand alone protocol as well 505 as in the context of its co-existence with IPv4. 507 The modifiers defined are independent of extension header type so 508 they can be applied equally to each one of the above tests. 510 The benchmarking tests described in this section SHOULD be performed 511 under each of the following conditions: 513 Extension header specific conditions: 514 i) IPv6 traffic with no extension headers 515 ii) IPv6 traffic with one extension header from the list in 516 section 4.3 517 iii) IPv6 traffic with the chain of extension headers described in 518 section 4.3 520 Co-existence specific conditions: 521 iv) IPv4 ONLY traffic benchmarking 522 v) IPv6 ONLY traffic benchmarking 523 vi) IPv4-IPv6 traffic mix with the ratio 90% vs 10% 524 vii) IPv4-IPv6 traffic mix with the ratio 50% vs 50% 525 viii) IPv4-IPv6 traffic mix with the ratio 10% vs 90% 527 Combining the test conditions listed for benchmarking IPv6 as a 528 stand-alone protocol and the co-existence tests leads to a large 529 coverage matrix. A minimum requirement is to cover the co-existence 530 conditions in the case of IPv6 with no extension headers and those 531 where either of the traffic is 10% and 90% respectively. 533 The subsequent sections describe each specific tests that MUST be 534 executed under the conditions listed above for a complete 535 benchmarking of IPv6 forwarding performance. 537 7.1. Throughput 539 Objective: To determine the DUT throughput as defined in RFC1242. 541 Procedure: Same as RFC2544. 543 Reporting Format: Same as RFC2544. 545 7.2. Latency 547 Objective: To determine the latency as defined in RFC1242. 549 Procedure: Same as RFC2544. 551 Reporting Format: Same as RFC2544. 553 7.3. Frame Loss 555 Objective: To determine the frame loss rate, as defined in RFC1242, 556 of a DUT throughout the entire range of input data rates and frame 557 sizes. 559 Procedure: Same as RFC2544. 561 Reporting Format: Same as RFC2544. 563 7.4. Back-to-Back Frames 565 Objective: To characterize the ability of a DUT to process back-to- 566 back frames as defined in RFC1242. 568 Based on the IPv4 experience, the Back-to-Back frames test is 569 characterized by significant variance due to short term variations in 570 the processing flow. For these reasons, this test is no longer 571 recommended for IPv6 benchmarking. 573 7.5. System Recovery 575 Objective: To characterize the speed at which a DUT recovers from an 576 overload condition. 578 Procedure: Same as RFC2544. 580 Reporting Format: Same as RFC2544. 582 7.6. Reset 584 Objective: To characterize the speed at which a DUT recovers from a 585 device or software reset. 587 Procedure: Same as RFC2544. 589 Reporting Format: Same as RFC2544. 591 8. IANA Considerations 593 IANA reserved prefix xxxxx/48 for IPv6 benchmarking similar to 594 198.18.0.0/15 in RFC 3330 [9]. This prefix length provides similar 595 flexibility as the range allocated for IPv4 benchmarking and it is 596 taking into consideration address conservation and simplicity of 597 usage concerns. The requested size meets the requirements for 598 testing large network elements and large emulated networks. 600 Note to IANA: Replace "xxxxx" with assigned prefix. 602 9. Security Considerations 604 Benchmarking activities as described in this memo are limited to 605 technology characterization using controlled stimuli in a laboratory 606 environment, with dedicated address space and the constraints 607 specified in the sections above. 609 The benchmarking network topology will be an independent test setup 610 and MUST NOT be connected to devices that may forward the test 611 traffic into a production network, or misroute traffic to the test 612 management network. 614 Further, benchmarking is performed on a "black-box" basis, relying 615 solely on measurements observable external to the DUT/SUT. 617 Special capabilities SHOULD NOT exist in the DUT/SUT specifically for 618 benchmarking purposes. Any implications for network security arising 619 from the DUT/SUT SHOULD be identical in the lab and in production 620 networks. 622 The isolated nature of the benchmarking environments and the fact 623 that no special features or capabilities, other than those used in 624 operational networks, are enabled on the DUT/SUT requires no security 625 considerations specific to the benchmarking process. 627 10. Conclusions 629 The Benchmarking Methodology for Network Interconnect Devices 630 document, RFC2544 [8], is for the most part applicable to evaluating 631 the IPv6 performance of network elements. This document is 632 addressing the IPv6 specific requirements that MUST be observed when 633 applying the recommendations of RFC2544. These additional 634 requirements stem from the architecture characteristics of IPv6. 635 This document is not a replacement of but a complement to RFC2544. 637 11. Acknowledgements 639 Scott Bradner provided valuable guidance and recommendations for this 640 document. The authors acknowledge the work done by Cynthia Martin 641 and Jeff Dunn with respect to defining the terminology for IPv6 642 benchmarking. The authors would like to thank Bill Kine for his 643 contribution to the initial document and to Bill Cerveny, Silvija 644 Dry, Sven Lanckmans, Dean Lee, Athanassios Liakopoulos, Benoit 645 Lourdelet, Al Morton, Rajiv Papejna and Pekka Savola for their very 646 helpful feedback. Maryam Hamza inspired the authors in completing 647 this document. 649 12. References 650 12.1. Normative References 652 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 653 Levels", BCP 14, RFC 2119, March 1997. 655 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 656 Specification", RFC 2460, December 1998. 658 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 659 for IP Version 6 (IPv6)", RFC 2461, December 1998. 661 [4] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, 662 June 1999. 664 [5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 665 December 2005. 667 12.2. Informative References 669 [6] Bradner, S., "Benchmarking terminology for network 670 interconnection devices", RFC 1242, July 1991. 672 [7] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, 673 July 1994. 675 [8] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 676 Network Interconnect Devices", RFC 2544, March 1999. 678 [9] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. 680 [10] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 681 Reserved for Documentation", RFC 3849, July 2004. 683 [11] Newman, D. and T. Player, "Hash and Stuffing: Overlooked 684 Factors in Network Device Benchmarking", RFC 4814, March 2007. 686 Appendix A. Theoretical Maximum Frame Rates Reference 688 This appendix provides the formulas to calculate and the values for 689 the theoretical maximum frame rates for two media types: Ethernet and 690 SONET. 692 A.1. Ethernet 694 The throughput in frames per second (fps) for various Ethernet 695 interface types and for a frame size X can be calculated with the 696 following formula: 698 Line Rate (bps) 699 ------------------------------ 700 (8bits/byte)*(X+20)bytes/frame 702 The 20 bytes in the formula is the sum of the preamble (8 bytes) and 703 the inter frame gap (12 bytes). The throughput for various Ethernet 704 interface types and frame sizes: 706 Size 10Mb/s 100Mb/s 1000Mb/s 10000Mb/s 707 Bytes pps pps pps pps 709 64 14880 148809 1488095 14880952 710 128 8445 84459 844594 8445945 711 256 4528 45289 452898 4528985 712 512 2349 23496 234962 2349624 713 1024 1197 11973 119731 1197318 714 1280 961 9615 96153 961538 715 1518 812 8127 81274 812743 716 4096 303 3036 30396 303691 717 8192 152 1522 15221 152216 718 9216 135 1353 13534 135339 720 Note: Ethernet's maximum frame rates are subject to variances due to 721 clock slip. The listed rates are theoretical maximums and actual 722 tests should account for a +/- 100 ppm tolerance. 724 A.2. Packet over SONET 726 ANSI T1.105 SONET provides the formula for calculating the maximum 727 available bandwidth for the various Packet over SONET (PoS) interface 728 types: 730 STS-Nc (N = 3Y, where Y=1,2,3,etc) 732 [(N*87) - N/3]*(9 rows)*(8 bit/byte)*(8000 frames/sec) 734 Packets over SONET can use various encapsulations: PPP [4], HDLC [7] 735 and Frame Relay. All these encapsulations use a 4-byte header, a 2- 736 or 4-byte FCS field and a 1-byte Flag which are all accounted for in 737 the overall frame size. The maximum frame rate for various interface 738 types can be calculated with the formula (where X represents the 739 frame size in bytes): 741 Line Rate (bps) 742 ------------------------------ 743 (8bits/byte)*(X+1)bytes/frame 745 The maximum throughput for various PoS interface types and frame 746 sizes: 748 Size OC-3c OC-12c OC-48c OC-192c OC-768c 749 Bytes fps fps fps fps fps 751 53 346,666 1,386,666 5,546,666 22,186,666 88,746,666 752 64 288,000 1,152,000 4,608,000 18,432,000 73,728,000 753 128 145,116 580,465 2,321,860 9,287,441 37,149,767 754 256 72,840 291,361 1,165,447 4,661,789 18,647,159 755 512 36,491 145,964 583,859 2,335,438 9,341,754 756 1024 18,263 73,053 292,214 1,168,858 4,675,434 757 2048 9,136 36,544 146,178 584,714 2,338,857 758 4096 4,569 18,276 73,107 292,428 1,169,714 760 It is important to note that throughput test results may vary from 761 the values presented in appendices A.1 and A.2 due to bit stuffing 762 performed by various media types [11]. The theoretical throughput 763 numbers were rounded down. 765 Authors' Addresses 767 Ciprian Popoviciu 768 Cisco Systems 769 Kit Creek Road 770 RTP, North Carolina 27709 771 USA 773 Phone: 919 787 8162 774 Email: cpopovic@cisco.com 776 Ahmed Hamza 777 Cisco Systems 778 3000 Innovation Drive 779 Kanata K2K 3E8 780 Canada 782 Phone: 613 254 3656 783 Email: ahamza@cisco.com 784 Gunter Van de Velde 785 Cisco Systems 786 De Kleetlaan 6a 787 Diegem 1831 788 Belgium 790 Phone: +32 2704 5473 791 Email: gunter@cisco.com 793 Diego Dugatkin 794 IXIA 795 26601 West Agoura Rd 796 Calabasas 91302 797 USA 799 Phone: 818 444 3124 800 Email: diego@ixiacom.com 802 Full Copyright Statement 804 Copyright (C) The IETF Trust (2007). 806 This document is subject to the rights, licenses and restrictions 807 contained in BCP 78, and except as set forth therein, the authors 808 retain all their rights. 810 This document and the information contained herein are provided on an 811 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 812 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 813 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 814 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 815 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 816 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 818 Intellectual Property 820 The IETF takes no position regarding the validity or scope of any 821 Intellectual Property Rights or other rights that might be claimed to 822 pertain to the implementation or use of the technology described in 823 this document or the extent to which any license under such rights 824 might or might not be available; nor does it represent that it has 825 made any independent effort to identify any such rights. Information 826 on the procedures with respect to rights in RFC documents can be 827 found in BCP 78 and BCP 79. 829 Copies of IPR disclosures made to the IETF Secretariat and any 830 assurances of licenses to be made available, or the result of an 831 attempt made to obtain a general license or permission for the use of 832 such proprietary rights by implementers or users of this 833 specification can be obtained from the IETF on-line IPR repository at 834 http://www.ietf.org/ipr. 836 The IETF invites any interested party to bring to its attention any 837 copyrights, patents or patent applications, or other proprietary 838 rights that may cover technology that may be required to implement 839 this standard. Please address the information to the IETF at 840 ietf-ipr@ietf.org. 842 Acknowledgment 844 Funding for the RFC Editor function is provided by the IETF 845 Administrative Support Activity (IASA).