draft-ietf-bmwg-ipv6-meth-02.txt   draft-ietf-bmwg-ipv6-meth-03.txt 
Network Working Group C. Popoviciu Network Working Group C. Popoviciu
Internet-Draft A. Hamza Internet-Draft A. Hamza
Expires: January 3, 2008 G. Van de Velde Expires: March 1, 2008 G. Van de Velde
Cisco Systems Cisco Systems
D. Dugatkin D. Dugatkin
IXIA IXIA
July 2, 2007 August 29, 2007
IPv6 Benchmarking Methodology IPv6 Benchmarking Methodology for Network Interconnect Devices
<draft-ietf-bmwg-ipv6-meth-02.txt> <draft-ietf-bmwg-ipv6-meth-03.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 January 3, 2008. This Internet-Draft will expire on March 1, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Benchmarking Methodologies defined in RFC2544 [8] are IP version The Benchmarking Methodologies defined in RFC2544 [8] are IP version
independent however, they do not address some of the specificities of independent. However, RFC 2544 does not address some of the
IPv6. This document provides additional benchmarking guidelines specificities of IPv6. This document provides additional
which in conjunction with RFC2544 lead to a more complete and benchmarking guidelines, which in conjunction with RFC2544, lead to a
realistic evaluation of the IPv6 performance of network elements. more complete and realistic evaluation of the IPv6 performance of
network interconnect devices. IPv6 transition mechanisms are outside
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 . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . 5
5.2. Protocol Addresses Selection . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2.1. Filter Format . . . . . . . . . . . . . . . . . . . . 9 6.2.1. Filter Format . . . . . . . . . . . . . . . . . . . . 10
6.2.2. Filter Types . . . . . . . . . . . . . . . . . . . . . 10 6.2.2. Filter Types . . . . . . . . . . . . . . . . . . . . . 10
7. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . . 11 7. Benchmarking Tests . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . . . . . . . 15 A.1. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 16
A.2. Packet over SONET . . . . . . . . . . . . . . . . . . . . 16 A.2. Packet over SONET . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
The benchmarking methodologies defined by RFC2544 [8] are proving to The benchmarking methodologies defined by RFC2544 [8] 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 are meant to complement the test and result analysis framework and complement the test and result analysis procedures as
procedures as described in RFC2544 and not replace them. 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" [6]. in "Benchmarking Terminology for Network Interconnect Devices"
This terminology SHOULD be consulted before using or applying the RFC1242 [6]. This terminology SHOULD be consulted before using or
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].
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
of standards track documents as clear as possible. While this of standards track documents as clear as possible. While this
document uses these keywords, this document is not a standards track document uses these keywords, this document is not a standards track
document. document.
3. Tests and Results Evaluation 3. Tests and Results Evaluation
The recommended performance evaluation tests are described in Section The recommended performance evaluation tests are described in Section
6 of this document. Not all of these tests are applicable to all 7 of this document. Not all of these tests are applicable to all
network element types. Nevertheless, for each evaluated device it is network element types. Nevertheless, for each evaluated device, it
recommended to perform as many of the applicable tests described in is recommended to perform as many of the applicable tests described
Section 6 as possible. in Section 6 as possible.
Test execution and the results analysis MUST be performed while Test execution and results analysis MUST be performed while observing
observing generally accepted testing practices regarding generally accepted testing practices regarding repeatability,
repeatability, variance and statistical significance of small numbers 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 those described in Section 6
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 is used in measuring per interface forwarding port testing measures per-interface forwarding performance while
performance while multi-port testing is used to measure the multi-port testing measures the scalability of forwarding performance
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 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 collected through the interfaces
collected through the interfaces forwarding the test traffic. 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 is supported by the test tool. The dynamic option is preferred
wherein the test tool interacts with the DUT for the duration of the wherein the test tool interacts with the DUT for the duration of the
test to maintain the respective neighbor caches in an active state. test to maintain the respective neighbor caches in an active state.
To avoid neighbor solicitation (NS) and neighbor advertisement (NA) To avoid neighbor solicitation (NS) and neighbor advertisement (NA)
storms due to the neighbor unreachability detection (NUD) mechanism storms due to the neighbor unreachability detection (NUD) mechanism
[3], the test scenarios assume the test traffic simulates end points [3], the test scenarios assume test traffic simulates end points and
and the IPv6 source and destination addresses are one hop beyond the IPv6 source and destination addresses are one hop beyond the DUT.
DUT.
5. Test Traffic 5. Test Traffic
The traffic used for all tests described in this document SHOULD meet Traffic used for all tests described in this document SHOULD meet the
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 in designed to reflect the characteristics of IPv6 unicast traffic.
all its aspects. Using the recommended IPv6 traffic profile leads to Using the recommended IPv6 traffic profile leads to a complete
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
Two types of media are commonly deployed and each SHOULD be tested if Two types of media are commonly deployed and each SHOULD be tested if
the network element supports that type of media: Ethernet and SONET. the network element supports that type of media: Ethernet and SONET.
This section identifies the frame sizes that SHOULD be used for each This section identifies the frame sizes that SHOULD be used for each
media type. Refer to recommendations in RFC2544 for all other media media type. Refer to recommendations in RFC2544 for all other media
types. 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
size (40 bytes) is larger than that of an IPv4 packet (20 bytes). size (40 bytes) is larger than that of an IPv4 packet (20 bytes).
Tests should compensate for this difference. Tests should compensate for this difference.
The frame sizes listed for IPv6 include the extension headers used in The frame sizes listed for IPv6 include the extension headers used in
testing (see section 4.3). By definition, extension headers are part testing (see section 5.3). By definition, extension headers are part
of the IPv6 packet payload. Depending on the total length of the of the IPv6 packet payload. Depending on the total length of the
extension headers, their use might not be possible at the smallest extension headers, their use might not be possible at the smallest
frame sizes. frame sizes.
Note: Test tools are commonly using signatures to identify test Note: Test tools are commonly using signatures to identify test
traffic packets to verify that there are no packet drops, out of traffic packets to verify that there are no packet drops, out of
order packets or to calculate various statistics such as delay and order packets or to calculate various statistics such as delay and
jitter. This could be the reason why the minimum frame size jitter. This could be the reason why the minimum frame size
selectable through the test tool might not be as low as the selectable through the test tool might not be as low as the
theoretical one presented in this document. theoretical one presented in this document.
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 Ethernet in all its types has become the most commonly deployed media
interface in today's networks. The following frame sizes SHOULD be in today's networks. The following frame sizes SHOULD be used for
used for benchmarking over this media type: 64, 128, 256, 512, 1024, benchmarking over this media type: 64, 128, 256, 512, 1024, 1280,
1280, 1518 bytes. Tests with jumbo frames SHOULD be executed. Frame 1518 bytes.
sizes should be selected based on the values supported by the device
under test due to the absence of a common standard defining the jumbo Note: The recommended 1518 bytes frame size represents the maximum
frame sizes. Examples of common jumbo frame sizes are: 4096, 8192, size of an untagged Ethernet frame. According to the IEEE 802.3as
9216 bytes. The maximum frame rates for each frame size and the standard [12], the frame size can be increased up to 2048 bytes to
various Ethernet interface types are provided in Appendix A. accommodate frame tags.
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, 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 5.1.2. Frame Sizes to be used on SONET
Packet over SONET (PoS) interfaces are commonly used for edge 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: 53, 64, 128, 256, frame sizes SHOULD be used for this media type: 47, 64, 128, 256,
512, 1024, 1280, 1518, 2048, 4096 bytes. The maximum frame rates for 512, 1024, 1280, 1518, 2048, 4096 bytes.
each frame size and the various PoS interface types are provided in
Appendix A. Note: The 47 bytes SONET frame has no practical use since it can
carry only the 40 bytes header of an IPv6 packet and no upper layer
protocol information. It represents however the smallest frame size
for this media type.
The maximum frame rates for each frame size and the various PoS
interface types are provided in 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
selection considerations MUST be analyzed: The selection of IP selection considerations MUST be analyzed: The selection of IP
addresses for the DUT and the selection of addresses for the test addresses for the DUT and the selection of addresses for test
traffic. traffic.
5.2.1. DUT Protocol Addresses 5.2.1. DUT Protocol Addresses
IANA reserved the IPv6 address block xxxxx/48 for use with IPv6 IANA reserved an IPv6 address block for use with IPv6 benchmark
benchmark testing. These addresses MUST be assumed to be not testing (see section 8). It MAY be assumed that addresses in this
routable on the Internet and MUST not be used as Internet source or block are not globally routable and they MUST NOT be used as Internet
destination addresses. source or destination addresses.
Note to IANA: Replace "xxxxx" with assigned prefix.
Similar to RFC2544, Appendix C, addresses from the first half of this Similar to RFC2544, Appendix C, addresses from the first half of this
range SHOULD be used for the ports viewed as input and addresses from range SHOULD be used for the ports viewed as input and addresses from
the other half of the range for the output ports. the other half of the range for the output ports.
The prefix length of the IPv6 addresses configured on the DUT The prefix length of the IPv6 addresses configured on the DUT
interfaces MUST fall into either one of the following: interfaces MUST fall into either of the following:
o Prefix length is /126 which would simulate a point-to-point link o Prefix length is /126 which would simulate a point-to-point link
for a core router. for a core router.
o Prefix length is smaller or equal to /64. o Prefix length is smaller or equal to /64.
No prefix lengths SHOULD be selected in the range between 64 and 128 No prefix lengths SHOULD be selected in the range between 64 and 128
except the 126 value mentioned above. except the 126 value mentioned above.
Note that /126 prefixes might not be always the best choice for Note that /126 prefixes might not be always the best choice for
addressing point-to-point links such as back-to-back Ethernet unless addressing point-to-point links such as back-to-back Ethernet unless
the autoprovisioning mechanism is disabled. Also, not all network the autoprovisioning mechanism is disabled. Also, not all network
elements support addresses of this prefix length. elements support addresses of this prefix length.
While with IPv6, the DUT interfaces can be configured with multiple While with IPv6, the DUT interfaces can be configured with multiple
global unicast addresses, the methodology described in this document global unicast addresses, the methodology described in this document
does not require testing such a scenario. It is not expected that does not require testing such a scenario. It is not expected that
such an evaluation would bring additional data with respect to the such an evaluation would bring additional data regarding the
performance of the network element. performance of the network element.
The Interface ID portion of global unicast IPv6 DUT addresses SHOULD The Interface ID portion of global unicast IPv6 DUT addresses SHOULD
be set to ::1. There are no requirements in the selection of the be set to ::1. There are no requirements in the selection of the
Interface ID portion of the link local IPv6 addresses. Interface ID portion of the link local IPv6 addresses.
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 prefix lengths: 48, 64, 126 and 128 for conducted using the following prefix lengths: 48, 64, 126 and 128 for
the advertised traffic destination prefix. Other prefix lengths can the advertised traffic destination prefix. Other prefix lengths can
be used. However the indicated range reflects major prefix be used. However the indicated range reflects major prefix
boundaries expected to be present in IPv6 routing tables and they boundaries expected to be present in IPv6 routing tables and they
should be representative to establish baseline performance metrics. should be representative 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 IPv6 source and destination addresses for the test streams SHOULD
belong to the IPv6 range assigned by IANA as discussed in section belong to the IPv6 range assigned by IANA as defined in section 8.
5.2.1. The source addresses SHOULD belong to one half of the range The source addresses SHOULD belong to one half of the range and the
and the destination addresses to the other, reflecting the DUT destination addresses to the other, reflecting the DUT interface IPv6
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 Special care needs to be taken about the neighbor unreachability
detection (NUD) [3] process. The IPv6 prefix reachable time in the detection (NUD) [3] process. The IPv6 prefix reachable time in the
skipping to change at page 7, line 35 skipping to change at page 7, line 40
(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 [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. They can be headers and traffic that has a set of extension headers. Extension
selected from the following list [2] which reflects the recommended header types can be selected from the following list [2] which
order of multiple extension headers in a packet: 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 (ESP) header
o Destination options header o Destination options header
o Mobility header o Mobility header
Considering that extension headers are an intrinsic part of the Since extension headers are an intrinsic part of the protocol and
protocol and that they fulfill different roles, benchmarking of that they fulfill different roles, benchmarking of traffic containing
traffic containing each extension header SHOULD be executed each extension header SHOULD be executed individually.
individually.
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 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 its will not measure the forwarding performance of the DUT, but rather
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 [8] as in the
case of the other extension headers but rather to evaluate the impact case of the other extension headers, but rather to evaluate the
of such traffic on the router. In this case, traffic with the Hop- impact of such traffic on the router. In this case, traffic with the
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.
The tests with traffic containing each individual extension header Tests with traffic containing each individual extension header MUST
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). The chain should also exclude the ESP [5] extension header). This chain should also exclude the ESP [5]
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 to be used in 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
This is a real life extension header chain that would be found in an 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 IPv6 packet between two mobile nodes exchanged over an optimized path
that requires fragmentation. The listed extension headers lengths that requires fragmentation. The listed extension headers lengths
represent test tool defaults. The total length of the extension represent test tool defaults. The total length of the extension
header chain SHOULD be larger than 32 bytes. header 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 value SHOULD be selected for the them at low frame size, a common value SHOULD be selected for the
smallest frame size both types of traffic. smallest frame size of both types of traffic.
For most cases, the network elements ignore the extension headers For most cases, the network elements ignore the extension headers
when forwarding IPv6 traffic. For these reasons it is likely that when forwarding IPv6 traffic. For these reasons it is likely the
the extension headers related performance impact will be observed performance impact related to extension headers will be observed only
only when testing the DUT with traffic filters that contain matching when testing the DUT with traffic filters that contain matching
conditions for the upper layer protocol information. In those cases, conditions for the upper layer protocol information. In those cases,
the DUT MUST traverse the chain of extension headers, a process that the DUT MUST traverse the chain of extension headers, a process that
could impact performance. could impact performance.
5.4. Traffic set up 5.4. Traffic set up
All tests recommended in this document SHOULD be performed with bi- All tests recommended in this document SHOULD be performed with bi-
directional traffic. For asymmetric situations, tests MAY be directional traffic. For asymmetric situations, tests MAY be
performed with unidirectional traffic for a more granular performed with unidirectional traffic for a more granular
characterization of the DUT performance. In these cases, the characterization of the DUT performance. In these cases, the
skipping to change at page 9, line 25 skipping to change at page 9, line 33
performance between the two directions. performance between the two directions.
All other traffic profile characteristics described in RFC2544 SHOULD All other traffic profile characteristics described in RFC2544 SHOULD
be applied in this testing as well. IPv6 multicast benchmarking is be applied in this testing as well. IPv6 multicast benchmarking is
outside the scope of this document. outside the scope of this document.
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 except that IPv6 does not employ layer 2 or 3 broadcast frames. IPv6
layer 3 broadcasts. This section provides additional conditions that does not use layer 2 or layer 3 broadcasts. This section provides
are specific to IPv6. The suite of tests recommended in this additional conditions that are specific to IPv6. The suite of tests
document SHOULD be first executed in the absence of these conditions recommended in this document SHOULD be first executed in the absence
and then repeated under each of these conditions separately. of these conditions 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 must be expanded to
expanded to include upper layer protocol information matching in include upper layer protocol information matching in order to analyze
order to analyze the handling of traffic with extension headers which the handling of traffic with extension headers which are an important
are an important architectural component of IPv6. architectural component of IPv6.
6.2.1. Filter Format 6.2.1. Filter Format
The filter format defined in RFC2544 is applicable to IPv6 as well The filter format defined in RFC2544 is applicable to IPv6 as well
except that the source addresses (SA) and destination addresses (DA) except that the source addresses (SA) and destination addresses (DA)
are IPv6. In addition to these basic filters, the evaluation of IPv6 are IPv6 addresses. In addition to these basic filters, the
performance SHOULD analyze the correct filtering and handling of evaluation of IPv6 performance SHOULD analyze the correct filtering
traffic with extension headers. and handling of traffic with extension headers.
While the intent is not to evaluate a platform's capability to While the intent is not to evaluate a platform's capability to
process the various extension header types, the goal is to measure process the various extension header types, the goal is to measure
performance impact when the network element must parse through the performance impact when the network element must parse through the
extension headers in order to reach upper layer information. In extension headers to reach upper layer information. In IPv6, routers
IPv6, routers do not have to parse through the extension headers do not have to parse through the extension headers (other than hop-
(other than Hop-by-hop) unless, for example, the upper layer by-hop) unless, for example, upper layer information has to be
information has to be analyzed due to filters. analyzed due to filters.
For these reasons, to evaluate the network element handling of IPv6 To evaluate the network element handling of IPv6 traffic with
traffic with extension headers, the definition of the filters must be extension headers, the definition of the filters must be extended to
extended to include conditions applied to upper layer protocol include conditions applied to upper layer protocol information. The
information. The following filter format SHOULD be used for this following filter format SHOULD be used for this type of evaluation:
type of evaluation:
[permit|deny] [protocol] [SA] [DA] [permit|deny] [protocol] [SA] [DA]
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. The upper layer protocols listed above are recommended address.
selection, however they do not represent an all-inclusive list of
upper layer protocols which could be used in defining filters. The upper layer protocols listed above are recommended selection.
However, they do not represent an all-inclusive list of upper layer
protocols which could be used in defining filters.
6.2.2. Filter Types 6.2.2. Filter Types
Based on the 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 one with 25 filters. The recommended filters are single filter and another with 25 filters. Examples of recommended
exemplified with the help of the IPv6 documentation prefix [10] 2001: filters are illustrated using the IPv6 documentation prefix [10]
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
extension headers from IPv6 SA 2001:DB8::1 to IPv6 DA 2001:DB8::2 and extension headers from IPv6 SA 2001:DB8::1 to IPv6 DA 2001:DB8::2 and
skipping to change at page 11, line 33 skipping to change at page 11, line 43
7. Benchmarking Tests 7. Benchmarking Tests
This document recommends the same benchmarking tests described in This document recommends the same benchmarking tests described in
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. The tests
sense, the tests recommended by RFC2544 MUST be repeated for IPv6 recommended by RFC2544 MUST be repeated for IPv6 traffic without
traffic without extension headers and with one or multiple extension extension headers and for IPv6 traffic with one or multiple extension
headers. headers.
IPv6's deployment in existing IPv4 environments and the expected long IPv6's deployment in existing IPv4 environments and the expected long
co-existence of the two protocols leads network operators to place co-existence of the two protocols leads network operators to place
great emphasis on understanding the performance of platforms great emphasis on understanding the performance of platforms
forwarding both types of traffic. While device resources are shared processing both types of traffic. While device resources are shared
between the two protocols, it is important for IPv6 enabled platforms between the two protocols, it is important that IPv6-enabled
to not experience degraded IPv4 performance. Thus, IPv6 benchmarking platforms not experience degraded IPv4 performance. Thus, IPv6
SHOULD be performed in the context of a stand alone protocol as well benchmarking SHOULD be performed in the context of a stand alone
as in the context of its co-existence with IPv4. 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 header specific conditions: Extension header 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
section 4.3 section 5.3
iii) IPv6 traffic with the chain of extension headers described in iii) IPv6 traffic with the chain of extension headers described in
section 4.3 section 5.3
Co-existence specific conditions: Co-existence specific conditions:
iv) IPv4 ONLY traffic benchmarking iv) IPv4 ONLY traffic benchmarking
v) IPv6 ONLY traffic benchmarking v) IPv6 ONLY traffic benchmarking
vi) IPv4-IPv6 traffic mix with the ratio 90% vs 10% vi) IPv4-IPv6 traffic mix with the ratio 90% vs 10%
vii) IPv4-IPv6 traffic mix with the ratio 50% vs 50% vii) IPv4-IPv6 traffic mix with the ratio 50% vs 50%
viii) IPv4-IPv6 traffic mix with the ratio 10% vs 90% viii) IPv4-IPv6 traffic mix with the ratio 10% vs 90%
Combining the test conditions listed for benchmarking IPv6 as a Combining the test conditions listed for benchmarking IPv6 as a
stand-alone protocol and the co-existence tests leads to a large stand-alone protocol and the co-existence tests leads to a large
coverage matrix. A minimum requirement is to cover the co-existence coverage matrix. At a minimum requirement, the co-existence tests
conditions in the case of IPv6 with no extension headers and those should use IPv6 traffic with no extension headers and the 10%-90%,
where either of the traffic is 10% and 90% respectively. 90%-10% IPv4/IPv6 traffic mix.
The subsequent sections describe each specific tests that MUST be The subsequent sections each describe specific tests that MUST be
executed under the conditions listed above for a complete executed under the conditions listed above for a complete
benchmarking of IPv6 forwarding performance. benchmarking of IPv6 forwarding performance.
7.1. Throughput 7.1. Throughput
Objective: To determine the DUT throughput as defined in RFC1242. Objective: To determine the DUT throughput as defined in RFC1242.
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 11 skipping to change at page 13, line 19
Objective: To determine the frame loss rate, as defined in RFC1242, Objective: To determine the frame loss rate, as defined in RFC1242,
of a DUT throughout the entire range of input data rates and frame of a DUT throughout the entire range of input data rates and frame
sizes. sizes.
Procedure: Same as RFC2544. Procedure: Same as RFC2544.
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- Based on the IPv4 experience, the back-to-back frames test is
back frames as defined in RFC1242.
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 no longer the processing flow. For these reasons, this test is no longer
recommended for IPv6 benchmarking. recommended 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.
skipping to change at page 14, line 30 skipping to change at page 14, line 34
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 [8], is for the most part applicable to evaluating
the IPv6 performance of network elements. This document is the IPv6 performance of network elements. This document addresses
addressing the IPv6 specific requirements that MUST be observed when the IPv6 specific requirements that MUST be observed when applying
applying the recommendations of RFC2544. These additional the recommendations of RFC2544. These additional requirements stem
requirements stem from the architecture characteristics of IPv6. from the architecture characteristics of IPv6. This document is not
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
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 Tom Alexander, Bill
Dry, Sven Lanckmans, Dean Lee, Athanassios Liakopoulos, Benoit Cerveny, Silvija Dry, Sven Lanckmans, Dean Lee, Athanassios
Lourdelet, Al Morton, Rajiv Papejna and Pekka Savola for their very Liakopoulos, Benoit Lourdelet, Al Morton, David Newman, Rajiv
helpful feedback. Maryam Hamza inspired the authors in completing Papejna, Dan Romascanu and Pekka Savola for their very helpful
this document. 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] 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.
skipping to change at page 15, line 41 skipping to change at page 15, line 44
Network Interconnect Devices", RFC 2544, March 1999. Network Interconnect Devices", RFC 2544, March 1999.
[9] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. [9] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[10] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix [10] 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 [11] 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
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.
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 16 skipping to change at page 16, line 28
------------------------------ ------------------------------
(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 throughput for various Ethernet the inter frame gap (12 bytes). The throughput for various Ethernet
interface types and frame sizes: 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 14880 148809 1488095 14880952 64 14,880 148,809 1,488,095 14,880,952
128 8445 84459 844594 8445945 128 8,445 84,459 844,594 8,445,945
256 4528 45289 452898 4528985 256 4,528 45,289 452,898 4,528,985
512 2349 23496 234962 2349624 512 2,349 23,496 234,962 2,349,624
1024 1197 11973 119731 1197318 1024 1,197 11,973 119,731 1,197,318
1280 961 9615 96153 961538 1280 961 9,615 96,153 961,538
1518 812 8127 81274 812743 1518 812 8,127 81,274 812,743
4096 303 3036 30396 303691 2048 604 6,044 60,444 604,448
8192 152 1522 15221 152216 4096 303 3,036 30,396 303,691
9216 135 1353 13534 135339 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 Note: Ethernet's maximum frame rates are subject to variances due to
clock slip. 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)
skipping to change at page 17, line 9 skipping to change at page 17, line 21
Line Rate (bps) Line Rate (bps)
------------------------------ ------------------------------
(8bits/byte)*(X+1)bytes/frame (8bits/byte)*(X+1)bytes/frame
The maximum throughput for various PoS interface types and frame The maximum throughput for various PoS interface types and frame
sizes: sizes:
Size OC-3c OC-12c OC-48c OC-192c OC-768c Size OC-3c OC-12c OC-48c OC-192c OC-768c
Bytes fps fps fps fps fps Bytes fps fps fps fps fps
53 346,666 1,386,666 5,546,666 22,186,666 88,746,666 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 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
 End of changes. 58 change blocks. 
167 lines changed or deleted 186 lines changed or added

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