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
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
网络互连设备的IPv6基准测试方法
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.
RFC 2544中定义的基准测试方法与IP版本无关。然而，RFC2544并没有解决IPv6的一些特殊性。本文档提供了额外的基准测试指南，该指南与RFC 2544结合使用，可对网络互连设备的IPv6性能进行更全面、更现实的评估。IPv6转换机制不在本文档的范围内。
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 ....................................................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
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).
RFC 2544[9]定义的基准测试方法在一致评估网络元件的IPv4转发性能方面被证明是有用的。遵守这些测试和结果分析程序有助于客观比较各种产品和个人的IPv4性能数据。虽然RFC 2544中引入的方法背后的原则在很大程度上与IP版本无关，但该协议仍在不断发展，特别是在其版本6（IPv6）中。
This document provides benchmarking methodology recommendations that address IPv6-specific aspects, such as evaluating the forwarding performance of traffic containing extension headers, as defined in 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.
本文档提供了针对IPv6特定方面的基准测试方法建议，如评估RFC 2460[2]中定义的包含扩展头的流量的转发性能。这些建议在RFC 2544框架内定义，它们补充了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.
本文件中使用的术语与“网络互连设备基准术语”RFC 1242[7]中定义的术语保持一致。在使用或应用本文件的建议之前，应参考本术语。
Any methodology aspects not covered in this document SHOULD be assumed to be treated based on the RFC 2544 recommendations.
本文件中未涵盖的任何方法方面均应假定根据RFC 2544建议进行处理。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。RFC 2119定义了这些关键词的使用，以帮助尽可能明确标准跟踪文档的意图。虽然本文档使用了这些关键词，但本文档不是标准跟踪文档。
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.
本文件第7节介绍了推荐的性能评估试验。并非所有这些测试都适用于所有网元类型。然而，对于每个评估的装置，建议尽可能多地进行第6节所述的适用试验。
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.
测试执行和结果分析必须在遵守关于少量试验的重复性、方差和统计显著性的公认测试实践的同时进行。
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.
在单端口和多端口情况下，建议用于IPv6性能评估的测试环境设置选项与RFC 2544第6节中描述的相同。单端口测试测量每个接口的转发性能，而多端口测试测量整个平台转发性能的可伸缩性。
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.
在整个测试过程中，可以监控被测设备（DUT）的相关资源（处理器、内存等）利用率。这些数据有助于理解每个DUT的流量处理以及必须为IPv6分配的资源。它可以揭示IPv6流量是在所有测试条件下由适用设备在硬件中处理的，还是在软件交换路径中处理的。如果此类数据被认为是有意义的，则必须在带外收集，并独立于通过转发测试流量的接口收集的任何管理数据。
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.
注意：在测试期间，可以使用邻居发现的静态或动态选项。在静态情况下，在DUT上手动配置测试工具的IPv6邻居信息，在测试工具上手动配置DUT的IPv6邻居信息。在动态情况下，每个设备通过邻居发现协议动态发现IPv6邻居信息。只要测试工具支持静态选项，就可以使用它。优选动态选项，其中测试工具在测试期间与DUT交互，以保持各个相邻缓存处于活动状态。为了避免邻居不可达性检测（NUD）机制[6]导致的邻居请求（NS）和邻居广告（NA）风暴，测试场景假设测试流量模拟DUT外一跳的端点和IPv6源地址和目标地址。
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.
本文件中描述的所有测试使用的流量应满足本节中描述的要求。这些要求旨在反映IPv6单播流量的特征。使用推荐的IPv6流量配置文件可以对网元性能进行全面评估。
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.
通常部署两种类型的介质，如果网元支持这种介质，则应对每种介质进行测试：以太网和SONET（同步光网络）。本节确定了每种媒体类型应使用的帧大小。有关所有其他介质类型，请参阅RFC 2544中的建议。
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.
与IPv4类似，小帧大小有助于描述DUT的每帧处理开销。请注意，IPv6数据包的最小大小（40字节）大于IPv4数据包的最小大小（20字节）。测试应该补偿这种差异。
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.
为IPv6列出的帧大小包括测试中使用的扩展标头（请参阅第5.3节）。根据定义，扩展头是IPv6数据包有效负载的一部分。根据扩展标头的总长度，在最小的帧大小下可能无法使用它们。
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.
注意：测试工具通常使用签名来识别测试流量数据包，以验证是否存在丢包或无序数据包，或者计算各种统计信息，如延迟和抖动。这可能是为什么通过测试工具选择的最小帧大小可能不如本文中给出的理论值低的原因。
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.
各种类型的以太网已成为当今网络中最常用的部署介质。以下帧大小应用于此媒体类型的基准测试：64、128、256、512、1024、1280和1518字节。
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].
注意：建议的1518字节帧大小表示未标记以太网帧的最大大小。根据IEEE 802.3as标准[13]，帧大小可增加至2048字节，以适应IEEE 802.1AE MAC[14]安全协议要求的帧标签和其他封装。根据802.1D[15]，操作环境中常用的帧大小为1522字节，即VLAN标记帧的最大长度。
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.
注：虽然巨型帧不在802.3 IEEE标准的范围内，但测试时应根据被测设备支持的值选择帧大小。常用巨型帧大小的示例有：4096、8192和9216字节。
The maximum frame rates for each frame size and the various Ethernet interface types are provided in Appendix A.
附录A中提供了每种帧大小和各种以太网接口类型的最大帧速率。
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.
SONET数据包（PoS）接口通常用于边缘上行链路和高带宽核心链路。建议评估DUT支持的PoS接口的转发性能。此媒体类型应使用以下帧大小：47、64、128、256、512、1024、1280、1518、2048、4096字节。
The theoretical maximum frame rates for each frame size and the various PoS interface types are provided in Appendix A.
附录A中提供了每种帧大小和各种PoS接口类型的理论最大帧速率。
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.
IPv6基准测试的两个方面必须分析IP地址选择的考虑因素：DUT的IP地址选择和测试流量的地址选择。
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.
IANA保留了一个IPv6地址块，用于IPv6基准测试（参见第8节）。可以假设此块中的地址不可全局路由，并且它们不得用作Internet源地址或目标地址。
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.
与RFC 2544的附录C类似，此范围前半部分的地址应用于被视为输入的端口，而另一半范围的地址应用于输出端口。
The prefix length of the IPv6 addresses configured on the DUT interfaces MUST fall into either of the following:
DUT接口上配置的IPv6地址的前缀长度必须符合以下任一条件：
o Prefix length is /126, which would simulate a point-to-point link for a core router.
o 前缀长度为/126，这将模拟核心路由器的点到点链路。
o Prefix length is smaller or equal to /64.
o 前缀长度小于或等于/64。
No prefix lengths SHOULD be selected in the range between 64 and 128 except the 126 value mentioned above.
除上述126值外，不应在64和128之间选择前缀长度。
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.
请注意，除非禁用自动资源调配机制，否则/126前缀可能并不总是寻址点到点链路（如背靠背以太网）的最佳选择。此外，并非所有网元都支持此前缀长度的地址。
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.
使用IPv6时，DUT接口可以配置多个全局单播地址，本文档中描述的方法不需要测试此类场景。预计这种评估不会带来关于网元性能的额外数据。
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.
全局单播IPv6 DUT地址的接口ID部分应设置为：：1。链路本地IPv6地址的接口ID部分的选择没有要求。
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.
建议使用以下前缀长度执行基准测试的多次迭代：48、64、126和128用于公布的流量目的地前缀。可以使用其他前缀长度。但是，指示的范围反映了IPv6路由表中预期存在的主要前缀边界，它们应该具有代表性，以建立基线性能指标。
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.
测试流的IPv6源地址和目标地址应属于IANA分配的IPv6范围，如第8节所定义。源地址应属于范围的一半，目标地址应属于另一半，反映DUT接口IPv6地址选择。
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.
测试应首先使用单个流执行，该流利用单个源-目标地址对。然后，应使用相应范围内的随机目标地址对通信量重复测试。如果评估了网元前缀查找功能，则测试应重点关注IPv6相关的前缀边界：0-64、126和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.
注意：当不使用静态定义的邻居时，应一致设置影响邻居不可达性检测的参数。路由器公告中的IPv6前缀可到达时间应设置为30秒。
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:
扩展头是IPv6体系结构的固有部分[2]。它们用于各种类型的实际流量，例如：碎片流量、基于移动IP的流量以及经过身份验证和加密的流量。由于这些原因，本文档中描述的所有测试都应该使用没有扩展头的通信量和具有一组扩展头的通信量来执行。可从以下列表[2]中选择扩展标头类型，该列表反映了数据包中多个扩展标头的建议顺序：
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
o 逐跳标头o目的地选项标头o路由标头o片段标头o身份验证标头o封装安全有效负载（ESP）标头o目的地选项标头o移动性标头
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.
逐跳扩展标头的特殊处理规则需要特定的基准测试方法。与其他扩展标头不同，此标头必须由转发流量的每个节点处理。使用包含这些扩展头类型的通信量进行的测试将不会测量DUT的转发性能，而是测量其扩展头处理能力，这取决于扩展头中包含的信息。令人担忧的是，高速率的流量可能会对路由器的操作资源产生负面影响，并可能被用作安全威胁。当对包含逐跳扩展头的流量进行基准测试时，目标不是像其他扩展头那样测量吞吐量[9]，而是评估此类流量对路由器的影响。在这种情况下，带有逐跳扩展头的通信量应以接口总带宽的1%、10%和50%发送。必须以每个通信速率监控设备资源，以确定影响。
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:
包含每个扩展头的流量测试必须与包含两个或多个扩展头链的测试互补（该链不得包含逐跳扩展头）。该链还应排除ESP[5]扩展头，因为带有加密有效负载的流量不能用于带有修改器（如基于上层信息的过滤器）的测试（见第5节）。由于DUT没有分析扩展头的内容，因此可以在测试中使用扩展头的任何组合。推荐用于测试的延伸收割台链为：
o Routing header - 24-32 bytes o Destination options header - 8 bytes o Fragment header - 8 bytes
o 路由标头-24-32字节o目标选项标头-8字节o片段标头-8字节
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.
这是一个真实的扩展头链，可以在两个移动节点之间的IPv6数据包中找到，这两个移动节点通过需要分段的优化路径进行交换。列出的扩展标题的长度表示测试工具的默认值。扩展标头链的总长度应大于32字节。
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
扩展头向IP数据包的有效负载大小添加额外的字节，当在低帧大小的测试中使用时，必须将其考虑在内。它们的存在将修改应用程序中使用的最小数据包大小
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.
在大多数情况下，转发IPv6流量时，网元会忽略扩展标头。由于这些原因，只有在使用包含上层协议信息匹配条件的流量过滤器测试DUT时，才可能观察到与扩展头相关的性能影响。在这些情况下，DUT必须遍历扩展头链，这一过程可能会影响性能。
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.
本文件中建议的所有试验应在双向交通条件下进行。对于非对称情况，可使用单向通信量进行测试，以更精确地描述DUT性能。在这些情况下，双向流量测试只能显示两个方向之间的最低性能。
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.
RFC 2544中描述的所有其他流量剖面特征也应应用于该测试。IPv6多播基准测试不在本文档的范围内。
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.
RFC 2544强调了在某些操作条件下评估网元性能的重要性。RFC 2544第11节中定义的条件对于IPv4和IPv6是通用的，但IPv6不使用第2层或第3层广播帧。IPv6不使用第2层或第3层广播。本节提供特定于IPv6的附加条件。本文件中建议的一系列试验应首先在没有这些条件的情况下进行，然后在每个条件下分别重复。
The procedures defined in Sections 11.2 and 11.3 of RFC 2544 are applicable for IPv6 management and routing update frames as well.
RFC 2544第11.2和11.3节中定义的程序也适用于IPv6管理和路由更新帧。
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.
RFC 2544第11.4节中定义的过滤器也适用于IPv6基准测试。必须扩展过滤器定义，以包括上层协议信息匹配，以便分析使用扩展头的流量处理，扩展头是IPv6的一个重要架构组件。
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.
RFC 2544中定义的筛选器格式也适用于IPv6，但源地址（SA）和目标地址（DA）是IPv6地址除外。除了这些基本过滤器外，IPv6性能评估还应分析使用扩展头对流量的正确过滤和处理。
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.
虽然目的不是评估平台处理各种扩展头类型的能力，但目标是在网元必须解析扩展头才能到达上层信息时测量性能影响。在IPv6中，路由器不必解析扩展头（逐跳解析除外），除非（例如）由于过滤器的原因必须分析上层信息。
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:
要使用扩展头评估IPv6流量的网元处理，必须扩展筛选器的定义，以包括应用于上层协议信息的条件。此类型的评估应使用以下筛选格式：
[permit|deny] [protocol] [SA] [DA]
[许可证|拒绝][协议][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:
其中，permit或deny表示通过应用筛选器的接口允许或拒绝数据包的操作。协议字段定义为：
o ipv6: any IP Version 6 traffic
o ipv6：任何IP版本6流量
o tcp: Transmission Control Protocol
o 传输控制协议
o udp: User Datagram Protocol
o 用户数据报协议
and SA stands for the source address and DA for the destination address.
SA代表源地址，DA代表目标地址。
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.
建议选择上面列出的上层协议。但是，它们并不代表可用于定义过滤器的上层协议的全包列表。这些基准测试建议中描述的过滤器适用于本机IPv6流量和在本机IPv6数据包中传输的上层协议（tcp、udp）。
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::.
根据RFC 2544建议，在存在修改器的情况下评估性能时，将执行两种类型的测试：一种使用单个过滤器，另一种使用25个过滤器。使用IPv6文档前缀[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
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.
单线筛选器案例应验证网元是否允许从IPv6 SA 2001:DB8:：1到IPv6 DA 2001:DB8:：2的所有TCP/UDP/IPv6通信，无论是否具有任何数量的扩展头，并拒绝所有其他通信。
Example of 25 filters:
25个过滤器的示例：
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
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.
路由器应拒绝所有带有或不带有扩展头的通信，除了带有SA 2001:DB8:99:：1和DA 2001:DB8:99:：2的TCP通信。
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.
本文件建议进行RFC 2544中所述的相同基准测试，同时观察上述DUT设置和流量设置注意事项。以下各节明确说明了测试类型，并且仅强调了与RFC 2544第26节中描述的方法可能存在的差异。
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的特殊性，特别是扩展头处理的定义，需要额外的基准测试步骤。对于不带扩展标头的IPv6通信和具有一个或多个扩展标头的IPv6通信，必须重复RFC 2544建议的测试。
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.
IPv6在现有IPv4环境中的部署以及这两种协议预期的长期共存导致网络运营商非常重视了解处理这两种类型流量的平台的性能。虽然设备资源在两个协议之间共享，但重要的是支持IPv6的平台不会出现IPv4性能降级的情况。因此，IPv6基准测试应该在独立协议以及与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
i) 不带扩展头的IPv6流量
ii) IPv6 traffic with one extension header from the list in Section 5.3
ii）具有第5.3节列表中一个扩展标头的IPv6流量
iii) IPv6 traffic with the chain of extension headers described in Section 5.3
iii）具有第5.3节所述扩展头链的IPv6流量
Coexistence-specific conditions:
共存特定条件：
iv) IPv4 ONLY traffic benchmarking
iv）仅IPv4流量基准测试
v) IPv6 ONLY traffic benchmarking
v) 仅IPv6流量基准测试
vi) IPv4-IPv6 traffic mix with the ratio 90% vs 10%
vi）IPv4-IPv6流量组合，比率为90%对10%
vii) IPv4-IPv6 traffic mix with the ratio 50% vs 50%
vii）IPv4-IPv6流量组合，比率为50%对50%
viii) IPv4-IPv6 traffic mix with the ratio 10% vs 90%
viii）IPv4-IPv6流量组合，比率为10%对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.
将IPv6作为独立协议进行基准测试时列出的测试条件与共存测试相结合，可以得到一个大的覆盖矩阵。在最低要求下，共存测试应使用不带扩展头的IPv6流量以及10%-90%、90%-10%或IPv4/IPv6流量组合。
The subsequent sections each describe specific tests that MUST be executed under the conditions listed above for a complete benchmarking of IPv6-forwarding performance.
后续章节分别描述了必须在上述条件下执行的特定测试，以便对IPv6转发性能进行完整的基准测试。
Objective: To determine the DUT throughput as defined in RFC 1242.
目的：确定RFC1242中定义的DUT吞吐量。
Procedure: Same as RFC 2544.
程序：与RFC 2544相同。
Reporting Format: Same as RFC 2544.
报告格式：与RFC 2544相同。
Objective: To determine the latency as defined in RFC 1242.
目的：确定RFC1242中定义的潜伏期。
Procedure: Same as RFC 2544.
程序：与RFC 2544相同。
Reporting Format: Same as RFC 2544.
报告格式：与RFC 2544相同。
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.
目标：确定DUT在整个输入数据速率和帧大小范围内的帧丢失率（如RFC 1242中所定义）。
Procedure: Same as RFC 2544.
程序：与RFC 2544相同。
Reporting Format: Same as RFC 2544.
报告格式：与RFC 2544相同。
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.
根据IPv4的经验，背对背帧测试的特点是由于处理流中的短期变化而产生显著差异。由于这些原因，不再建议将此测试用于IPv6基准测试。
Objective: To characterize the speed at which a DUT recovers from an overload condition.
目的：描述DUT从过载状态恢复的速度。
Procedure: Same as RFC 2544.
程序：与RFC 2544相同。
Reporting Format: Same as RFC 2544.
报告格式：与RFC 2544相同。
Objective: To characterize the speed at which a DUT recovers from a device or software reset.
目标：描述DUT从设备或软件复位中恢复的速度。
Procedure: Same as RFC 2544.
程序：与RFC 2544相同。
Reporting Format: Same as RFC 2544.
报告格式：与RFC 2544相同。
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.
IANA为IPv6基准测试分配了2001:0200:：/48，这是来自RFC 4773池的48位前缀。该分配类似于RFC 3330[10]中定义的198.18.0.0/15。此前缀长度（48）提供了与为IPv4基准测试分配的范围类似的灵活性，并考虑了地址保护和使用简单性问题。请求的大小满足测试大型网元和大型仿真网络的要求。
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.
注：与RFC 2544类似，避免使用RFC 1918地址空间进行基准测试，本文件不建议使用RFC 4193[4]（唯一本地地址），以尽量减少与操作流量冲突的可能性。
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.
基准网络拓扑将是一个独立的测试设置，不得连接到可能将测试流量转发到生产网络或将流量错误路由到测试管理网络的设备。
Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the DUT/SUT (System Under Test).
此外，基准测试是在“黑盒”基础上进行的，仅依赖于DUT/SUT（被测系统）外部可观察到的测量值。
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.
DUT/SUT中不应存在专门用于基准测试的特殊能力。DUT/SUT对网络安全的任何影响应在实验室和生产网络中相同。
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.
基准测试环境的孤立性以及DUT/SUT上除运行网络中使用的功能外没有启用任何特殊功能或能力的事实不需要针对基准测试过程的安全考虑。
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.
网络互连设备的基准测试方法文件RFC 2544[9]在很大程度上适用于评估网络元件的IPv6性能。本文件阐述了应用RFC 2544建议时必须遵守的IPv6特定要求。这些额外的需求源于IPv6的体系结构特征。本文件不是RFC 2544的替代品，而是RFC 2544的补充。
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.
Scott Bradner为本文件提供了宝贵的指导和建议。作者感谢Cynthia Martin和Jeff Dunn在定义IPv6基准术语方面所做的工作。作者感谢Bill Kine对初始文件的贡献，感谢Tom Alexander、Bill Cerveny、Silvija Dry、Sven Lanckmans、Dean Lee、Athanasios Liakopoulos、Benoit Lourdelet、Al Morton、David Newman、Rajiv Papejna、Dan Romascanu和Pekka Savola提供的非常有用的反馈。Maryam Hamza激励作者完成本文档。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[2] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[3] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June 1999.
[3] Malis，A.和W.Simpson，“SONET/SDH上的PPP”，RFC 26151999年6月。
[4] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[4] Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC4193，2005年10月。
[5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[5] Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[6] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[6] Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[7] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.
[7] Bradner，S.，“网络互连设备的基准术语”，RFC 1242，1991年7月。
[8] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[8] 辛普森，W.，编辑，“HDLC类框架中的PPP”，STD 51，RFC 16621994年7月。
[9] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[9] Bradner，S.和J.McQuaid，“网络互连设备的基准测试方法”，RFC 25441999年3月。
[10] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[10] IANA，“特殊用途IPv4地址”，RFC 3330，2002年9月。
[11] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004.
[11] Huston，G.，Lord，A.，和P.Smith，“保留用于文档的IPv6地址前缀”，RFC 3849，2004年7月。
[12] Newman, D. and T. Player, "Hash and Stuffing: Overlooked Factors in Network Device Benchmarking", RFC 4814, March 2007.
[12] Newman，D.和T.Player，“散列和填充：网络设备基准测试中被忽视的因素”，RFC 4814，2007年3月。
[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.
[13] IEEE计算机协会局域网/城域网标准委员会，“IEEE标准802.3as-2006，第3部分：带冲突检测的载波侦听多址接入（CSMA/CD）接入方法和物理层规范，修改件3：帧格式扩展”，2006年11月。
[14] Allyn Romanow (editor), "IEEE Std 802.3ae, Media Access Control (MAC) Security", June 2006.
[14] Allyn Romanow（编辑），“IEEE标准802.3ae，媒体访问控制（MAC）安全”，2006年6月。
[15] Mick Seaman (editor), "IEEE Std 802.1D-2004, MAC Bridges", February 2004.
[15] Mick Seaman（编辑），“IEEE标准802.1D-2004，MAC桥”，2004年2月。
This appendix provides the formulas to calculate and the values for the theoretical maximum frame rates for two media types: Ethernet and SONET.
本附录提供了两种媒体类型（以太网和SONET）的理论最大帧速率的计算公式和值。
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:
各种以太网接口类型和帧大小X的吞吐量（以每秒帧数（fps）为单位）可以使用以下公式计算：
Line Rate (bps)
------------------------------
(8bits/byte)*(X+20)bytes/frame
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:
公式中的20个字节是前导码（8字节）和帧间间隙（12字节）的总和。各种以太网接口类型和帧大小的吞吐量：
Size 10Mb/s 100Mb/s 1000Mb/s 10000Mb/s
Bytes pps pps pps pps
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
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.
注：以太网的最大帧速率会因时钟斜率而发生变化。所列速率为理论最大值，实际测试应考虑+/-100 ppm公差。
ANSI T1.105 SONET provides the formula for calculating the maximum available bandwidth for the various Packet over SONET (PoS) interface types:
ANSI T1.105 SONET提供了计算SONET上各种数据包（PoS）接口类型的最大可用带宽的公式：
STS-Nc (N = 3Y, where Y=1,2,3,etc)
STS Nc（N=3Y，其中Y=1,2,3等）
[(N*87) - N/3]*(9 rows)*(8 bit/byte)*(8000 frames/sec)
[(N*87) - N/3]*(9 rows)*(8 bit/byte)*(8000 frames/sec)
Packets over SONET can use various encapsulations: PPP [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):
SONET上的数据包可以使用各种封装：PPP[3]、高级数据链路控制（HDLC）[8]和帧中继。所有这些封装都使用一个4字节的报头、一个2字节或4字节的帧检查序列（FCS）字段和一个1字节的标志，所有这些都在整个帧大小中进行了说明。各种接口类型的最大帧速率可通过以下公式计算（其中X表示以字节为单位的帧大小）：
Line Rate (bps)
------------------------------
(8bits/byte)*(X+1)bytes/frame
Line Rate (bps)
------------------------------
(8bits/byte)*(X+1)bytes/frame
The theoretical maximum frame rates for various PoS interface types and frame sizes:
各种PoS接口类型和帧大小的理论最大帧速率：
Size OC-3c OC-12c OC-48c OC-192c OC-768c Bytes fps fps fps fps fps
大小OC-3c OC-12c OC-48c OC-192c OC-768c字节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
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.
需要注意的是，由于不同介质类型进行的比特填充，吞吐量测试结果可能与附录A.1和A.2中给出的值不同[12]。理论吞吐量数字向下舍入。
Authors' Addresses
作者地址
Ciprian Popoviciu Cisco Systems Kit Creek Road RTP, North Carolina 27709 USA
美国北卡罗来纳州克里克路RTP Ciprian Popoviciu Cisco Systems Kit Creek Road 27709
Phone: 919 787 8162 EMail: cpopovic@cisco.com
电话：919 787 8162电子邮件：cpopovic@cisco.com
Ahmed Hamza Cisco Systems 3000 Innovation Drive Kanata K2K 3E8 Canada
Ahmed Hamza Cisco Systems 3000创新大道加拿大卡纳塔K2K 3E8
Phone: 613 254 3656 EMail: ahamza@cisco.com
电话：613 254 3656电子邮件：ahamza@cisco.com
Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium
Gunter Van de Velde Cisco Systems de Kleetlaan 6a Diegem 1831比利时
Phone: +32 2704 5473
EMail: gunter@cisco.com
Phone: +32 2704 5473
EMail: gunter@cisco.com
Diego Dugatkin FastSoft, Inc. 150 S. Los Robles Ave. Pasadena, CA 91101 USA
Diego Dugatkin FastSoft，Inc.美国加利福尼亚州帕萨迪纳市洛斯罗伯斯大道南150号，邮编：91101
Phone: +1-626-357-7012
EMail: diego@fastsoft.com
Phone: +1-626-357-7012
EMail: diego@fastsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.