< draft-ietf-bmwg-ipv6-meth-04.txt   draft-ietf-bmwg-ipv6-meth-05.txt >
Network Working Group C. Popoviciu Network Working Group C. Popoviciu
Internet-Draft A. Hamza Internet-Draft A. Hamza
Intended status: Informational G. Van de Velde Intended status: Informational G. Van de Velde
Expires: April 10, 2008 Cisco Systems Expires: July 4, 2008 Cisco Systems
D. Dugatkin D. Dugatkin
IXIA IXIA
October 8, 2007 January 2008
IPv6 Benchmarking Methodology for Network Interconnect Devices IPv6 Benchmarking Methodology for Network Interconnect Devices
<draft-ietf-bmwg-ipv6-meth-04.txt> <draft-ietf-bmwg-ipv6-meth-05.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 April 10, 2008. This Internet-Draft will expire on July 4, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Benchmarking Methodologies defined in RFC2544 [8] are IP version The Benchmarking Methodologies defined in RFC2544 [9] are IP version
independent. However, RFC 2544 does not address some of the independent. However, RFC 2544 does not address some of the
specificities of IPv6. This document provides additional specificities of IPv6. This document provides additional
benchmarking guidelines, which in conjunction with RFC2544, lead to a benchmarking guidelines, which in conjunction with RFC2544, lead to a
more complete and realistic evaluation of the IPv6 performance of more complete and realistic evaluation of the IPv6 performance of
network interconnect devices. IPv6 transition mechanisms are outside network interconnect devices. IPv6 transition mechanisms are outside
the scope of this document. the scope of this document.
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 . . . . . . . . . . . . . . . . . 5
5.1.1. Frame Sizes to be used on Ethernet . . . . . . . . . . 5 5.1.1. Frame Sizes to be used on Ethernet . . . . . . . . . . 5
5.1.2. Frame Sizes to be used on SONET . . . . . . . . . . . 5 5.1.2. Frame Sizes to be used on SONET . . . . . . . . . . . 6
5.2. Protocol Addresses Selection . . . . . . . . . . . . . . . 6 5.2. Protocol Addresses Selection . . . . . . . . . . . . . . . 6
5.2.1. DUT Protocol Addresses . . . . . . . . . . . . . . . . 6 5.2.1. DUT Protocol Addresses . . . . . . . . . . . . . . . . 6
5.2.2. Test Traffic Protocol Addresses . . . . . . . . . . . 7 5.2.2. Test Traffic Protocol Addresses . . . . . . . . . . . 7
5.3. Traffic with Extension Headers . . . . . . . . . . . . . . 7 5.3. Traffic with Extension Headers . . . . . . . . . . . . . . 7
5.4. Traffic set up . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Traffic set up . . . . . . . . . . . . . . . . . . . . . . 9
6. Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Modifiers . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Management and Routing Traffic . . . . . . . . . . . . . . 9 6.1. Management and Routing Traffic . . . . . . . . . . . . . . 9
6.2. Filters . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Filters . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.1. Filter Format . . . . . . . . . . . . . . . . . . . . 9 6.2.1. Filter Format . . . . . . . . . . . . . . . . . . . . 10
6.2.2. Filter Types . . . . . . . . . . . . . . . . . . . . . 10 6.2.2. Filter Types . . . . . . . . . . . . . . . . . . . . . 11
7. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . . 11 7. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.3. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 13
7.4. Back-to-Back Frames . . . . . . . . . . . . . . . . . . . 13 7.4. Back-to-Back Frames . . . . . . . . . . . . . . . . . . . 13
7.5. System Recovery . . . . . . . . . . . . . . . . . . . . . 13 7.5. System Recovery . . . . . . . . . . . . . . . . . . . . . 13
7.6. Reset . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.6. Reset . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Theoretical Maximum Frame Rates Reference . . . . . . 15 Appendix A. Theoretical Maximum Frame Rates Reference . . . . . . 16
A.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 16 A.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 16
A.2. Packet over SONET . . . . . . . . . . . . . . . . . . . . 16 A.2. Packet over SONET . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
The benchmarking methodologies defined by RFC2544 [8] are proving to The benchmarking methodologies defined by RFC2544 [9] are proving to
be useful in consistently evaluating IPv4 forwarding performance of be useful in consistently evaluating IPv4 forwarding performance of
network elements. Adherence to these testing and result analysis network elements. Adherence to these testing and result analysis
procedures facilitates objective comparison of IPv4 performance data procedures facilitates objective comparison of IPv4 performance data
measured on various products and by various individuals. While the measured on various products and by various individuals. While the
principles behind the methodologies introduced in RFC2544 are largely principles behind the methodologies introduced in RFC2544 are largely
IP version independent, the protocol continued to evolve, IP version independent, the protocol continued to evolve,
particularly in its version 6 (IPv6). 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 [2]. These recommendations are defined within the RFC2544 RFC2460 [2]. These recommendations are defined within the RFC2544
framework and complement the test and result analysis procedures as framework and complement the test and result analysis procedures as
described in RFC2544. described in RFC2544.
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" in "Benchmarking Terminology for Network Interconnect Devices"
RFC1242 [6]. This terminology SHOULD be consulted before using or RFC1242 [7]. This terminology SHOULD be consulted before using or
applying the recommendations of this document. applying the 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].
skipping to change at page 4, line 15 skipping to change at page 4, line 15
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 those described in Section 6 performance evaluation are the same as those described in Section 6
of RFC2544, in both single-port and multi-port scenarios. Single- of RFC2544, in both single-port and multi-port scenarios. Single-
port testing measures per-interface forwarding performance while port testing measures per-interface forwarding performance while
multi-port testing measures the scalability of forwarding performance multi-port testing measures the scalability of forwarding performance
across the entire platform. across the entire platform.
Throughout the test, the DUT can be monitored for relevant resource Throughout the test, the Device Under Test (DUT) can be monitored for
(Processor, Memory, etc.) utilization. This data could be beneficial relevant resource (Processor, Memory, etc.) utilization. This data
in understanding traffic processing by each DUT and the resources could be beneficial in understanding traffic processing by each DUT
that must be allocated for IPv6. It could reveal if the IPv6 traffic and the resources that must be allocated for IPv6. It could reveal
is processed in hardware, by applicable devices, under all test if the IPv6 traffic is processed in hardware, by applicable devices,
conditions or it is punted in the software switched path. If such under all test conditions or it is punted in the software switched
data is considered of interest, it MUST be collected out of band and path. If such data is considered of interest, it MUST be collected
independent of any management data collected through the interfaces out of band and independent of any management data collected through
forwarding the test traffic. 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. In the static case the IPv6 neighbor
is supported by the test tool. The dynamic option is preferred information for the test tool is manually configured on the DUT and
wherein the test tool interacts with the DUT for the duration of the the IPv6 neighbor information for the DUT is manually configured on
test to maintain the respective neighbor caches in an active state. the test tool. In the dynamic case, the IPv6 neighbor information is
To avoid neighbor solicitation (NS) and neighbor advertisement (NA) dynamically discovered by each device through the neighbor discovery
storms due to the neighbor unreachability detection (NUD) mechanism protocol. The static option can be used as long as it is supported
[3], the test scenarios assume test traffic simulates end points and by the test tool. The dynamic option is preferred wherein the test
IPv6 source and destination addresses are one hop beyond the DUT. tool interacts with the DUT for the duration of the test to maintain
the respective neighbor caches in an active state. To avoid neighbor
solicitation (NS) and neighbor advertisement (NA) storms due to the
neighbor unreachability detection (NUD) mechanism [3], the test
scenarios assume test traffic simulates end points and IPv6 source
and destination addresses are one hop beyond the DUT.
5. Test Traffic 5. Test Traffic
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 requirements described in this section. These requirements are
designed to reflect the characteristics of IPv6 unicast traffic. designed to reflect the characteristics of IPv6 unicast traffic.
Using the recommended IPv6 traffic profile leads to a complete Using the recommended IPv6 traffic profile leads to a complete
evaluation of the network element performance. evaluation of the network element performance.
5.1. Frame Formats and Sizes 5.1. Frame Formats and Sizes
skipping to change at page 5, line 32 skipping to change at page 5, line 40
5.1.1. Frame Sizes to be used on Ethernet 5.1.1. Frame Sizes to be used on Ethernet
Ethernet in all its types has become the most commonly deployed media Ethernet in all its types has become the most commonly deployed media
in today's networks. The following frame sizes SHOULD be used for in today's networks. The following frame sizes SHOULD be used for
benchmarking over this media type: 64, 128, 256, 512, 1024, 1280, benchmarking over this media type: 64, 128, 256, 512, 1024, 1280,
1518 bytes. 1518 bytes.
Note: The recommended 1518 bytes frame size represents the maximum Note: The recommended 1518 bytes frame size represents the maximum
size of an untagged Ethernet frame. According to the IEEE 802.3as size of an untagged Ethernet frame. According to the IEEE 802.3as
standard [12], the frame size can be increased up to 2048 bytes to standard [13], the frame size can be increased up to 2048 bytes to
accommodate frame tags. accommodate frame tags and other encapsulation required by the IEEE
802.1AE MAC [14] security protocol. A frame size commonly used in
operational environments is 1522 bytes, max length for a VLAN-tagged
frame as per 802.1D [15].
Note: While jumbo frames are outside the scope of the 802.3 IEEE Note: While jumbo frames are outside the scope of the 802.3 IEEE
standard, tests SHOULD be executed with frame sizes selected based on standard, tests SHOULD be executed with frame sizes selected based on
the values supported by the device under test. Examples of commonly the values supported by the device under test. Examples of commonly
used jumbo frame sizes are: 4096, 8192, 9216 bytes. used jumbo frame sizes are: 4096, 8192, 9216 bytes.
The maximum frame rates for each frame size and the various Ethernet The 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
skipping to change at page 7, line 20 skipping to change at page 7, line 31
destination addresses to the other, reflecting the DUT interface IPv6 destination addresses to the other, reflecting the DUT interface IPv6
address selection. 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 Note: When statically defined neighbors are not used, the parameters
detection (NUD) [3] process. The IPv6 prefix reachable time in the affecting Neighbor Unreachability Detection should be consistently
router advertisement SHOULD be set to 30 seconds and allow 50% set. The IPv6 prefix reachable time in the router advertisement
jitter. The IPv6 source and destination addresses SHOULD not appear SHOULD be set to 30 seconds.
to be directly connected to the DUT to avoid neighbor solicitation
(NS) and neighbor advertisement (NA) storms due to multiple test
traffic flows.
5.3. Traffic with Extension Headers 5.3. Traffic with Extension Headers
Extension headers are an intrinsic part of the IPv6 architecture [2]. Extension headers are an intrinsic part of the IPv6 architecture [2].
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. Extension headers and traffic that has a set of extension headers. Extension
header types can be selected from the following list [2] which header types can be selected from the following list [2] which
skipping to change at page 8, line 13 skipping to change at page 8, line 23
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 other extension require a specific benchmarking approach. Unlike 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 these extension header types traffic. Tests with traffic containing these extension header types
will not measure the forwarding performance of the DUT, but rather will not measure the forwarding performance of the DUT, but rather
its extension header processing capability, which is dependent on the its extension header processing capability, 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 header, the goal is not to measure throughput [8] as in the extension header, the goal is not to measure throughput [9] as in the
case of the other extension headers, but rather to evaluate the case of the other extension headers, but rather to evaluate the
impact of such traffic on the router. In this case, traffic with the impact 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 hop-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.
Tests with traffic containing each individual extension header MUST Tests with traffic containing each individual extension header MUST
be complemented with tests containing a chain of two or more be complemented with tests containing 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). This chain should also exclude the ESP [5] extension header). This chain should also exclude the ESP [6]
extension header since traffic with an encrypted payload can not be extension header since traffic with an encrypted payload can not be
used in tests with modifiers such as filters based on upper layer used in tests with modifiers such as filters based on upper layer
information (see Section 5). Since the DUT is not analyzing the information (see Section 5). Since the DUT is not analyzing the
content of the extension headers, any combination of extension content of the extension headers, any combination of extension
headers can be used in testing. The extension header chain headers can be used in testing. The extension header chain
recommended for testing is: recommended for 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
skipping to change at page 10, line 31 skipping to change at page 10, line 45
where permit or deny indicates the action to allow or deny a packet where permit or deny indicates the action to allow or deny a packet
through the interface the filter is applied to. The protocol field through the interface the filter is applied to. The protocol field
is defined as: is defined as:
o ipv6: any IP Version 6 traffic o ipv6: any IP Version 6 traffic
o tcp: Transmission Control Protocol o tcp: Transmission Control Protocol
o udp: User Datagram Protocol o udp: User Datagram Protocol
and SA stands for the source address and DA for the destination and SA stands for the source address and DA for the destination
address. address.
The upper layer protocols listed above are recommended selection. The upper layer protocols listed above are a recommended selection.
However, they do not represent an all-inclusive list of upper layer However, they do not represent an all-inclusive list of upper layer
protocols which could be used in defining filters. protocols which could be used in defining filters. The filters
described in these benchmarking recommendations apply to native IPv6
traffic and upper layer protocols (tcp, udp) transported in native
IPv6 packets.
6.2.2. Filter Types 6.2.2. Filter Types
Based on RFC2544 recommendations, two types of tests are executed Based on RFC2544 recommendations, two types of tests are executed
when evaluating performance in the presence of modifiers: One with a when evaluating performance in the presence of modifiers: One with a
single filter and another with 25 filters. Examples of recommended single filter and another with 25 filters. Examples of recommended
filters are illustrated using the IPv6 documentation prefix [10] filters are illustrated using the IPv6 documentation prefix [11]
2001:DB8::. 2001:DB8::.
Examples of single filters are: Examples of single filters are:
Filter for TCP traffic - permit tcp 2001:DB8::1 2001:DB8::2 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 UDP traffic - permit udp 2001:DB8::1 2001:DB8::2
Filter for IPv6 traffic - permit ipv6 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 The single line filter case SHOULD verify that the network element
permits all TCP/UDP/IPv6 traffic with or without any number of permits all TCP/UDP/IPv6 traffic with or without any number of
skipping to change at page 13, line 36 skipping to change at page 14, line 7
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 xxxxx/48 for IPv6 benchmarking similar to The IANA was instructed to allocate for IPv6 benchmarking a 48 bits
198.18.0.0/15 in RFC 3330 [9]. This prefix length provides similar prefix from the RFC 4773 pool. This allocation is similar to
flexibility as the range allocated for IPv4 benchmarking and it is 198.18.0.0/15 defined in RFC 3330 [10]. This prefix length (48)
taking into consideration address conservation and simplicity of provides similar flexibility as the range allocated for IPv4
usage concerns. The requested size meets the requirements for benchmarking and it is taking into consideration address conservation
testing large network elements and large emulated networks. and simplicity of usage concerns. The requested size meets the
requirements for testing large network elements and large emulated
networks.
Note to IANA: Replace "xxxxx" with assigned prefix. Note: Similar to RFC 2544 avoiding the use of RFC 1918 address space
for benchmarking tests, this document does not recommend the use of
RFC 4193 [5] (Unique Local Addresses) in order to minimize the
possibility of conflicts with operational traffic.
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
environment, with dedicated address space and the constraints environment, with dedicated address space and the constraints
specified in the sections above. specified in the sections above.
The benchmarking network topology will be an independent test setup The benchmarking network topology will be an independent test setup
and MUST NOT be connected to devices that may forward the test and MUST NOT be connected to devices that may forward the test
skipping to change at page 14, line 26 skipping to change at page 14, line 49
networks. networks.
The isolated nature of the benchmarking environments and the fact The isolated nature of the benchmarking environments and the fact
that no special features or capabilities, other than those used in that no special features or capabilities, other than those used in
operational networks, are enabled on the DUT/SUT requires no security operational networks, are enabled on the DUT/SUT requires no security
considerations specific to the benchmarking process. considerations specific to the benchmarking process.
10. Conclusions 10. Conclusions
The Benchmarking Methodology for Network Interconnect Devices The Benchmarking Methodology for Network Interconnect Devices
document, RFC2544 [8], is for the most part applicable to evaluating document, RFC2544 [9], is for the most part applicable to evaluating
the IPv6 performance of network elements. This document addresses the IPv6 performance of network elements. This document addresses
the IPv6 specific requirements that MUST be observed when applying the IPv6 specific requirements that MUST be observed when applying
the recommendations of RFC2544. These additional requirements stem the recommendations of RFC2544. These additional requirements stem
from the architecture characteristics of IPv6. This document is not from the architecture characteristics of IPv6. This document is not
a replacement of but a complement to RFC2544. 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
skipping to change at page 15, line 4 skipping to change at page 15, line 23
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 Tom Alexander, Bill contribution to the initial document and to Tom Alexander, Bill
Cerveny, Silvija Dry, Sven Lanckmans, Dean Lee, Athanassios Cerveny, Silvija Dry, Sven Lanckmans, Dean Lee, Athanassios
Liakopoulos, Benoit Lourdelet, Al Morton, David Newman, Rajiv Liakopoulos, Benoit Lourdelet, Al Morton, David Newman, Rajiv
Papejna, Dan Romascanu and Pekka Savola for their very helpful Papejna, Dan Romascanu and Pekka Savola for their very helpful
feedback. Maryam Hamza inspired the authors in completing this feedback. Maryam Hamza inspired the authors in completing this
document. 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] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[4] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, [4] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615,
June 1999. June 1999.
[5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, [5] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[6] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005. December 2005.
12.2. Informative References 12.2. Informative References
[6] Bradner, S., "Benchmarking terminology for network [7] Bradner, S., "Benchmarking terminology for network
interconnection devices", RFC 1242, July 1991. interconnection devices", RFC 1242, July 1991.
[7] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, [8] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994. July 1994.
[8] Bradner, S. and J. McQuaid, "Benchmarking Methodology for [9] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999. Network Interconnect Devices", RFC 2544, March 1999.
[9] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. [10] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[10] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix [11] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004. Reserved for Documentation", RFC 3849, July 2004.
[11] Newman, D. and T. Player, "Hash and Stuffing: Overlooked [12] Newman, D. and T. Player, "Hash and Stuffing: Overlooked
Factors in Network Device Benchmarking", RFC 4814, March 2007. Factors in Network Device Benchmarking", RFC 4814, March 2007.
[12] LAN/MAN Standards Committee of the IEEE Computer Society, "IEEE [13] LAN/MAN Standards Committee of the IEEE Computer Society, "IEEE
Std 802.3as-2006, Part 3: Carrier Sense Multiple Access with Std 802.3as-2006, Part 3: Carrier Sense Multiple Access with
Collision Detection (CSMA/CD) Access Method and Physical Layer Collision Detection (CSMA/CD) Access Method and Physical Layer
Specifications, Amendment 3: Frame format extensions", Specifications, Amendment 3: Frame format extensions",
November 2006. November 2006.
[14] Allyn Romanow (editor), "IEEE Std 802.3ae, Media Access Control
(MAC) Security", June 2006.
[15] Mick Seaman (editor), "IEEE Std 802.1D-2004, MAC Bridges",
February 2004.
Appendix A. Theoretical Maximum Frame Rates Reference Appendix A. Theoretical 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 theoretical maximum frame rates for two media types: Ethernet and the theoretical maximum frame rates for two media types: Ethernet and
SONET. SONET.
A.1. Ethernet A.1. Ethernet
The throughput in frames per second (fps) for various Ethernet The throughput in frames per second (fps) for various Ethernet
interface types and for a frame size X can be calculated with the interface types and for a frame size X can be calculated with the
skipping to change at page 16, line 29 skipping to change at page 17, line 15
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 14,880 148,809 1,488,095 14,880,952 64 14,880 148,809 1,488,095 14,880,952
128 8,445 84,459 844,594 8,445,945 128 8,445 84,459 844,594 8,445,945
256 4,528 45,289 452,898 4,528,985 256 4,528 45,289 452,898 4,528,985
512 2,349 23,496 234,962 2,349,624 512 2,349 23,496 234,962 2,349,624
1024 1,197 11,973 119,731 1,197,318 1024 1,197 11,973 119,731 1,197,318
1280 961 9,615 96,153 961,538 1280 961 9,615 96,153 961,538
1518 812 8,127 81,274 812,743 1518 812 8,127 81,274 812,743
1522 810 8,106 81,063 810,635
2048 604 6,044 60,444 604,448 2048 604 6,044 60,444 604,448
4096 303 3,036 30,396 303,691 4096 303 3,036 30,396 303,691
8192 152 1,522 15,221 152,216 8192 152 1,522 15,221 152,216
9216 135 1,353 13,534 135,339 9216 135 1,353 13,534 135,339
Note: Ethernet's maximum frame rates are subject to variances due to Note: Ethernet's maximum frame rates are subject to variances due to
clock slop. The listed rates are theoretical maximums and actual clock slop. The listed rates are theoretical maximums and actual
tests should account for a +/- 100 ppm tolerance. tests should account for a +/- 100 ppm tolerance.
A.2. Packet over SONET A.2. Packet over SONET
ANSI T1.105 SONET provides the formula for calculating the maximum ANSI T1.105 SONET provides the formula for calculating the maximum
available bandwidth for the various Packet over SONET (PoS) interface available bandwidth for the various Packet over SONET (PoS) interface
types: types:
STS-Nc (N = 3Y, where Y=1,2,3,etc) STS-Nc (N = 3Y, where Y=1,2,3,etc)
[(N*87) - N/3]*(9 rows)*(8 bit/byte)*(8000 frames/sec) [(N*87) - N/3]*(9 rows)*(8 bit/byte)*(8000 frames/sec)
Packets over SONET can use various encapsulations: PPP [4], HDLC [7] Packets over SONET can use various encapsulations: PPP [4], HDLC [8]
and Frame Relay. All these encapsulations use a 4-byte header, a 2- and Frame Relay. All these encapsulations use a 4-byte header, a 2-
or 4-byte FCS field and a 1-byte Flag which are all accounted for in or 4-byte FCS field and a 1-byte Flag which are all accounted for in
the overall frame size. The maximum frame rate for various interface the overall frame size. The maximum frame rate for various interface
types can be calculated with the formula (where X represents the types can be calculated with the formula (where X represents the
frame size in bytes): frame size in bytes):
Line Rate (bps) Line Rate (bps)
------------------------------ ------------------------------
(8bits/byte)*(X+1)bytes/frame (8bits/byte)*(X+1)bytes/frame
skipping to change at page 17, line 27 skipping to change at page 18, line 19
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,441 37,149,767 128 145,116 580,465 2,321,860 9,287,441 37,149,767
256 72,840 291,361 1,165,447 4,661,789 18,647,159 256 72,840 291,361 1,165,447 4,661,789 18,647,159
512 36,491 145,964 583,859 2,335,438 9,341,754 512 36,491 145,964 583,859 2,335,438 9,341,754
1024 18,263 73,053 292,214 1,168,858 4,675,434 1024 18,263 73,053 292,214 1,168,858 4,675,434
2048 9,136 36,544 146,178 584,714 2,338,857 2048 9,136 36,544 146,178 584,714 2,338,857
4096 4,569 18,276 73,107 292,428 1,169,714 4096 4,569 18,276 73,107 292,428 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]. The theoretical throughput performed by various media types [12]. The theoretical throughput
numbers were rounded down. numbers were rounded down.
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
skipping to change at page 19, line 7 skipping to change at page 20, line 7
IXIA IXIA
26601 West Agoura Rd 26601 West Agoura Rd
Calabasas 91302 Calabasas 91302
USA USA
Phone: 818 444 3124 Phone: 818 444 3124
Email: diego@ixiacom.com Email: diego@ixiacom.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 42 change blocks. 
73 lines changed or deleted 97 lines changed or added

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