IPv6 Benchmarking Draft - Please provide feedback

Subject: IPv6 Benchmarking Draft - Please provide feedback

From: "Chip Popoviciu \(cpopovic\)" <cpopovic@cisco.com>

Date: Thu, 8 Jun 2006 02:36:36 -0400

Authentication-results: sj-dkim-2.cisco.com; header.From=cpopovic@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; );

Cc: "Ahmed Hamza \(ahamza\)" <ahamza@cisco.com>, "Gunter Van de Velde \(gvandeve\)" <gvandeve@cisco.com>, "Diego Dugatkin" <diego@ixiacom.com>, "Kine, Bill" <Bill.Kine@SpirentCom.COM>, "Chip Popoviciu \(cpopovic\)" <cpopovic@cisco.com>

Dkim-signature: a=rsa-sha1; q=dns; l=54778; t=1149748599; x=1150612599; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=cpopovic@cisco.com; z=From:=22Chip=20Popoviciu=20\(cpopovic\)=22=20<cpopovic@cisco.com> |Subject:IPv6=20Benchmarking=20Draft=20-=20Please=20provide=20feedback; X=v=3Dcisco.com=3B=20h=3DEfHssjTyJq+nJlKpDVJlOi4ysrw=3D; b=cIs7PRi6dJG8Tz9ZPDuHWbJjRVkClJy8d33SasL1aEm5bFXK1LE6aBK4pXbLbAn2xwdwkg1v KDsmepWw/nCPeSNgN2nLOEJ+T6BXmVcNZ4Ty8FRavXrrdrgV8h3zDyfv;

Dear v6ops WG members,

We would like to ask for your feedback on an "IPv6 Benchmarking" draft (attached) we are working on within the Benchmarking Working Group. This work was started and is driven by the great demand we see for benchmarking guidelines on evaluating the IPv6 performance of network devices. This is a subject of great interest to those who deployed or consider the deployment of IPv6.

This draft follows, in structure and format, the recommendation of BMWG to be an IPv6 specific complement to RFC 2544 and not its replacement. As such, this document is referring the reader to RFC 2544 wherever possible and provides IPv6 specific updates wherever necessary. Recommendations are made on evaluating performance with mixed IPv4-IPv6 traffic as well. Note that in keeping with the spirit of RFC 2544, no benchmarking recommendations are made for tunneling mechanisms, the focus remaining on native forwarding. The attached version incorporates the feedback received on version -00 from BWMG members.

Considering the IPv6 operational expertise of this group, your comments and suggestions would be extremely valuable in developing and improving this document. Your feedback is most appreciated.

Best Regards,

Ciprian Popoviciu

for the authors of the draft

