draft-ietf-bmwg-ipv6-meth-00.txt   draft-ietf-bmwg-ipv6-meth-01.txt 
Network Working Group C. Popoviciu Network Working Group C. Popoviciu
Internet-Draft A. Hamza Internet-Draft A. Hamza
Expires: July 6, 2007 G. Van de Velde Expires: July 5, 2007 G. Van de Velde
Cisco Systems Cisco Systems
D. Dugatkin D. Dugatkin
IXIA IXIA
January 2, 2007 January 2007
IPv6 Benchmarking Methodology IPv6 Benchmarking Methodology
<draft-ietf-bmwg-ipv6-meth-00.txt> <draft-ietf-bmwg-ipv6-meth-01.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 6, 2007. This Internet-Draft will expire on July 5, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Benchmarking Methodologies defined in RFC2544 [2] are IP version The Benchmarking Methodologies defined in RFC2544 [2] are IP version
independent however, they do not address some of the specificities of independent however, they do not address some of the specificities of
IPv6. This document provides additional benchmarking guidelines IPv6. This document provides additional benchmarking guidelines
which in conjunction with RFC2544 will lead to a more complete and which in conjunction with RFC2544 lead to a more complete and
realistic evaluation of the IPv6 performance of network elements. realistic evaluation of the IPv6 performance of network elements.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 3 2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 3
3. Tests and Results Evaluation . . . . . . . . . . . . . . . . . 3 3. Tests and Results Evaluation . . . . . . . . . . . . . . . . . 3
4. Test Environment Set Up . . . . . . . . . . . . . . . . . . . 4 4. Test Environment Set Up . . . . . . . . . . . . . . . . . . . 4
5. Test Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Test Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Frame Formats and Sizes . . . . . . . . . . . . . . . . . 4 5.1. Frame Formats and Sizes . . . . . . . . . . . . . . . . . 4
skipping to change at page 3, line 10 skipping to change at page 3, line 10
A.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 15
A.2. Packet over SONET . . . . . . . . . . . . . . . . . . . . 16 A.2. Packet over SONET . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
The benchmarking methodologies defined by RFC2544 [2] are proving to The benchmarking methodologies defined by RFC2544 [2] are proving to
be very useful in consistently evaluating IPv4 forwarding performance be very useful in consistently evaluating IPv4 forwarding performance
of network elements. Adherence to these testing and result analysis of network elements. Adherence to these testing and result analysis
procedures facilitates objective comparison of product IPv4 procedures facilitates objective comparison of IPv4 performance data
performance. While the principles behind the methodologies measured on various products and by various individuals. While the
introduced in RFC2544 are largely IP version independent, the principles behind the methodologies introduced in RFC2544 are largely
protocol continued to evolve, particularly in its version 6 (IPv6). IP version independent, the protocol continued to evolve,
particularly in its version 6 (IPv6).
This document provides benchmarking methodology recommendations that This document provides benchmarking methodology recommendations that
address IPv6 specific aspects such as evaluating the forwarding address IPv6 specific aspects such as evaluating the forwarding
performance of traffic containing extension headers as defined in performance of traffic containing extension headers as defined in
RFC2460 [5]. These recommendations are defined within the RFC2544 RFC2460 [5]. These recommendations are defined within the RFC2544
framework and are meant to complement the test and result analysis framework and are meant to complement the test and result analysis
procedures described in RFC2544 and not to replace them. procedures as described in RFC2544 and not to replace them.
The terms used in this document remain consistent with those defined The terms used in this document remain consistent with those defined
in "Benchmarking Terminology for Network Interconnect Devices" [3]. in "Benchmarking Terminology for Network Interconnect Devices" [3].
This terminology document SHOULD be consulted before using or This terminology SHOULD be consulted before using or applying the
applying the recommendations of this document. recommendations of this document.
Any methodology aspects not covered in this document SHOULD be Any methodology aspects not covered in this document SHOULD be
assumed to be treated based on the RFC2544 recommendations. assumed to be treated based on the RFC2544 recommendations.
2. Existing Definitions 2. Existing Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [1]. document are to be interpreted as described in BCP 14, RFC 2119 [1].
RFC 2119 defines the use of these key words to help make the intent RFC 2119 defines the use of these key words to help make the intent
skipping to change at page 4, line 13 skipping to change at page 4, line 14
repeatability, variance and statistical significance of small numbers repeatability, variance and statistical significance of small numbers
of trials. of trials.
4. Test Environment Set Up 4. Test Environment Set Up
The test environment setup options recommended for the IPv6 The test environment setup options recommended for the IPv6
performance evaluation are the same as the ones described in Section performance evaluation are the same as the ones described in Section
6 of RFC2544, in both single-port and multi-port scenarios. Single- 6 of RFC2544, in both single-port and multi-port scenarios. Single-
port testing is used in measuring per interface forwarding port testing is used in measuring per interface forwarding
performance while multi-port testing is used to measure the performance while multi-port testing is used to measure the
scalability of this performance across the entire platform. scalability of forwarding performance across the entire platform.
Throughout the test, the DUT can be monitored for relevant resource Throughout the test, the DUT can be monitored for relevant resource
(Processor, Memory, etc.) utilization. This data could be beneficial (Processor, Memory, etc.) utilization. This data could be beneficial
in understanding traffic processing by each DUT and the resources in understanding traffic processing by each DUT and the resources
that must be allocated for IPv6. It could reveal if the IPv6 traffic that must be allocated for IPv6. It could reveal if the IPv6 traffic
is processed in hardware, by applicable devices, under all test is processed in hardware, by applicable devices, under all test
conditions or it is punted in the software switched path. If such conditions or it is punted in the software switched path. If such
data is considered of interest, it MUST be collected out of band and data is considered of interest, it MUST be collected out of band and
independent of any management data that might be recommended to be independent of any management data that might be recommended to be
collected through the interfaces forwarding the test traffic. collected through the interfaces forwarding the test traffic.
Note: During testing, either static or dynamic options for neighbor Note: During testing, either static or dynamic options for neighbor
discovery can be used. The static option can be used as long as it discovery can be used. The static option can be used as long as it
is supported by the test tool. The dynamic option is preferred if is supported by the test tool. The dynamic option is preferred if
the test tool interacts with the DUT for the duration of the test to the test tool interacts with the DUT for the duration of the test to
maintain the respective neighbor caches in an active state. The test maintain the respective neighbor caches in an active state. The test
scenarios assume the test traffic end points and the IPv6 source and scenarios assume the test traffic simulated end points and the IPv6
destination addresses are not directly attached to the DUT, but are source and destination addresses are not directly attached to the
seen as one hop beyond, to avoid Neighbor Solicitation (NS) and DUT, but are seen as one hop beyond, to avoid Neighbor Solicitation
Neighbor Advertisement (NA) storms due to the Neighbor Unreachability (NS) and Neighbor Advertisement (NA) storms due to the Neighbor
Detection (NUD) mechanism [6]. Unreachability Detection (NUD) mechanism [6].
5. Test Traffic 5. Test Traffic
The traffic used for all tests described in this document SHOULD meet The traffic used for all tests described in this document SHOULD meet
the requirements described in this section. These requirements are the requirements described in this section. These requirements are
designed to reflect the characteristics of IPv6 unicast traffic in designed to reflect the characteristics of IPv6 unicast traffic in
all its aspects. Using this IPv6 traffic leads to a complete all its aspects. Using the recommended IPv6 traffic profile leads to
evaluation of the network element performance. a complete evaluation of the network element performance.
5.1. Frame Formats and Sizes 5.1. Frame Formats and Sizes
Two types of media are commonly deployed and SHOULD be tested: Two types of media are commonly deployed and SHOULD be tested:
Ethernet and SONET. This section identifies the frame sizes that Ethernet and SONET. This section identifies the frame sizes that
SHOULD be used for each media type. Refer to recommendations in SHOULD be used for each media type. Refer to recommendations in
RFC2544 for all other media types. RFC2544 for all other media types.
Similar to IPv4, small frame sizes help characterize the per-frame Similar to IPv4, small frame sizes help characterize the per-frame
processing overhead of the DUT. Note that the minimum IPv6 packet processing overhead of the DUT. Note that the minimum IPv6 packet
skipping to change at page 5, line 28 skipping to change at page 5, line 29
Ethernet in all its types has become the most commonly deployed Ethernet in all its types has become the most commonly deployed
interface in today's networks. The following frame sizes SHOULD be interface in today's networks. The following frame sizes SHOULD be
used for benchmarking over this media type: 64, 128, 256, 512, 1024, used for benchmarking over this media type: 64, 128, 256, 512, 1024,
1280, 1518 bytes. The 4096, 8192, 9216 bytes long jumbo frame sizes 1280, 1518 bytes. The 4096, 8192, 9216 bytes long jumbo frame sizes
SHOULD be used when benchmarking Gigabit Ethernet interfaces. The SHOULD be used when benchmarking Gigabit Ethernet interfaces. The
maximum frame rates for each frame size and the various Ethernet maximum frame rates for each frame size and the various Ethernet
interface types are provided in Appendix A. interface types are provided in Appendix A.
5.1.2. Frame Sizes to be used on SONET 5.1.2. Frame Sizes to be used on SONET
Packet over SONET (PoS) interfaces are commonly used for core uplinks Packet over SONET (PoS) interfaces are commonly used for edge uplinks
and high bandwidth core links. Evaluating the forwarding performance and high bandwidth core links. Evaluating the forwarding performance
of PoS interfaces supported by the DUT is recommended. The following of PoS interfaces supported by the DUT is recommended. The following
frame sizes SHOULD be used for this media type: 64, 128, 256, 512, frame sizes SHOULD be used for this media type: 64, 128, 256, 512,
1024, 1280, 1518, 2048, 4096 bytes. The maximum frame rates for each 1024, 1280, 1518, 2048, 4096 bytes. The maximum frame rates for each
frame size and the various PoS interface types are provided in frame size and the various PoS interface types are provided in
Appendix A. Appendix A.
5.2. Protocol Addresses Selection 5.2. Protocol Addresses Selection
There are two aspects of IPv6 benchmarking testing where IP address There are two aspects of IPv6 benchmarking testing where IP address
skipping to change at page 6, line 37 skipping to change at page 6, line 39
It is recommended that multiple iterations of the benchmark tests be It is recommended that multiple iterations of the benchmark tests be
conducted using the following lengths: 32, 48, 64, 126 and 128 for conducted using the following lengths: 32, 48, 64, 126 and 128 for
the advertised traffic destination prefix. Other prefix lengths can the advertised traffic destination prefix. Other prefix lengths can
also be used if desired, however the indicated range should be also be used if desired, however the indicated range should be
sufficient to establish baseline performance metrics. sufficient to establish baseline performance metrics.
5.2.2. Test Traffic Protocol Addresses 5.2.2. Test Traffic Protocol Addresses
The IPv6 source and destination addresses for the test streams SHOULD The IPv6 source and destination addresses for the test streams SHOULD
belong to the IPv6 range to be assigned by IANA as discussed in belong to the IPv6 range assigned by IANA as discussed in section
section 4.2.1. The source addresses SHOULD belong to one half of the 4.2.1. The source addresses SHOULD belong to one half of the range
range and the destination addresses to the other, reflecting the DUT and the destination addresses to the other, reflecting the DUT
interface IPv6 address selection. interface IPv6 address selection.
Tests SHOULD first be executed with a single stream leveraging a Tests SHOULD first be executed with a single stream leveraging a
single source-destination address pair. The tests SHOULD then be single source-destination address pair. The tests SHOULD then be
repeated with traffic using a random destination address in the repeated with traffic using a random destination address in the
corresponding range. If the network element prefix lookup corresponding range. If the network element prefix lookup
capabilities are evaluated, the tests SHOULD focus on the IPv6 capabilities are evaluated, the tests SHOULD focus on the IPv6
relevant prefix boundaries: 0-64, 126 and 128. relevant prefix boundaries: 0-64, 126 and 128.
Special care needs to be taken about the Neighbor Unreachability Special care needs to be taken about the Neighbor Unreachability
skipping to change at page 7, line 15 skipping to change at page 7, line 18
(NS) and Neighbor Advertisement (NA) storms due to multiple test (NS) and Neighbor Advertisement (NA) storms due to multiple test
traffic flows. traffic flows.
5.3. Traffic with Extension Headers 5.3. Traffic with Extension Headers
Extension headers are an intrinsic part of the IPv6 architecture [5]. Extension headers are an intrinsic part of the IPv6 architecture [5].
They are used with various types of practical traffic such as: They are used with various types of practical traffic such as:
Fragmented traffic, mobile IP based traffic, authenticated and Fragmented traffic, mobile IP based traffic, authenticated and
encrypted traffic. For these reasons, all tests described in this encrypted traffic. For these reasons, all tests described in this
document SHOULD be performed with both traffic that has no extension document SHOULD be performed with both traffic that has no extension
headers and traffic that has a set of extension headers selected from headers and traffic that has a set of extension headers. They can be
the following ordered list [5]: selected from the following list [5] which reflects the recommended
order of multiple extension headers in a packet:
o Hop-by-hop header o Hop-by-hop header
o Destination options header o Destination options header
o Routing header o Routing header
o Fragment header o Fragment header
o Authentication header o Authentication header
o Encapsulating Security Payload header o Encapsulating Security Payload header
o Destination options header o Destination options header
o Mobility header o Mobility header
Considering the fact that extension headers are an intrinsic part of Considering the fact that extension headers are an intrinsic part of
skipping to change at page 7, line 41 skipping to change at page 7, line 45
The special processing rules for the Hop-by-hop extension header The special processing rules for the Hop-by-hop extension header
require a specific benchmarking approach. Unlike the other extension require a specific benchmarking approach. Unlike the other extension
headers, this header must be processed by each node that forwards the headers, this header must be processed by each node that forwards the
traffic. Tests with traffic containing this extension headers type traffic. Tests with traffic containing this extension headers type
will not measure the forwarding performance of the DUT but rather its will not measure the forwarding performance of the DUT but rather its
extension headers processing ability which is dependent on the extension headers processing ability which is dependent on the
information contained in the extension headers. The concern is that information contained in the extension headers. The concern is that
this traffic, at high rates, could have a negative impact on the this traffic, at high rates, could have a negative impact on the
operational resources of the router and could be used as a security operational resources of the router and could be used as a security
threat. When benchmarking with traffic that contains the Hop-by-hop threat. When benchmarking with traffic that contains the Hop-by-hop
extension headers, the goal is not to measure throughput [2] as in extension header, the goal is not to measure throughput [2] as in the
the case of the other extension headers but rather to evaluate impact case of the other extension headers but rather to evaluate the impact
of such traffic on the router. In this case, traffic with the Hop- of such traffic on the router. In this case, traffic with the Hop-
by-hop extension headers should be sent at 1%, 10% and 50% of the by-hop extension headers should be sent at 1%, 10% and 50% of the
interface total bandwidth. Device resources must be monitored at interface total bandwidth. Device resources must be monitored at
each traffic rate to determine the impact. each traffic rate to determine the impact.
The tests with traffic containing each individual extension headers The tests with traffic containing each individual extension header
MUST be complemented with tests that contain a chain of two or more MUST be complemented with tests that contain a chain of two or more
extension headers (the chain MUST not contain the Hop-by-hop extension headers (the chain MUST not contain the Hop-by-hop
extension header). The chain should also exclude the ESP extension extension header). The chain should also exclude the ESP extension
header since traffic with an encrypted payload can not be used in header since traffic with an encrypted payload can not be used in
tests with modifiers such as filters based on upper layer information tests with modifiers such as filters based on upper layer information
(see Section 5). Since the DUT is not analyzing the content of the (see Section 5). Since the DUT is not analyzing the content of the
extension headers, any combination of extension headers can be used extension headers, any combination of extension headers can be used
in testing. The extension headers chain recommended to be used in in testing. The extension headers chain recommended to be used in
testing is: testing is:
o Routing header - 24-32 bytes o Routing header - 24-32 bytes
o Destination options header - 8 bytes o Destination options header - 8 bytes
o Fragment header - 8 bytes o Fragment header - 8 bytes
This is a real life extension headers chain that would be found in an This is a real life extension headers chain that would be found in an
IPv6 packet between two mobile nodes exchanged over the optimized IPv6 packet between two mobile nodes exchanged over an optimized path
path that requires fragmentation. The listed extension headers that requires fragmentation. The listed extension headers lengths
lengths represent test tool defaults. The total length of the represent test tool defaults. The total length of the extension
extension headers chain SHOULD be larger than 32 bytes. headers chain SHOULD be larger than 32 bytes.
Extension headers add extra bytes to the payload size of the IP 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 packets which MUST be factored in when used in testing at low frame
sizes. Their presence will modify the minimum packet size used in sizes. Their presence will modify the minimum packet size used in
testing. For direct comparison between the data obtained with testing. For direct comparison between the data obtained with
traffic that has extension headers and with traffic that doesn't have traffic that has extension headers and with traffic that doesn't have
them, at low frame size, a common bottom size SHOULD be selected for them, at low frame size, a common bottom size SHOULD be selected for
both types of traffic. both types of traffic.
For the most cases, the network elements ignore the extension headers For the most cases, the network elements ignore the extension headers
skipping to change at page 9, line 14 skipping to change at page 9, line 14
6. Modifiers 6. Modifiers
RFC2544 underlines the importance of evaluating the performance of RFC2544 underlines the importance of evaluating the performance of
network elements under certain operational conditions. The network elements under certain operational conditions. The
conditions defined in RFC2544 Section 11 are common to IPv4 and IPv6 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 with the exception of broadcast frames. IPv6 does not use layer 2 or
layer 3 broadcasts. This section provides additional conditions that layer 3 broadcasts. This section provides additional conditions that
are specific to IPv6. The suite of tests recommended in this are specific to IPv6. The suite of tests recommended in this
document SHOULD be first executed in the absence of these conditions document SHOULD be first executed in the absence of these conditions
and then repeated under each of the conditions separately. and then repeated under each of these conditions separately.
6.1. Management and Routing Traffic 6.1. Management and Routing Traffic
The procedures defined in RFC2544 sections 11.2 and 11.3 are The procedures defined in RFC2544 sections 11.2 and 11.3 are
applicable for IPv6 management and routing update Frames as well. applicable for IPv6 management and routing update Frames as well.
6.2. Filters 6.2. Filters
The filters defined in Section 11.4 of RFC2544 apply to IPv6 The filters defined in Section 11.4 of RFC2544 apply to IPv6
benchmarking as well. The filter definitions however must be benchmarking as well. The filter definitions however must be
skipping to change at page 11, line 18 skipping to change at page 11, line 18
RFC2544 while observing the DUT setup and the traffic setup RFC2544 while observing the DUT setup and the traffic setup
considerations described above. The following sections state the considerations described above. The following sections state the
test types explicitly and highlight only the methodology differences test types explicitly and highlight only the methodology differences
that might exist with respect to those described in Section 26 of that might exist with respect to those described in Section 26 of
RFC2544. RFC2544.
The specificities of IPv6, particularly the definition of extension The specificities of IPv6, particularly the definition of extension
headers processing, require additional benchmarking steps. In this headers processing, require additional benchmarking steps. In this
sense, the tests recommended by RFC2544 MUST be repeated for IPv6 sense, the tests recommended by RFC2544 MUST be repeated for IPv6
traffic without extension headers and with one or multiple extension traffic without extension headers and with one or multiple extension
headers. IPv6's deployment in existing IPv4 environments and the headers.
expected long co-existence of the two protocols leads network
operators to place great emphasis on understanding the performance of IPv6's deployment in existing IPv4 environments and the expected long
platforms forwarding both types of traffic. While device resources co-existence of the two protocols leads network operators to place
are shared between the two protocols, it is important for IPv6 great emphasis on understanding the performance of platforms
enabled platforms to not experience degraded IPv4 performance. In forwarding both types of traffic. While device resources are shared
this context the IPv6 benchmarking SHOULD be performed in the context between the two protocols, it is important for IPv6 enabled platforms
of a stand alone protocol as well as in the context of its co- to not experience degraded IPv4 performance. Thus, IPv6 benchmarking
existence with IPv4. SHOULD be performed in the context of a stand alone protocol as well
as in the context of its co-existence with IPv4.
The modifiers defined are independent of extension header type so The modifiers defined are independent of extension header type so
they can be applied equally to each one of the above tests. they can be applied equally to each one of the above tests.
The benchmarking tests described in this section SHOULD be performed The benchmarking tests described in this section SHOULD be performed
under each of the following conditions: under each of the following conditions:
Extension headers specific conditions: Extension headers specific conditions:
i) IPv6 traffic with no extension headers i) IPv6 traffic with no extension headers
ii) IPv6 traffic with one extension header from the list in ii) IPv6 traffic with one extension header from the list in
skipping to change at page 12, line 43 skipping to change at page 12, line 44
Reporting Format: Same as RFC2544. Reporting Format: Same as RFC2544.
7.4. Back-to-Back Frames 7.4. Back-to-Back Frames
Objective: To characterize the ability of a DUT to process back-to- Objective: To characterize the ability of a DUT to process back-to-
back frames as defined in RFC1242. back frames as defined in RFC1242.
Based on the IPv4 experience, the Back-to-Back frames test is Based on the IPv4 experience, the Back-to-Back frames test is
characterized by significant variance due to short term variations in characterized by significant variance due to short term variations in
the processing flow. For these reasons, this test is not recommended the processing flow. For these reasons, this test is not recommended
anymore for IPv6 benchamrking. anymore for IPv6 benchmarking.
7.5. System Recovery 7.5. System Recovery
Objective: To characterize the speed at which a DUT recovers from an Objective: To characterize the speed at which a DUT recovers from an
overload condition. overload condition.
Procedure: Same as RFC2544. Procedure: Same as RFC2544.
Reporting Format: Same as RFC2544. Reporting Format: Same as RFC2544.
skipping to change at page 13, line 16 skipping to change at page 13, line 18
Objective: To characterize the speed at which a DUT recovers from a Objective: To characterize the speed at which a DUT recovers from a
device or software reset. device or software reset.
Procedure: Same as RFC2544. Procedure: Same as RFC2544.
Reporting Format: Same as RFC2544. Reporting Format: Same as RFC2544.
8. IANA Considerations 8. IANA Considerations
IANA reserved prefix xxxx/48 IPv6 for IPv6 benchmarking similar to IANA reserved prefix xxxx/48 for IPv6 benchmarking similar to
192.18.0.0 in RFC 3330 [8]. This prefix length provides similar 198.18.0.0/15 in RFC 3330 [8]. This prefix length provides similar
flexibility as the range allocated for IPv4 benchmarking and it is flexibility as the range allocated for IPv4 benchmarking and it is
taking into consideration address conservation and simplicity of taking into consideration address conservation and simplicity of
usage concerns. Most network infrastructures are allocated a /48 usage concerns. Most network infrastructures are allocated a /48
prefix, hence this range would allow most network administrators to prefix, hence this range would allow most network administrators to
mimic their IPv6 Address Plans when performing IPv6 benchmarking. mimic their IPv6 Address Plans when performing IPv6 benchmarking.
9. Security Considerations 9. Security Considerations
Benchmarking activities as described in this memo are limited to Benchmarking activities as described in this memo are limited to
technology characterization using controlled stimuli in a laboratory technology characterization using controlled stimuli in a laboratory
skipping to change at page 14, line 22 skipping to change at page 14, line 22
requirements stem from the architecture characteristics of IPv6. requirements stem from the architecture characteristics of IPv6.
This document is not a replacement of but a complement to RFC2544. This document is not a replacement of but a complement to RFC2544.
11. Acknowledgements 11. Acknowledgements
Scott Bradner provided valuable guidance and recommendations for this Scott Bradner provided valuable guidance and recommendations for this
document. The authors acknowledge the work done by Cynthia Martin document. The authors acknowledge the work done by Cynthia Martin
and Jeff Dunn with respect to defining the terminology for IPv6 and Jeff Dunn with respect to defining the terminology for IPv6
benchmarking. The authors would like to thank Bill Kine for his benchmarking. The authors would like to thank Bill Kine for his
contribution to the initial document and to Bill Cerveny, Silvija contribution to the initial document and to Bill Cerveny, Silvija
Dry, Sven Lanckmans, Athanassios Liakopoulos, Benoit Lourdelet, Al Dry, Sven Lanckmans, Dean Lee, Athanassios Liakopoulos, Benoit
Morton, Rajiv Papejna and Pekka Savola for their feedback. Lourdelet, Al Morton, Rajiv Papejna and Pekka Savola for their very
helpful feedback. Maryam Hamza inspired the authors in completing
this document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner, S. and J. McQuaid, "Benchmarking Methodology for [2] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999. Network Interconnect Devices", RFC 2544, March 1999.
skipping to change at page 15, line 12 skipping to change at page 15, line 15
[7] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, [7] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615,
June 1999. June 1999.
[8] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. [8] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[9] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix [9] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004. Reserved for Documentation", RFC 3849, July 2004.
[10] Newman, D. and T. Player, "Hash and Stuffing: Overlooked [10] Newman, D. and T. Player, "Hash and Stuffing: Overlooked
Factors in Network Device Benchmarking", Factors in Network Device Benchmarking",
draft-ietf-bmwg-hash-stuffing-07 (work in progress), (draft-ietf-bmwg-hash-stuffing-08 (work in progress)",
November 2006. January 2007.
[11] Newman, D. and T. Player, "Hash and Stuffing: Overlooked
Factors in Network Device Benchmarking
(draft-ietf-bmwg-hash-stuffing-07.txt)", November 2006.
Appendix A. Maximum Frame Rates Reference Appendix A. Maximum Frame Rates Reference
This appendix provides the formulas to calculate and the values for This appendix provides the formulas to calculate and the values for
the maximum frame rates for two media types: Ethernet and SONET. the maximum frame rates for two media types: Ethernet and SONET.
A.1. Ethernet A.1. Ethernet
The maximum throughput in frames per second (fps) for various The maximum throughput in frames per second (fps) for various
Ethernet interface types and for a frame size X can be calculated Ethernet interface types and for a frame size X can be calculated
with the following formula: with the following formula:
Line Rate (bps) Line Rate (bps)
------------------------------ ------------------------------
(8bits/byte)*(X+20)bytes/frame (8bits/byte)*(X+20)bytes/frame
The 20 bytes in the formula is the sum of the Preamble (8 bytes) and The 20 bytes in the formula is the sum of the Preamble (8 bytes) and
the Inter Frame Gap (12 bytes). The maximum throughput for various the Inter Frame Gap (12 bytes). The maximum throughput for various
PoS interface types and frame sizes: Ethernet interface types and frame sizes:
Size 10Mb/s 100Mb/s 1000Mb/s 10000Mb/s Size 10Mb/s 100Mb/s 1000Mb/s 10000Mb/s
Bytes pps pps pps pps Bytes pps pps pps pps
64 14881 148810 1488096 14880952 64 14881 148810 1488096 14880952
128 8446 84449 844595 8445946 128 8446 84449 844595 8445946
256 4529 45290 452899 4528986 256 4529 45290 452899 4528986
512 2350 23497 234962 2349625 512 2350 23497 234962 2349625
1024 1198 11973 119731 1197318 1024 1198 11973 119731 1197318
1280 961 9616 96153 961538 1280 961 9616 96153 961538
skipping to change at page 16, line 42 skipping to change at page 16, line 42
64 288,000 1,152,000 4,608,000 18,432,000 73,728,000 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 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 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 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 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 2048 9,136 36,545 146,179 584,714 2,338,858
4096 4,569 18,277 73,107 292,429 1,169,714 4096 4,569 18,277 73,107 292,429 1,169,714
It is important to note that throughput test results may vary from It is important to note that throughput test results may vary from
the values presented in appendices A.1 and A.2 due to bit stuffing the values presented in appendices A.1 and A.2 due to bit stuffing
performed by various media types [11]. performed by various media types [10].
Authors' Addresses Authors' Addresses
Ciprian Popoviciu Ciprian Popoviciu
Cisco Systems Cisco Systems
Kit Creek Road Kit Creek Road
RTP, North Carolina 27709 RTP, North Carolina 27709
USA USA
Phone: 919 787 8162 Phone: 919 787 8162
 End of changes. 25 change blocks. 
56 lines changed or deleted 57 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/