GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5180

Network Working Group C. Popoviciu Request for Comments: 5180 A. Hamza Category: Informational G. Van de Velde

                                                         Cisco Systems
                                                           D. Dugatkin
                                                         FastSoft Inc.
                                                              May 2008
   IPv6 Benchmarking Methodology for Network Interconnect Devices

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Abstract

 The benchmarking methodologies defined in RFC 2544 are IP version
 independent.  However, RFC 2544 does not address some of the
 specificities of IPv6.  This document provides additional
 benchmarking guidelines, which in conjunction with RFC 2544, lead to
 a more complete and realistic evaluation of the IPv6 performance of
 network interconnect devices.  IPv6 transition mechanisms are outside
 the scope of this document.

Popoviciu, et al. Informational [Page 1] RFC 5180 IPv6 Benchmarking Methodology May 2008

Table of Contents

 1. Introduction ....................................................2
 2. Existing Definitions ............................................3
 3. Tests and Results Evaluation ....................................3
 4. Test Environment Setup ..........................................3
 5. Test Traffic ....................................................4
    5.1. Frame Formats and Sizes ....................................4
         5.1.1. Frame Sizes to Be Used on Ethernet ..................5
         5.1.2. Frame Sizes to Be Used on SONET .....................5
    5.2. Protocol Addresses Selection ...............................6
         5.2.1. DUT Protocol Addresses ..............................6
         5.2.2. Test Traffic Protocol Addresses .....................7
    5.3. Traffic with Extension Headers .............................7
    5.4. Traffic Setup ..............................................9
 6. Modifiers .......................................................9
    6.1. Management and Routing Traffic .............................9
    6.2. Filters ...................................................10
         6.2.1. Filter Format ......................................10
         6.2.2. Filter Types .......................................11
 7. Benchmarking Tests .............................................12
    7.1. Throughput ................................................13
    7.2. Latency ...................................................13
    7.3. Frame Loss ................................................13
    7.4. Back-to-Back Frames .......................................13
    7.5. System Recovery ...........................................14
    7.6. Reset .....................................................14
 8. IANA Considerations ............................................14
 9. Security Considerations ........................................14
 10. Conclusions ...................................................15
 11. Acknowledgements ..............................................15
 12. References ....................................................15
    12.1. Normative References .....................................15
    12.2. Informative References ...................................16
 Appendix A.  Theoretical Maximum Frame Rates Reference ............17
    A.1.  Ethernet .................................................17
    A.2.  Packet over SONET ........................................18

1. Introduction

 The benchmarking methodologies defined by RFC 2544 [9] are proving to
 be useful in consistently evaluating IPv4 forwarding performance of
 network elements.  Adherence to these testing and result analysis
 procedures facilitates objective comparison of IPv4 performance data
 measured on various products and by various individuals.  While the
 principles behind the methodologies introduced in RFC 2544 are
 largely IP version independent, the protocol has continued to evolve,
 particularly in its version 6 (IPv6).

Popoviciu, et al. Informational [Page 2] RFC 5180 IPv6 Benchmarking Methodology May 2008

 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
 RFC 2460 [2].  These recommendations are defined within the RFC 2544
 framework, and they complement the test and result analysis
 procedures as described in RFC 2544.
 The terms used in this document remain consistent with those defined
 in "Benchmarking Terminology for Network Interconnect Devices", RFC
 1242 [7].  This terminology 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 RFC 2544 recommendations.

2. Existing Definitions

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 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
 of standards track documents as clear as possible.  While this
 document uses these key words, this document is not a standards track
 document.

3. Tests and Results Evaluation

 The recommended performance evaluation tests are described in Section
 7 of this document.  Not all of these tests are applicable to all
 network element types.  Nevertheless, for each evaluated device, it
 is recommended to perform as many of the applicable tests described
 in Section 6 as possible.
 Test execution and results analysis MUST be performed while observing
 generally accepted testing practices regarding repeatability,
 variance, and statistical significance of small numbers of trials.

4. Test Environment Setup

 The test environment setup options recommended for the IPv6
 performance evaluation are the same as those described in Section 6
 of RFC 2544, in both single-port and multi-port scenarios.
 Single-port testing measures per-interface forwarding performance,
 while multi-port testing measures the scalability of forwarding
 performance across the entire platform.

