idnits 2.17.1 draft-ietf-bmwg-ipv6-meth-03.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 836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 847. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 854. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 860. 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 726 has weird spacing: '... Bytes pps...' == Line 769 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 (August 29, 2007) is 6057 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 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. '9') (Obsoleted by RFC 5735) Summary: 4 errors (**), 0 flaws (~~), 7 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: March 1, 2008 G. Van de Velde 5 Cisco Systems 6 D. Dugatkin 7 IXIA 8 August 29, 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 March 1, 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 . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . 16 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 Note: The 47 bytes SONET frame has no practical use since it can 232 carry only the 40 bytes header of an IPv6 packet and no upper layer 233 protocol information. It represents however the smallest frame size 234 for this media type. 236 The maximum frame rates for each frame size and the various PoS 237 interface types are provided in Appendix A. 239 5.2. Protocol Addresses Selection 241 There are two aspects of IPv6 benchmarking testing where IP address 242 selection considerations MUST be analyzed: The selection of IP 243 addresses for the DUT and the selection of addresses for test 244 traffic. 246 5.2.1. DUT Protocol Addresses 248 IANA reserved an IPv6 address block for use with IPv6 benchmark 249 testing (see section 8). It MAY be assumed that addresses in this 250 block are not globally routable and they MUST NOT be used as Internet 251 source or destination addresses. 253 Similar to RFC2544, Appendix C, addresses from the first half of this 254 range SHOULD be used for the ports viewed as input and addresses from 255 the other half of the range for the output ports. 257 The prefix length of the IPv6 addresses configured on the DUT 258 interfaces MUST fall into either of the following: 259 o Prefix length is /126 which would simulate a point-to-point link 260 for a core router. 261 o Prefix length is smaller or equal to /64. 262 No prefix lengths SHOULD be selected in the range between 64 and 128 263 except the 126 value mentioned above. 265 Note that /126 prefixes might not be always the best choice for 266 addressing point-to-point links such as back-to-back Ethernet unless 267 the autoprovisioning mechanism is disabled. Also, not all network 268 elements support addresses of this prefix length. 270 While with IPv6, the DUT interfaces can be configured with multiple 271 global unicast addresses, the methodology described in this document 272 does not require testing such a scenario. It is not expected that 273 such an evaluation would bring additional data regarding the 274 performance of the network element. 276 The Interface ID portion of global unicast IPv6 DUT addresses SHOULD 277 be set to ::1. There are no requirements in the selection of the 278 Interface ID portion of the link local IPv6 addresses. 280 It is recommended that multiple iterations of the benchmark tests be 281 conducted using the following prefix lengths: 48, 64, 126 and 128 for 282 the advertised traffic destination prefix. Other prefix lengths can 283 be used. However the indicated range reflects major prefix 284 boundaries expected to be present in IPv6 routing tables and they 285 should be representative to establish baseline performance metrics. 287 5.2.2. Test Traffic Protocol Addresses 289 IPv6 source and destination addresses for the test streams SHOULD 290 belong to the IPv6 range assigned by IANA as defined in section 8. 291 The source addresses SHOULD belong to one half of the range and the 292 destination addresses to the other, reflecting the DUT interface IPv6 293 address selection. 295 Tests SHOULD first be executed with a single stream leveraging a 296 single source-destination address pair. The tests SHOULD then be 297 repeated with traffic using a random destination address in the 298 corresponding range. If the network element prefix lookup 299 capabilities are evaluated, the tests SHOULD focus on the IPv6 300 relevant prefix boundaries: 0-64, 126 and 128. 302 Special care needs to be taken about the neighbor unreachability 303 detection (NUD) [3] process. The IPv6 prefix reachable time in the 304 router advertisement SHOULD be set to 30 seconds and allow 50% 305 jitter. The IPv6 source and destination addresses SHOULD not appear 306 to be directly connected to the DUT to avoid neighbor solicitation 307 (NS) and neighbor advertisement (NA) storms due to multiple test 308 traffic flows. 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 [8] 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 [5] 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 recommended selection. 458 However, they do not represent an all-inclusive list of upper layer 459 protocols which could be used in defining filters. 461 6.2.2. Filter Types 463 Based on RFC2544 recommendations, two types of tests are executed 464 when evaluating performance in the presence of modifiers: One with a 465 single filter and another with 25 filters. Examples of recommended 466 filters are illustrated using the IPv6 documentation prefix [10] 467 2001:DB8::. 469 Examples of single filters are: 471 Filter for TCP traffic - permit tcp 2001:DB8::1 2001:DB8::2 472 Filter for UDP traffic - permit udp 2001:DB8::1 2001:DB8::2 473 Filter for IPv6 traffic - permit ipv6 2001:DB8::1 2001:DB8::2 475 The single line filter case SHOULD verify that the network element 476 permits all TCP/UDP/IPv6 traffic with or without any number of 477 extension headers from IPv6 SA 2001:DB8::1 to IPv6 DA 2001:DB8::2 and 478 deny all other traffic. 480 Example of 25 filters: 482 deny tcp 2001:DB8:1::1 2001:DB8:1::2 483 deny tcp 2001:DB8:2::1 2001:DB8:2::2 484 deny tcp 2001:DB8:3::1 2001:DB8:3::2 485 ... 486 deny tcp 2001:DB8:C::1 2001:DB8:C::2 487 permit tcp 2001:DB8:99::1 2001:DB8:99::2 488 deny tcp 2001:DB8:D::1 2001:DB8:D::2 489 deny tcp 2001:DB8:E::1 2001:DB8:E::2 490 ... 491 deny tcp 2001:DB8:19::1 2001:DB8:19::2 492 deny ipv6 any any 494 The router SHOULD deny all traffic with or without extension headers 495 except TCP traffic with SA 2001:DB8:99::1 and DA 2001:DB8:99::2. 497 7. Benchmarking Tests 499 This document recommends the same benchmarking tests described in 500 RFC2544 while observing the DUT setup and the traffic setup 501 considerations described above. The following sections state the 502 test types explicitly and highlight only the methodology differences 503 that might exist with respect to those described in Section 26 of 504 RFC2544. 506 The specificities of IPv6, particularly the definition of extension 507 headers processing, require additional benchmarking steps. The tests 508 recommended by RFC2544 MUST be repeated for IPv6 traffic without 509 extension headers and for IPv6 traffic with one or multiple extension 510 headers. 512 IPv6's deployment in existing IPv4 environments and the expected long 513 co-existence of the two protocols leads network operators to place 514 great emphasis on understanding the performance of platforms 515 processing both types of traffic. While device resources are shared 516 between the two protocols, it is important that IPv6-enabled 517 platforms not experience degraded IPv4 performance. Thus, IPv6 518 benchmarking SHOULD be performed in the context of a stand alone 519 protocol as well as in the context of its co-existence with IPv4. 521 The modifiers defined are independent of extension header type so 522 they can be applied equally to each one of the above tests. 524 The benchmarking tests described in this section SHOULD be performed 525 under each of the following conditions: 527 Extension header specific conditions: 528 i) IPv6 traffic with no extension headers 529 ii) IPv6 traffic with one extension header from the list in 530 section 5.3 531 iii) IPv6 traffic with the chain of extension headers described in 532 section 5.3 534 Co-existence specific conditions: 535 iv) IPv4 ONLY traffic benchmarking 536 v) IPv6 ONLY traffic benchmarking 537 vi) IPv4-IPv6 traffic mix with the ratio 90% vs 10% 538 vii) IPv4-IPv6 traffic mix with the ratio 50% vs 50% 539 viii) IPv4-IPv6 traffic mix with the ratio 10% vs 90% 541 Combining the test conditions listed for benchmarking IPv6 as a 542 stand-alone protocol and the co-existence tests leads to a large 543 coverage matrix. At a minimum requirement, the co-existence tests 544 should use IPv6 traffic with no extension headers and the 10%-90%, 545 90%-10% IPv4/IPv6 traffic mix. 547 The subsequent sections each describe specific tests that MUST be 548 executed under the conditions listed above for a complete 549 benchmarking of IPv6 forwarding performance. 551 7.1. Throughput 553 Objective: To determine the DUT throughput as defined in RFC1242. 555 Procedure: Same as RFC2544. 557 Reporting Format: Same as RFC2544. 559 7.2. Latency 561 Objective: To determine the latency as defined in RFC1242. 563 Procedure: Same as RFC2544. 565 Reporting Format: Same as RFC2544. 567 7.3. Frame Loss 569 Objective: To determine the frame loss rate, as defined in RFC1242, 570 of a DUT throughout the entire range of input data rates and frame 571 sizes. 573 Procedure: Same as RFC2544. 575 Reporting Format: Same as RFC2544. 577 7.4. Back-to-Back Frames 579 Based on the IPv4 experience, the back-to-back frames test is 580 characterized by significant variance due to short term variations in 581 the processing flow. For these reasons, this test is no longer 582 recommended for IPv6 benchmarking. 584 7.5. System Recovery 586 Objective: To characterize the speed at which a DUT recovers from an 587 overload condition. 589 Procedure: Same as RFC2544. 591 Reporting Format: Same as RFC2544. 593 7.6. Reset 595 Objective: To characterize the speed at which a DUT recovers from a 596 device or software reset. 598 Procedure: Same as RFC2544. 600 Reporting Format: Same as RFC2544. 602 8. IANA Considerations 604 IANA reserved prefix xxxxx/48 for IPv6 benchmarking similar to 605 198.18.0.0/15 in RFC 3330 [9]. This prefix length provides similar 606 flexibility as the range allocated for IPv4 benchmarking and it is 607 taking into consideration address conservation and simplicity of 608 usage concerns. The requested size meets the requirements for 609 testing large network elements and large emulated networks. 611 Note to IANA: Replace "xxxxx" with assigned prefix. 613 9. Security Considerations 615 Benchmarking activities as described in this memo are limited to 616 technology characterization using controlled stimuli in a laboratory 617 environment, with dedicated address space and the constraints 618 specified in the sections above. 620 The benchmarking network topology will be an independent test setup 621 and MUST NOT be connected to devices that may forward the test 622 traffic into a production network, or misroute traffic to the test 623 management network. 625 Further, benchmarking is performed on a "black-box" basis, relying 626 solely on measurements observable external to the DUT/SUT. 628 Special capabilities SHOULD NOT exist in the DUT/SUT specifically for 629 benchmarking purposes. Any implications for network security arising 630 from the DUT/SUT SHOULD be identical in the lab and in production 631 networks. 633 The isolated nature of the benchmarking environments and the fact 634 that no special features or capabilities, other than those used in 635 operational networks, are enabled on the DUT/SUT requires no security 636 considerations specific to the benchmarking process. 638 10. Conclusions 640 The Benchmarking Methodology for Network Interconnect Devices 641 document, RFC2544 [8], is for the most part applicable to evaluating 642 the IPv6 performance of network elements. This document addresses 643 the IPv6 specific requirements that MUST be observed when applying 644 the recommendations of RFC2544. These additional requirements stem 645 from the architecture characteristics of IPv6. This document is not 646 a replacement of but a complement to RFC2544. 648 11. Acknowledgements 650 Scott Bradner provided valuable guidance and recommendations for this 651 document. The authors acknowledge the work done by Cynthia Martin 652 and Jeff Dunn with respect to defining the terminology for IPv6 653 benchmarking. The authors would like to thank Bill Kine for his 654 contribution to the initial document and to Tom Alexander, Bill 655 Cerveny, Silvija Dry, Sven Lanckmans, Dean Lee, Athanassios 656 Liakopoulos, Benoit Lourdelet, Al Morton, David Newman, Rajiv 657 Papejna, Dan Romascanu and Pekka Savola for their very helpful 658 feedback. Maryam Hamza inspired the authors in completing this 659 document. 661 12. References 663 12.1. Normative References 665 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 666 Levels", BCP 14, RFC 2119, March 1997. 668 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 669 Specification", RFC 2460, December 1998. 671 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 672 for IP Version 6 (IPv6)", RFC 2461, December 1998. 674 [4] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, 675 June 1999. 677 [5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 678 December 2005. 680 12.2. Informative References 682 [6] Bradner, S., "Benchmarking terminology for network 683 interconnection devices", RFC 1242, July 1991. 685 [7] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, 686 July 1994. 688 [8] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 689 Network Interconnect Devices", RFC 2544, March 1999. 691 [9] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. 693 [10] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 694 Reserved for Documentation", RFC 3849, July 2004. 696 [11] Newman, D. and T. Player, "Hash and Stuffing: Overlooked 697 Factors in Network Device Benchmarking", RFC 4814, March 2007. 699 [12] LAN/MAN Standards Committee of the IEEE Computer Society, "IEEE 700 Std 802.3as-2006, Part 3: Carrier Sense Multiple Access with 701 Collision Detection (CSMA/CD) Access Method and Physical Layer 702 Specifications, Amendment 3: Frame format extensions", 703 November 2006. 705 Appendix A. Theoretical Maximum Frame Rates Reference 707 This appendix provides the formulas to calculate and the values for 708 the theoretical maximum frame rates for two media types: Ethernet and 709 SONET. 711 A.1. Ethernet 713 The throughput in frames per second (fps) for various Ethernet 714 interface types and for a frame size X can be calculated with the 715 following formula: 717 Line Rate (bps) 718 ------------------------------ 719 (8bits/byte)*(X+20)bytes/frame 721 The 20 bytes in the formula is the sum of the preamble (8 bytes) and 722 the inter frame gap (12 bytes). The throughput for various Ethernet 723 interface types and frame sizes: 725 Size 10Mb/s 100Mb/s 1000Mb/s 10000Mb/s 726 Bytes pps pps pps pps 728 64 14,880 148,809 1,488,095 14,880,952 729 128 8,445 84,459 844,594 8,445,945 730 256 4,528 45,289 452,898 4,528,985 731 512 2,349 23,496 234,962 2,349,624 732 1024 1,197 11,973 119,731 1,197,318 733 1280 961 9,615 96,153 961,538 734 1518 812 8,127 81,274 812,743 735 2048 604 6,044 60,444 604,448 736 4096 303 3,036 30,396 303,691 737 8192 152 1,522 15,221 152,216 738 9216 135 1,353 13,534 135,339 740 Note: Ethernet's maximum frame rates are subject to variances due to 741 clock slop. The listed rates are theoretical maximums and actual 742 tests should account for a +/- 100 ppm tolerance. 744 A.2. Packet over SONET 746 ANSI T1.105 SONET provides the formula for calculating the maximum 747 available bandwidth for the various Packet over SONET (PoS) interface 748 types: 750 STS-Nc (N = 3Y, where Y=1,2,3,etc) 752 [(N*87) - N/3]*(9 rows)*(8 bit/byte)*(8000 frames/sec) 754 Packets over SONET can use various encapsulations: PPP [4], HDLC [7] 755 and Frame Relay. All these encapsulations use a 4-byte header, a 2- 756 or 4-byte FCS field and a 1-byte Flag which are all accounted for in 757 the overall frame size. The maximum frame rate for various interface 758 types can be calculated with the formula (where X represents the 759 frame size in bytes): 761 Line Rate (bps) 762 ------------------------------ 763 (8bits/byte)*(X+1)bytes/frame 765 The maximum throughput for various PoS interface types and frame 766 sizes: 768 Size OC-3c OC-12c OC-48c OC-192c OC-768c 769 Bytes fps fps fps fps fps 771 47 390,000 1,560,000 6,240,000 24,960,000 99,840,000 772 64 288,000 1,152,000 4,608,000 18,432,000 73,728,000 773 128 145,116 580,465 2,321,860 9,287,441 37,149,767 774 256 72,840 291,361 1,165,447 4,661,789 18,647,159 775 512 36,491 145,964 583,859 2,335,438 9,341,754 776 1024 18,263 73,053 292,214 1,168,858 4,675,434 777 2048 9,136 36,544 146,178 584,714 2,338,857 778 4096 4,569 18,276 73,107 292,428 1,169,714 780 It is important to note that throughput test results may vary from 781 the values presented in appendices A.1 and A.2 due to bit stuffing 782 performed by various media types [11]. The theoretical throughput 783 numbers were rounded down. 785 Authors' Addresses 787 Ciprian Popoviciu 788 Cisco Systems 789 Kit Creek Road 790 RTP, North Carolina 27709 791 USA 793 Phone: 919 787 8162 794 Email: cpopovic@cisco.com 795 Ahmed Hamza 796 Cisco Systems 797 3000 Innovation Drive 798 Kanata K2K 3E8 799 Canada 801 Phone: 613 254 3656 802 Email: ahamza@cisco.com 804 Gunter Van de Velde 805 Cisco Systems 806 De Kleetlaan 6a 807 Diegem 1831 808 Belgium 810 Phone: +32 2704 5473 811 Email: gunter@cisco.com 813 Diego Dugatkin 814 IXIA 815 26601 West Agoura Rd 816 Calabasas 91302 817 USA 819 Phone: 818 444 3124 820 Email: diego@ixiacom.com 822 Full Copyright Statement 824 Copyright (C) The IETF Trust (2007). 826 This document is subject to the rights, licenses and restrictions 827 contained in BCP 78, and except as set forth therein, the authors 828 retain all their rights. 830 This document and the information contained herein are provided on an 831 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 832 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 833 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 834 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 835 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 836 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 838 Intellectual Property 840 The IETF takes no position regarding the validity or scope of any 841 Intellectual Property Rights or other rights that might be claimed to 842 pertain to the implementation or use of the technology described in 843 this document or the extent to which any license under such rights 844 might or might not be available; nor does it represent that it has 845 made any independent effort to identify any such rights. Information 846 on the procedures with respect to rights in RFC documents can be 847 found in BCP 78 and BCP 79. 849 Copies of IPR disclosures made to the IETF Secretariat and any 850 assurances of licenses to be made available, or the result of an 851 attempt made to obtain a general license or permission for the use of 852 such proprietary rights by implementers or users of this 853 specification can be obtained from the IETF on-line IPR repository at 854 http://www.ietf.org/ipr. 856 The IETF invites any interested party to bring to its attention any 857 copyrights, patents or patent applications, or other proprietary 858 rights that may cover technology that may be required to implement 859 this standard. Please address the information to the IETF at 860 ietf-ipr@ietf.org. 862 Acknowledgment 864 Funding for the RFC Editor function is provided by the IETF 865 Administrative Support Activity (IASA).