Network Working Group C. Popoviciu Internet-Draft A. Hamza Expires: October 3, 2006 G. Van de Velde Cisco Systems D. Dugatkin IXIA B. Kine Spirent April 2006 IPv6 Benchmarking Methodology <draft-popoviciu-bmwg-ipv6benchmarking-01.txt> Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 3, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Benchmarking Methodologies defined in RFC2544 [1] are IP version independent however, they do not address some of the specificities of IPv6. This document provides additional benchmarking guidelines Popoviciu, et al. Expires October 3, 2006 [Page 1] Internet-Draft IPv6 Performance Benchmarking April 2006 which in conjunction with RFC2544 will lead to a more complete and realistic evaluation of the IPv6 performance of network elements. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Tests and Results Evaluation . . . . . . . . . . . . . . . . . 3 3. Test Environment Set Up . . . . . . . . . . . . . . . . . . . 3 4. Test Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Frame Formats and Sizes . . . . . . . . . . . . . . . . . 4 4.1.1. Frame Sizes to be used on Ethernet . . . . . . . . . . 5 4.1.2. Frame Sizes to be used on SONET . . . . . . . . . . . 5 4.2. Protocol Addresses Selection . . . . . . . . . . . . . . . 5 4.2.1. DUT Protocol Addresses . . . . . . . . . . . . . . . . 5 4.2.2. Test Traffic Protocol Addresses . . . . . . . . . . . 6 4.3. Traffic with Extension Headers . . . . . . . . . . . . . . 6 4.4. Traffic set up . . . . . . . . . . . . . . . . . . . . . . 8 5. Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Management and Routing Traffic . . . . . . . . . . . . . . 8 5.2. Filters . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2.1. Filter Format . . . . . . . . . . . . . . . . . . . . 8 5.2.2. Filter Types . . . . . . . . . . . . . . . . . . . . . 9 6. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 12 6.4. Back-to-Back Frames . . . . . . . . . . . . . . . . . . . 12 6.5. System Recovery . . . . . . . . . . . . . . . . . . . . . 12 6.6. Reset . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. Maximum Frame Rates Reference . . . . . . . . . . . . 14 A.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.2. Packet over SONET . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Popoviciu, et al. Expires October 3, 2006 [Page 2] Internet-Draft IPv6 Performance Benchmarking April 2006 1. Introduction The benchmarking methodologies defined by RFC2544 [1] are proving to be very useful in consistently evaluating IPv4 forwarding performance of network elements. Adherence to these testing and result analysis procedures facilitates the objective comparison of product IPv4 performance. While the principles behind the methodologies introduced in RFC2544 are largely IP version independent, the protocol continued to evolve, particularly in its version 6 (IPv6). This document provides benchmarking methodology recommendations that address IPv6 specific aspects such as evaluating the forwarding performance of traffic containing Extension Headers as defined in RFC2460 [4]. These recommendations are defined within the RFC2544 framework and are meant to complement the test and result analysis procedures described in RFC2544 and not to replace them. The terms used in this document remain consistent with those defined in "Benchmarking Terminology for Network Interconnect Devices" [2]. This terminology document SHOULD be consulted before using or applying the recommendations of this document. Any methodology aspects not covered in this document SHOULD be assumed to be treated based on the RFC2544 recommendations. 2. Tests and Results Evaluation The recommended performance evaluation tests are described in Section 6 of this document. Not all these tests are applicable to all network element types. Nevertheless, for each evaluated device, all applicable tests described in Section 6 MUST be performed. Test execution and the results analysis MUST be performed while observing generally accepted testing practices regarding repeatability, variance and statistical significance of small numbers of trials. 3. Test Environment Set Up The test environment setup options recommended for the IPv6 performance evaluation are the same to the ones described in Section 6 of RFC2544, in both single-port and multi-port scenarios. Single- port testing is used in measuring per interface forwarding performance while multi-port testing is used to measure the scalability of this performance across the entire platform. Popoviciu, et al. Expires October 3, 2006 [Page 3] Internet-Draft IPv6 Performance Benchmarking April 2006 Throughout the test, the DUT MUST be monitored for relevant resource (Processor, Memory, etc.) utilization. This data is important in understanding traffic processing by each DUT and the resources that must be allocated for IPv6. It reveals if the IPv6 is processed in hardware, by applicable devices, under all test conditions or it is punted in the software switched path. The data collection MUST be done out of band and independent of any management data that might be recommended to be collected through the interfaces forwarding the test traffic. Note: During testing, either static or dynamic Neighbor Discovery can be used. The static option can be used as long as it is supported by the test tools. The dynamic option is however preferred if the test tool interacts with the DUT during the duration of the test in order to maintain the respective neighbor caches active. The above described test scenarios stem from the assumption that the test traffic end points, the IPv6 source and destination addresses are not directly attached to the DUT, but is seen as one hop beyond, to avoid Neighbor Solicitation (NS) and Neighbor Advertisement (NA) storms due to the Neighbor Unreachability Detection (NUD) mechanism [5]. 4. Test Traffic The traffic used for all tests described in this document SHOULD meet the requirements described in this section. These requirements are designed to reflect the characteristics of IPv6 unicast traffic in all its aspects. Using this IPv6 traffic leads to a complete evaluation of the network element performance. 4.1. Frame Formats and Sizes Two types of media are commonly deployed and SHOULD be tested: Ethernet and SONET. This section identifies the frame sizes that SHOULD be used for each media type. For all other media types refer to the recommendations of RFC2544. Similar to IPv4, small frame sizes help characterize the per-frame processing overhead of the DUT. Note that the minimum size of a relevant IPv6 packet (it carries minimal upper layer information) is larger than that of an IPv4 packet because the former has a 40 bytes long header while the later has a minimum header of 20 bytes. The frame sizes listed for IPv6 include the extension headers used in testing (see section 4.3). By definition, extension headers are part of the IPv6 packet payload. Depending on the total length of the extension headers, their use might not be possible at the smallest frame sizes. Popoviciu, et al. Expires October 3, 2006 [Page 4] Internet-Draft IPv6 Performance Benchmarking April 2006 4.1.1. Frame Sizes to be used on Ethernet Ethernet in all its types has become the most commonly deployed interface in today's networks. The following frame sizes SHOULD be used for testing the IPv6 forwarding performance over this media type: 64, 128, 256, 512, 1024, 1280, 1518 bytes. The maximum frame rates for each frame size and the various Ethernet interface types are provided in Appendix A. 4.1.2. Frame Sizes to be used on SONET The Packet over SONET (PoS) interfaces are commonly used for core uplinks and high bandwidth core links. For this reason it is recommended to evaluate the forwarding performance of such interfaces if present or are an option in the DUT. The recommended layer 2 packet sizes for this media type are: 64, 128, 256, 512, 1024, 1280, 1518, 2048, 4096 bytes. The maximum frame rates for each frame size and the various Ethernet interface types are provided in Appendix A. 4.2. Protocol Addresses Selection There are two aspects of the IPv6 benchmarking testing where IP address selection considerations MUST be analyzed: The selection of IP addresses for the DUT and the selection of addresses for the test traffic. 4.2.1. DUT Protocol Addresses There is no IPv6 address range reserved for the Benchmarking Methodology Working Group. In order to maintain the consistency with the IPv4 benchmarking recommendations, IANA SHOULD reserve an IPv6 benchmarking prefix similar to 192.18.0.0 in RFC 3330 [7]. Similar to the RFC2544, Appendix C, addresses from the first half of this range SHOULD be used for the ports viewed as input and addresses from the other half of the range for the output ports. The prefix length of the IPv6 addresses configured on the DUT interfaces MUST fall into either one of the following two categories: o Prefix length is /126 which would simulate a point-to-point link for a core router. o Prefix length is smaller or equal to /64. No prefix lengths SHOULD be selected in the range between 64 and 128 except the 126 value mentioned above. Note that /126 prefixes might not be always the best choice for addressing point-to-point links such as back-to-back Ethernet unless the autoprovisioning mechanism is disabled. Also, not all network elements support this type of addresses. Popoviciu, et al. Expires October 3, 2006 [Page 5] Internet-Draft IPv6 Performance Benchmarking April 2006 While with IPv6, the DUT interfaces can be configured with multiple global unicast prefixes, the methodology described in this document does not require testing such a scenario. It is not expected that such an evaluation would bring additional data with respect to the performance of the network element. The Interface ID portion of the Global Unicast IPv6 DUT addresses MUST be set to ::1. There are no requirements in the selection of the Interface ID portion of the Link Local IPv6 addresses. It is recommended that multiple iterations of the benchmark tests be conducted using the following prefix lengths: 32, 48, 64, 126 and 128. Other prefix lengths can also be used if desired, however the indicated range should be sufficient to establish baseline performance metrics. 4.2.2. Test Traffic Protocol Addresses The IPv6 addresses used as sources and destinations for the test streams SHOULD belong to the IPv6 range to be assigned by IANA as discussed in section 4.2.1. The source addresses SHOULD belong to one half of the range and the destination addresses to the other, reflecting the DUT interface IPv6 address selection. Tests SHOULD first be executed with a single stream leveraging a single source-destination address pair. The tests SHOULD then be repeated with traffic using a random destination address in the corresponding range. If the network element prefix lookup capabilities are evaluated, the tests SHOULD focus on the IPv6 relevant prefix boundaries: 0-64, 126 and 128. Special care needs to be taken about the Neighbor Unreachability Detection (NUD) [5] 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 appear not to be directly connected to the NUD to avoid Neighbor Solicitation (NS) and Neighbor Advertisement (NA) storms due to multiple test traffic flows. 4.3. Traffic with Extension Headers Extension Headers (EH) are an intrinsic part of the IPv6 architecture [4] . They are used with various types of practical traffic such as: Fragmented traffic, Mobility based traffic, Authenticated and Encrypted traffic. For these reasons, all tests described in this document SHOULD be performed with both traffic that has no EH and traffic that has a set of EH selected from the following list: Popoviciu, et al. Expires October 3, 2006 [Page 6] Internet-Draft IPv6 Performance Benchmarking April 2006 o Hop-by-Hop header o Destination Options header o Routing header o Fragment header o Authentication header o Encapsulating Security Payload header o Destination Options header o Mobility header The Hop-by-Hop extension header MUST be processed by each node so a test with traffic containing this EH type will not measure the forwarding performance of the DUT but rather its EH processing ability which is dependent on the information contained by the EH. The processing of IPv6 packets with Hop-by-Hop EH by network elements is similar to the processing of IPv4 packets with IP options. This is distinctly different from the way the other IPv6 EH must be handled where the traffic can be forwarded in the fast path without full EH processing. In agreement with RFC2544 omission of tests with IPv4 traffic that includes IP options, this document makes no benchmarking recommendations for traffic with IPv6 traffic with the Hop-by-Hop extension header. All IPv6 test traffic containing extension headers SHOULD contain a combination of two or more EH. Since the DUT is not analyzing the content of the EH, a combination of structure-less EH can be used in testing such as: o Destination Options header - 8 bytes o Routing header - 24-32 bytes o Fragment header - 8 bytes o Authentication header - 16 bytes The recommended set excludes the Hop-by-Hop EH based on the above analysis. It also excludes the ESP EH since traffic with an encrypted payload could not be used in tests with modifiers such as filters based on upper layer information (see Section 5). The recommended headers are commonly used with IPv6 traffic for various services. The listed EH lengths represent test tool defaults. The total length of the EH chain SHOULD be larger than 32 bytes. These extension headers add extra bytes to the payload size of the IP packets which MUST be factored in when used in testing at low frame sizes. Their presence will modify the minimum size used in testing. For direct comparison between the data obtained with traffic that has EH and with traffic that doesn't have them, at low frame size, a common bottom size SHOULD be selected for both types of traffic. For the most cases, the network elements ignore the EH when forwarding IPv6 traffic. For these reasons it is most likely that Popoviciu, et al. Expires October 3, 2006 [Page 7] Internet-Draft IPv6 Performance Benchmarking April 2006 the EH related performance impact will be observed only when testing the DUT with traffic filters that contain matching conditions for the upper layer protocol information. In those cases, the DUT MUST traverse the chain of EH, a process that could impact performance. 4.4. Traffic set up All tests recommended in this document SHOULD be performed with bi- directional traffic. For asymmetric situations, tests MAY be performed with unidirectional traffic for a more granular characterization of the DUT performance. In these cases, the bidirectional traffic testing would reveal only the worst performance between the two directions. All other traffic profile characteristics described in RFC2544 SHOULD be applied in this testing as well. 5. Modifiers RFC2544 underlines the importance of evaluating the performance of network elements under certain operational conditions. The conditions defined in RFC2544 Section 11 are common to IPv4 and IPv6 with the exception of Broadcast Frames. IPv6 does not use layer 2 or layer 3 broadcasts. This section provides additional conditions that are specific to IPv6. The suite of tests recommended in this document SHOULD be first executed in the absence of these conditions and then repeated under each of the conditions separately. 5.1. Management and Routing Traffic The procedures defined in RFC2544 sections 11.2 and 11.3 are applicable for IPv6 Management and Routing Update Frames as well. 5.2. Filters The filters defined in Section 11.4 of RFC2544 apply to IPv6 benchmarking as well. The filter definitions however must be expanded to include upper layer protocol information matching in order to analyze the handling of traffic with Extension Headers (EH) which are an important architectural component of IPv6. 5.2.1. Filter Format The filter format defined in RFC2544 is applicable to IPv6 as well except that the Source Addresses (SA) and Destination Addresses (DA) are IPv6. In addition to these basic filters, the evaluation of IPv6 performance SHOULD analyze the handling of traffic with Extension Popoviciu, et al. Expires October 3, 2006 [Page 8] Internet-Draft IPv6 Performance Benchmarking April 2006 Headers. While the intent is not to evaluate a platform's capability to process the various extension header types, the goal is to measure the impact on performance when the network element must parse through the EH in order to reach upper layer information. In IPv6 routers do not have to parse through the extension headers (other than Hop-by- Hop) unless the upper layer information has to be analyzed due to filters for example. For this reasons, in order to evaluate the network element handling of IPv6 traffic with EH, the definition of the filters must be extended to include conditions applied to upper layer protocol information. The following filter format SHOULD be use for this type of evaluation: [permit|deny] [protocol] [SA] [DA] where permit or deny indicates the action to allow or deny a packet through the interface the filter is applied to. The Protocol field is defined as: o ipv6: any IP Version 6 traffic o tcp: Transmission Control Protocol o udp: User Datagram Protocol and SA stands for the Source Address and DA for the Destination Address. 5.2.2. Filter Types Based on the RFC2544 recommendations, two types of tests are executed when evaluating performance in the presence of modifiers. One with a single filter and one with 25 filters. The recommended filters are exemplified with the help of the IPv6 documentation prefix [8] 2001: DB8::. Examples of single filters are: Filter for TCP traffic - permit tcp 2001:DB8::1 2001:DB8::2 Filter for UDP traffic - permit udp 2001:DB8::1 2001:DB8::2 Filter for IPv6 traffic - permit ipv6 2001:DB8::1 2001:DB8::2 The single line filter case SHOULD verify that the network element permits all TCP/UDP/IPv6 traffic with or without any number of Extension Headers from IPv6 SA 2001:DB8::1 to IPv6 DA 2001:DB8::2 and deny all other traffic. Popoviciu, et al. Expires October 3, 2006 [Page 9] Internet-Draft IPv6 Performance Benchmarking April 2006 Example of 25 filters: deny tcp 2001:DB8:1::1 2001:DB8:1::2 deny tcp 2001:DB8:2::1 2001:DB8:2::2 deny tcp 2001:DB8:3::1 2001:DB8:3::2 ... deny tcp 2001:DB8:C::1 2001:DB8:C::2 permit tcp 2001:DB8:99::1 2001:DB8:99::2 deny tcp 2001:DB8:D::1 2001:DB8:D::2 deny tcp 2001:DB8:E::1 2001:DB8:E::2 ... deny tcp 2001:DB8:19::1 2001:DB8:19::2 deny ipv6 any any The router SHOULD deny all traffic with or without extension headers except TCP traffic with SA 2001:DB8:99::1 and DA 2001:DB8:99::2. 6. Benchmarking Tests This document recommends the same benchmarking tests described in RFC2544 while observing the DUT setup and the traffic setup considerations described above. The following sections state the test types explicitly and highlight only the methodology differences that might exist with respect to those described in Section 26 of RFC2544. The specificities of IPv6, particularly the definition of EH processing, require additional benchmarking steps. In this sense, the tests recommended by RFC2544 MUST be repeated for IPv6 traffic without and with one or multiple extension header. The testing approach that addresses this aspect of the protocol in a systematic manner is presented below. The benchmarking tests described in this section SHOULD be performed under each of the following conditions: IPv6 traffic with no extension headers IPv6 traffic with one extension header from the list in section 5.3 IPv6 traffic with the chain of extension headers described in section 5.3 The modifiers defined are independent of EH type so they can be applied equally to each one of the above tests. IPv6's deployment in existent IPv4 environments and the expected long co-existence of the two protocols leads network operators to place Popoviciu, et al. Expires October 3, 2006 [Page 10] Internet-Draft IPv6 Performance Benchmarking April 2006 great emphasis on understanding the performance of platforms forwarding both types of traffic. While resource sharing between the two protocols, it is important for IPv6 enabled platforms to not experience degraded IPv4 performance. In this context the IPv6 benchmarking SHOULD be performed in the context of a stand alone protocol as well as in the context of its co-existence with IPv4. The benchmarking tests described in this section SHOULD be performed under each of the following conditions evaluating the IPv6-IPv4 co- existence: IPv4 ONLY traffic benchmarking IPv6 ONLY traffic benchmarking IPv4-IPv6 traffic mix with the ration 90% vs 10% IPv4-IPv6 traffic mix with the ration 50% vs 50% IPv4-IPv6 traffic mix with the ration 10% vs 90% Combining the test conditions listed for benchmarking IPv6 as a stand-alone protocol and the co-existence tests leads to a large coverage matrix. A minimum requirement is to cover the co-existence conditions in the case of where IPv6 with no extension headers is used. The subsequent sections describe each specific tests that MUST be executed under the conditions listed above for a complete benchmarking of IPv6 forwarding performance. 6.1. Throughput Objective: To determine the DUT throughput as defined in RFC1242. Procedure: Same as RFC2544. Reporting Format: Same as RFC2544. While reporting the network element performance at the minimum frame size might be of interest, it is recommended that the performance at the IMIX average frame size or higher SHOULD also be reported. This data point would have a more useful value in practice. 6.2. Latency Objective: To determine the latency as defined in RFC1242. Procedure: Same as RFC2544. Reporting Format: Same as RFC2544. Popoviciu, et al. Expires October 3, 2006 [Page 11] Internet-Draft IPv6 Performance Benchmarking April 2006 6.3. Frame Loss Objective: To determine the frame loss rate, as defined in RFC1242, of a DUT throughout the entire range of input data rates and frame sizes. Procedure: Same as RFC2544. Reporting Format: Same as RFC2544. 6.4. Back-to-Back Frames Objective: To characterize the ability of a DUT to process back-to- back frames as defined in RFC1242. Procedure: Same as RFC2544. Reporting Format: Same as RFC2544. 6.5. System Recovery Objective: To characterize the speed at which a DUT recovers from an overload condition. Procedure: Same as RFC2544. Reporting Format: Same as RFC2544. 6.6. Reset Objective: To characterize the speed at which a DUT recovers from a device or software reset. Procedure: Same as RFC2544. Reporting Format: Same as RFC2544. 7. IANA Considerations IANA SHOULD reserve an IPv6 prefix for benchmarking purposes similar to 192.18.0.0 in RFC 3330 [7]. 8. Security Considerations There are no security issues that are or need to be addressed in this document. Popoviciu, et al. Expires October 3, 2006 [Page 12] Internet-Draft IPv6 Performance Benchmarking April 2006 9. Conclusions The Benchmarking Methodology for Network Interconnect Devices document, RFC2544 [1], is for the most part applicable to evaluating the IPv6 performance of network elements. This document is addressing the IPv6 specific requirements that MUST be observed when applying the recommendations of RFC2544. These additional requirements stem from the architecture characteristics of IPv6. This document is not a replacement of but a complement to RFC2544. 10. Acknowledgements Scott Bradner provided valuable guidance and recommendations for this document. The authors acknowledge the work done by Cynthia Martin and Jeff Dunn with respect to defining the terminology for IPv6 benchmarking. The authors would also like to thank Benoit Lourdelet for his feedback. 11. References 11.1. Normative References [1] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999. 11.2. Informative References [2] Bradner, S., "Benchmarking terminology for network interconnection devices", RFC 1242, July 1991. [3] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994. [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [5] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [6] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999. [7] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. [8] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004. Popoviciu, et al. Expires October 3, 2006 [Page 13] Internet-Draft IPv6 Performance Benchmarking April 2006 Appendix A. Maximum Frame Rates Reference This appendix provides the formulas to calculate and the values for the maximum frame rates for two media types: Ethernet and SONET. A.1. Ethernet The maximum throughput in frames per second (fps) for various Ethernet interface types and for a frame size X can be calculated with the following formula: Line Rate (bps) ------------------------------ (8bits/byte)*(X+20)bytes/frame The 20 bytes in the formula is the sum of the Preamble (8 bytes) and the Inter Frame Gap (12 bytes). The calculated maximum throughput values for each Ethernet interface type and frame size can be found in Appendix B of RFC2544. A.2. Packet over SONET ANSI T1.105 SONET provides the formula for calculating the maximum available bandwidth for the various Packet over SONET (PoS) interface types: STS-Nc (N = 3X, where X=1,2,3,etc) [(N*87) - N/3]*(9 rows)*(8 bit/byte)*(8000 frames/sec) Packets over SONET can use various encapsulations: PPP [6], HDLC [3] and Frame Relay. All these encapsulations use a 4 bytes header, a 2 or 4 bytes FCS field and a 1 byte Flag. The maximum frame rate for various interface types can be calculated with the formula: Line Rate (bps) ------------------------------ (8bits/byte)*(X+1)bytes/frame The maximum throughput for various PoS interface types and frame sizes: Popoviciu, et al. Expires October 3, 2006 [Page 14] Internet-Draft IPv6 Performance Benchmarking April 2006 Size OC-3 OC-12 OC-48 OC-192 OC-768 Bytes fps fps fps fps fps 64 288,000 1,152,000 4,608,000 18,432,000 73,728,000 128 145,116 580,465 2,321,860 9,287,442 37,149,767 256 72,840 291,362 1,165,447 4,661,790 18,647,160 512 36,491 145,965 583,860 2,335,439 9,341,754 1024 18,263 73,054 292,215 1,168,859 4,675,434 2048 9,136 36,545 146,179 584,714 2,338,858 4096 4,569 18,277 73,107 292,429 1,169,714 Popoviciu, et al. Expires October 3, 2006 [Page 15] Internet-Draft IPv6 Performance Benchmarking April 2006 Authors' Addresses Ciprian Popoviciu Cisco Systems Kit Creek Road RTP, North Carolina 27709 USA Phone: 919 787 8162 Email: cpopovic@cisco.com Ahmed Hamza Cisco Systems 3000 Innovation Drive Kanata K2K 3E8 Canada Phone: 613 254 3656 Email: ahamza@cisco.com Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium Phone: +32 2704 5473 Email: gunter@cisco.com Diego Dugatkin IXIA 26601 West Agoura Rd Calabasas 91302 USA Phone: 818 444 3124 Email: diego@ixiacom.com Popoviciu, et al. Expires October 3, 2006 [Page 16] Internet-Draft IPv6 Performance Benchmarking April 2006 Bill Kine Spirent 1515 Seal Way Seal Beach 90740 USA Phone: 562 598 0631 Email: Bill.Kine@SpirentCom.COM Popoviciu, et al. Expires October 3, 2006 [Page 17] Internet-Draft IPv6 Performance Benchmarking April 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Popoviciu, et al. Expires October 3, 2006 [Page 18]