Popoviciu, et al. Informational [Page 3] RFC 5180 IPv6 Benchmarking Methodology May 2008

 Throughout the test, the Device Under Test (DUT) can be monitored for
 relevant resource (processor, memory, etc.) utilization.  This data
 could be beneficial in understanding traffic processing by each DUT
 and the resources that must be allocated for IPv6.  It could reveal
 if the IPv6 traffic is processed in hardware, by applicable devices,
 under all test conditions, or if it is punted in the software-
 switched path.  If such data is considered of interest, it MUST be
 collected out of band and be independent of any management data
 collected through the interfaces forwarding the test traffic.
 Note: During testing, either static or dynamic options for neighbor
 discovery can be used.  In the static case, the IPv6 neighbor
 information for the test tool is manually configured on the DUT, and
 the IPv6 neighbor information for the DUT is manually configured on
 the test tool.  In the dynamic case, the IPv6 neighbor information is
 dynamically discovered by each device through the neighbor discovery
 protocol.  The static option can be used as long as it is supported
 by the test tool.  The dynamic option is preferred wherein the test
 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 [6], the test
 scenarios assume test traffic simulates end points and IPv6 source
 and destination addresses that are one hop beyond the DUT.

5. Test Traffic

 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.
 Using the recommended IPv6 traffic profile leads to a complete
 evaluation of the network element performance.

5.1. Frame Formats and Sizes

 Two types of media are commonly deployed, and each SHOULD be tested
 if the network element supports that type of media: Ethernet and
 SONET (Synchronous Optical Network).  This section identifies the
 frame sizes that SHOULD be used for each media type.  Refer to
 recommendations in RFC 2544 for all other media types.
 Similar to IPv4, small frame sizes help characterize the per-frame
 processing overhead of the DUT.  Note that the minimum IPv6 packet
 size (40 bytes) is larger than that of an IPv4 packet (20 bytes).
 Tests should compensate for this difference.

Popoviciu, et al. Informational [Page 4] RFC 5180 IPv6 Benchmarking Methodology May 2008

 The frame sizes listed for IPv6 include the extension headers used in
 testing (see Section 5.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.
 Note: Test tools commonly use signatures to identify test traffic
 packets to verify that there are no packet drops or out-of-order
 packets, or to calculate various statistics such as delay and jitter.
 This could be the reason why the minimum frame size selectable
 through the test tool might not be as low as the theoretical one
 presented in this document.

5.1.1. Frame Sizes to Be Used on Ethernet

 Ethernet, in all its types, has become the most commonly deployed
 media in today's networks.  The following frame sizes SHOULD be used
 for benchmarking over this media type: 64, 128, 256, 512, 1024, 1280,
 and 1518 bytes.
 Note: The recommended 1518-byte frame size represents the maximum
 size of an untagged Ethernet frame.  According to the IEEE 802.3as
 standard [13], the frame size can be increased up to 2048 bytes to
 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, the 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
 standard, tests SHOULD be executed with frame sizes selected based on
 the values supported by the device under test.  Examples of commonly
 used jumbo frame sizes are: 4096, 8192, and 9216 bytes.
 The maximum frame rates for each frame size and the various Ethernet
 interface types are provided in Appendix A.

5.1.2. Frame Sizes to Be Used on SONET

 Packet over SONET (PoS) interfaces are commonly used for edge uplinks
 and high-bandwidth core links.  Evaluating the forwarding performance
 of PoS interfaces supported by the DUT is recommended.  The following
 frame sizes SHOULD be used for this media type: 47, 64, 128, 256,
 512, 1024, 1280, 1518, 2048, 4096 bytes.
 The theoretical maximum frame rates for each frame size and the
 various PoS interface types are provided in Appendix A.

Popoviciu, et al. Informational [Page 5] RFC 5180 IPv6 Benchmarking Methodology May 2008

5.2. Protocol Addresses Selection

 There are two aspects of 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 test
 traffic.

5.2.1. DUT Protocol Addresses

 IANA reserved an IPv6 address block for use with IPv6 benchmark
 testing (see Section 8).  It MAY be assumed that addresses in this
 block are not globally routable, and they MUST NOT be used as
 Internet source or destination addresses.
 Similar to Appendix C of RFC 2544, 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 of the following:
    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 always be the best choice for
 addressing point-to-point links such as back-to-back Ethernet unless
 the auto-provisioning mechanism is disabled.  Also, not all network
 elements support addresses of this prefix length.
 While with IPv6, the DUT interfaces can be configured with multiple
 global unicast addresses, 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 regarding the
 performance of the network element.
 The Interface ID portion of global unicast IPv6 DUT addresses SHOULD
 be set to ::1.  There are no requirements in the selection of the
 Interface ID portion of the link local IPv6 addresses.

Popoviciu, et al. Informational [Page 6] RFC 5180 IPv6 Benchmarking Methodology May 2008

 It is recommended that multiple iterations of the benchmark tests be
 conducted using the following prefix lengths: 48, 64, 126, and 128
 for the advertised traffic destination prefix.  Other prefix lengths
 can be used.  However, the indicated range reflects major prefix
 boundaries expected to be present in IPv6 routing tables, and they
 should be representative to establish baseline performance metrics.

5.2.2. Test Traffic Protocol Addresses

 IPv6 source and destination addresses for the test streams SHOULD
 belong to the IPv6 range assigned by IANA, as defined in Section 8.
 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.
 Note: When statically defined neighbors are not used, the parameters
 affecting Neighbor Unreachability Detection should be consistently
 set.  The IPv6 prefix-reachable time in the router advertisement
 SHOULD be set to 30 seconds.

5.3. Traffic with Extension Headers

 Extension headers are an intrinsic part of the IPv6 architecture [2].
 They are used with various types of practical traffic such as:
 fragmented traffic, mobile IP-based traffic, and authenticated and
 encrypted traffic.  For these reasons, all tests described in this
 document SHOULD be performed with both traffic that has no extension
 headers and traffic that has a set of extension headers.  Extension
 header types can be selected from the following list [2] that
 reflects the recommended order of multiple extension headers in a
 packet:
    o  Hop-by-hop header
    o  Destination options header
    o  Routing header
    o  Fragment header
    o  Authentication header
    o  Encapsulating security payload (ESP) header
    o  Destination options header
    o  Mobility header

Popoviciu, et al. Informational [Page 7] RFC 5180 IPv6 Benchmarking Methodology May 2008

 Since extension headers are an intrinsic part of the protocol and
 they fulfill different roles, benchmarking of traffic containing each
 extension header SHOULD be executed individually.
 The special processing rules for the hop-by-hop extension header
 require a specific benchmarking approach.  Unlike other extension
 headers, this header must be processed by each node that forwards the
 traffic.  Tests with traffic containing these extension header types
 will not measure the forwarding performance of the DUT, but rather
 its extension-header processing capability, which is dependent on the
 information contained in the extension headers.  The concern is that
 this traffic, at high rates, could have a negative impact on the
 operational resources of the router, and it could be used as a
 security threat.  When benchmarking with traffic that contains the
 hop-by-hop extension header, the goal is not to measure throughput
 [9] as in 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 hop-by-hop extension headers should be sent at 1%,
 10%, and 50% of the interface total bandwidth.  Device resources must
 be monitored at each traffic rate to determine the impact.
 Tests with traffic containing each individual extension header MUST
 be complemented with tests containing a chain of two or more
 extension headers (the chain MUST NOT contain the hop-by-hop
 extension header).  This chain should also exclude the ESP [5]
 extension header, since traffic with an encrypted payload cannot be
 used in tests with modifiers such as filters based on upper-layer
 information (see Section 5).  Since the DUT is not analyzing the
 content of the extension headers, any combination of extension
 headers can be used in testing.  The extension header chain
 recommended for testing is:
    o  Routing header - 24-32 bytes
    o  Destination options header - 8 bytes
    o  Fragment header - 8 bytes
 This is a real-life extension-header chain that would be found in an
 IPv6 packet between two mobile nodes exchanged over an optimized path
 that requires fragmentation.  The listed extension headers' lengths
 represent test tool defaults.  The total length of the extension
 header chain SHOULD be larger than 32 bytes.
 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 packet size used in

Popoviciu, et al. Informational [Page 8] RFC 5180 IPv6 Benchmarking Methodology May 2008

 testing.  For direct comparison between the data obtained with
 traffic that has extension headers and with traffic that doesn't have
 them at low frame size, a common value SHOULD be selected for the
 smallest frame size of both types of traffic.
 For most cases, the network elements ignore the extension headers
 when forwarding IPv6 traffic.  For these reasons, it is likely the
 performance impact related to extension headers 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 extension headers, a process that
 could impact performance.

5.4. Traffic Setup

 All tests recommended in this document SHOULD be performed with
 bi-directional traffic.  For asymmetric situations, tests MAY be
 performed with uni-directional traffic for a more granular
 characterization of the DUT performance.  In these cases, the
 bi-directional traffic testing would reveal only the lowest
 performance between the two directions.
 All other traffic profile characteristics described in RFC 2544
 SHOULD be applied in this testing as well.  IPv6 multicast
 benchmarking is outside the scope of this document.

6. Modifiers

 RFC 2544 underlines the importance of evaluating the performance of
 network elements under certain operational conditions.  The
 conditions defined in Section 11 of RFC 2544 are common to IPv4 and
 IPv6, except that IPv6 does not employ layer 2 or 3 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 these
 conditions separately.

6.1. Management and Routing Traffic

 The procedures defined in Sections 11.2 and 11.3 of RFC 2544 are
 applicable for IPv6 management and routing update frames as well.

Popoviciu, et al. Informational [Page 9] RFC 5180 IPv6 Benchmarking Methodology May 2008

6.2. Filters

 The filters defined in Section 11.4 of RFC 2544 apply to IPv6
 benchmarking as well.  The filter definitions must be expanded to
 include upper-layer protocol information matching in order to analyze
 the handling of traffic with extension headers, which are an
 important architectural component of IPv6.

6.2.1. Filter Format

 The filter format defined in RFC 2544 is applicable to IPv6 as well,
 except that the source addresses (SA) and destination addresses (DA)
 are IPv6 addresses.  In addition to these basic filters, the
 evaluation of IPv6 performance SHOULD analyze the correct filtering
 and handling of traffic with extension headers.
 While the intent is not to evaluate a platform's capability to
 process the various extension header types, the goal is to measure
 performance impact when the network element must parse through the
 extension headers to reach upper-layer information.  In IPv6, routers
 do not have to parse through the extension headers (other than
 hop-by-hop) unless, for example, upper-layer information has to be
 analyzed due to filters.
 To evaluate the network element handling of IPv6 traffic with
 extension headers, the definition of the filters must be extended to
 include conditions applied to upper-layer protocol information.  The
 following filter format SHOULD be used 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.

Popoviciu, et al. Informational [Page 10] RFC 5180 IPv6 Benchmarking Methodology May 2008

 The upper-layer protocols listed above are a recommended selection.
 However, they do not represent an all-inclusive list of upper-layer
 protocols that 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

 Based on RFC 2544 recommendations, two types of tests are executed
 when evaluating performance in the presence of modifiers: one with a
 single filter and another with 25 filters.  Examples of recommended
 filters are illustrated using the IPv6 documentation prefix [11]
 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.
 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.

Popoviciu, et al. Informational [Page 11] RFC 5180 IPv6 Benchmarking Methodology May 2008

7. Benchmarking Tests

 This document recommends the same benchmarking tests described in RFC
 2544 while observing the DUT setup and the traffic setup
 considerations described above.  The following sections state the
 test types explicitly, and they highlight only the methodology
 differences that might exist with respect to those described in
 Section 26 of RFC 2544.
 The specificities of IPv6, particularly the definition of extension
 header processing, require additional benchmarking steps.  The tests
 recommended by RFC 2544 MUST be repeated for IPv6 traffic without
 extension headers and for IPv6 traffic with one or multiple extension
 headers.
 IPv6's deployment in existing IPv4 environments and the expected long
 coexistence of the two protocols leads network operators to place
 great emphasis on understanding the performance of platforms
 processing both types of traffic.  While device resources are shared
 between the two protocols, it is important that IPv6-enabled
 platforms not experience degraded IPv4 performance.  Thus, IPv6
 benchmarking SHOULD be performed in the context of a stand-alone
 protocol as well as in the context of its coexistence with IPv4.
 The modifiers defined are independent of the extension header type,
 so they can be applied equally to each one of the above tests.
 The benchmarking tests described in this section SHOULD be performed
 under each of the following conditions:
 Extension header specific conditions:
 i)    IPv6 traffic with no extension headers
 ii)   IPv6 traffic with one extension header from the list in Section
       5.3
 iii)  IPv6 traffic with the chain of extension headers described in
       Section 5.3
 Coexistence-specific conditions:
 iv)   IPv4 ONLY traffic benchmarking
 v)    IPv6 ONLY traffic benchmarking
 vi)   IPv4-IPv6 traffic mix with the ratio 90% vs 10%

Popoviciu, et al. Informational [Page 12] RFC 5180 IPv6 Benchmarking Methodology May 2008

 vii)  IPv4-IPv6 traffic mix with the ratio 50% vs 50%
 viii) IPv4-IPv6 traffic mix with the ratio 10% vs 90%
 Combining the test conditions listed for benchmarking IPv6 as a
 stand-alone protocol and the coexistence tests leads to a
 large-coverage matrix.  At a minimum requirement, the coexistence
 tests should use IPv6 traffic with no extension headers and the 10%-
 90%, 90%-10%, or IPv4/IPv6 traffic mix.
 The subsequent sections each describe specific tests that MUST be
 executed under the conditions listed above for a complete
 benchmarking of IPv6-forwarding performance.

7.1. Throughput

 Objective: To determine the DUT throughput as defined in RFC 1242.
 Procedure: Same as RFC 2544.
 Reporting Format: Same as RFC 2544.

7.2. Latency

 Objective: To determine the latency as defined in RFC 1242.
 Procedure: Same as RFC 2544.
 Reporting Format: Same as RFC 2544.

7.3. Frame Loss

 Objective: To determine the frame-loss rate (as defined in RFC 1242)
 of a DUT throughout the entire range of input data rates and frame
 sizes.
 Procedure: Same as RFC 2544.
 Reporting Format: Same as RFC 2544.

7.4. Back-to-Back Frames

 Based on the IPv4 experience, the back-to-back frames test is
 characterized by significant variance due to short-term variations in
 the processing flow.  For these reasons, this test is no longer
 recommended for IPv6 benchmarking.

Popoviciu, et al. Informational [Page 13] RFC 5180 IPv6 Benchmarking Methodology May 2008

7.5. System Recovery

 Objective: To characterize the speed at which a DUT recovers from an
 overload condition.
 Procedure: Same as RFC 2544.
 Reporting Format: Same as RFC 2544.

7.6. Reset

 Objective: To characterize the speed at which a DUT recovers from a
 device or software reset.
 Procedure: Same as RFC 2544.
 Reporting Format: Same as RFC 2544.

8. IANA Considerations

 The IANA has allocated 2001:0200::/48 for IPv6 benchmarking, which is
 a 48-bit prefix from the RFC 4773 pool.  This allocation is similar
 to 198.18.0.0/15, defined in RFC 3330 [10].  This prefix length (48)
 provides similar flexibility as the range allocated for IPv4
 benchmarking, and it takes into consideration address conservation
 and simplicity of usage concerns.  The requested size meets the
 requirements for testing large network elements and large emulated
 networks.
 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 [4] (Unique Local Addresses) in order to minimize the
 possibility of conflicts with operational traffic.

9. Security Considerations

 Benchmarking activities, as described in this memo, are limited to
 technology characterization using controlled stimuli in a laboratory
 environment, with dedicated address space and the constraints
 specified in the sections above.
 The benchmarking network topology will be an independent test setup
 and MUST NOT be connected to devices that may forward the test
 traffic into a production network or misroute traffic to the test
 management network.

Popoviciu, et al. Informational [Page 14] RFC 5180 IPv6 Benchmarking Methodology May 2008

 Further, benchmarking is performed on a "black-box" basis, relying
 solely on measurements observable external to the DUT/SUT (System
 Under Test).
 Special capabilities SHOULD NOT exist in the DUT/SUT specifically for
 benchmarking purposes.  Any implications for network security arising
 from the DUT/SUT SHOULD be identical in the lab and in production
 networks.
 The isolated nature of the benchmarking environments and the fact
 that no special features or capabilities, other than those used in
 operational networks, are enabled on the DUT/SUT requires no security
 considerations specific to the benchmarking process.

10. Conclusions

 The Benchmarking Methodology for Network Interconnect Devices
 document, RFC 2544 [9], is for the most part applicable to evaluating
 the IPv6 performance of network elements.  This document addresses
 the IPv6-specific requirements that MUST be observed when applying
 the recommendations of RFC 2544.  These additional requirements stem
 from the architecture characteristics of IPv6.  This document is not
 a replacement for, but a complement to, RFC 2544.

11. 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 like to thank Bill Kine for his
 contribution to the initial document and to Tom Alexander, Bill
 Cerveny, Silvija Dry, Sven Lanckmans, Dean Lee, Athanassios
 Liakopoulos, Benoit Lourdelet, Al Morton, David Newman, Rajiv
 Papejna, Dan Romascanu, and Pekka Savola for their very helpful
 feedback.  Maryam Hamza inspired the authors to complete this
 document.

12. References

12.1. Normative References

 [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.
 [2]   Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
       Specification", RFC 2460, December 1998.

Popoviciu, et al. Informational [Page 15] RFC 5180 IPv6 Benchmarking Methodology May 2008

 [3]   Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June
       1999.
 [4]   Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
       Addresses", RFC 4193, October 2005.
 [5]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
       December 2005.
 [6]   Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
       "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
       September 2007.

12.2. Informative References

 [7]   Bradner, S., "Benchmarking Terminology for Network
       Interconnection Devices", RFC 1242, July 1991.
 [8]   Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662,
       July 1994.
 [9]   Bradner, S. and J. McQuaid, "Benchmarking Methodology for
       Network Interconnect Devices", RFC 2544, March 1999.
 [10]  IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
 [11]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
       Reserved for Documentation", RFC 3849, July 2004.
 [12]  Newman, D. and T. Player, "Hash and Stuffing: Overlooked
       Factors in Network Device Benchmarking", RFC 4814, March 2007.
 [13]  LAN/MAN Standards Committee of the IEEE Computer Society, "IEEE
       Std 802.3as-2006, Part 3: Carrier Sense Multiple Access with
       Collision Detection (CSMA/CD) Access Method and Physical Layer
       Specifications, Amendment 3: Frame format extensions", 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.

Popoviciu, et al. Informational [Page 16] RFC 5180 IPv6 Benchmarking Methodology May 2008

Appendix A. Theoretical Maximum Frame Rates Reference

 This appendix provides the formulas to calculate and the values for
 the theoretical maximum frame rates for two media types: Ethernet and
 SONET.

A.1. Ethernet

 The 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 throughput for various Ethernet
 interface types and frame sizes:
    Size     10Mb/s   100Mb/s    1000Mb/s     10000Mb/s
    Bytes    pps      pps        pps          pps
    64       14,880   148,809    1,488,095    14,880,952
    128      8,445    84,459     844,594      8,445,945
    256      4,528    45,289     452,898      4,528,985
    512      2,349    23,496     234,962      2,349,624
    1024     1,197    11,973     119,731      1,197,318
    1280     961      9,615      96,153       961,538
    1518     812      8,127      81,274       812,743
    1522     810      8,106      81,063       810,635
    2048     604      6,044      60,444       604,448
    4096     303      3,036      30,396       303,691
    8192     152      1,522      15,221       152,216
    9216     135      1,353      13,534       135,339
 Note: Ethernet's maximum frame rates are subject to variances due to
 clock slop.  The listed rates are theoretical maximums, and actual
 tests should account for a +/- 100 ppm tolerance.

Popoviciu, et al. Informational [Page 17] RFC 5180 IPv6 Benchmarking Methodology May 2008

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 = 3Y, where Y=1,2,3,etc)
    [(N*87) - N/3]*(9 rows)*(8 bit/byte)*(8000 frames/sec)
 Packets over SONET can use various encapsulations: PPP [3], High-
 Level Data Link Control (HDLC) [8], and Frame Relay.  All these
 encapsulations use a 4-byte header, a 2- or 4-byte Frame Check
 Sequence (FCS) field, and a 1-byte Flag that are all accounted for in
 the overall frame size.  The maximum frame rate for various interface
 types can be calculated with the formula (where X represents the
 frame size in bytes):
           Line Rate (bps)
    ------------------------------
    (8bits/byte)*(X+1)bytes/frame
 The theoretical maximum frame rates for various PoS interface types
 and frame sizes:
    Size   OC-3c    OC-12c     OC-48c     OC-192c     OC-768c
    Bytes  fps      fps        fps        fps         fps
    47     390,000  1,560,000  6,240,000  24,960,000  99,840,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
    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
    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
    4096   4,569    18,276     73,107     292,428     1,169,714
 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
 performed by various media types [12].  The theoretical throughput
 numbers were rounded down.

Popoviciu, et al. Informational [Page 18] RFC 5180 IPv6 Benchmarking Methodology May 2008

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
 FastSoft, Inc.
 150 S. Los Robles Ave.
 Pasadena, CA 91101
 USA
 Phone: +1-626-357-7012
 EMail: diego@fastsoft.com

Popoviciu, et al. Informational [Page 19] RFC 5180 IPv6 Benchmarking Methodology May 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 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.
 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, THE IETF TRUST 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.

Intellectual Property

 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.

Popoviciu, et al. Informational [Page 20]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5180.txt · Last modified: 2008/05/16 16:37 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki