[要約] RFC 5180は、ネットワークインターコネクトデバイスのIPv6ベンチマーキング方法論に関するものです。このRFCの目的は、IPv6ネットワークインターコネクトデバイスの性能評価と比較を可能にするための一貫した方法論を提供することです。
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バージョンに依存しません。ただし、RFC 2544は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
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.
このドキュメントは、RFC 2460 [2]で定義されているように、拡張ヘッダーを含むトラフィックの転送パフォーマンスの評価など、IPv6固有の側面に対処するベンチマークの方法論的推奨事項を提供します。これらの推奨事項は、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.
このドキュメントで使用される用語は、「ネットワーク相互接続デバイスのベンチマーク用語」で定義されている用語と一致しています。RFC1242[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.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、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.
注：テスト中に、近隣発見の静的または動的オプションを使用できます。静的ケースでは、テストツールのIPv6隣接情報がDUTで手動で構成され、DUTのIPv6隣接情報はテストツールで手動で構成されています。動的な場合、IPv6隣接情報は、隣接するディスカバリープロトコルを介して各デバイスによって動的に発見されます。静的オプションは、テストツールによってサポートされている限り使用できます。テストツールがテストの期間中にDUTと相互作用して、アクティブな状態でそれぞれの隣接キャッシュを維持する動的オプションが推奨されます。近隣の勧誘（NS）および近隣の広告（NA）が近隣の到達不能検出（NUD）メカニズム[6]による暴風雨を回避するために、テストシナリオはテストシナリオがエンドポイントとIPv6ソースと宛先アドレスをDUTを超えた1つのホップをシミュレートすると仮定します。
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.
2種類のメディアが一般的に展開され、ネットワーク要素がそのタイプのメディア、イーサネットとソネット（同期光ネットワーク）をサポートする場合、それぞれをテストする必要があります。このセクションでは、各メディアタイプに使用する必要があるフレームサイズを識別します。他のすべてのメディアタイプについては、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]によると、フレームサイズは、IEEE 802.1AE MAC [14]セキュリティプロトコルに必要なフレームタグとその他のカプセル化に対応するために、最大2048バイトまで増加させることができます。運用環境で一般的に使用されるフレームサイズは1522バイトで、802.1D [15]に従って、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.
各フレームサイズとさまざまなPOSインターフェイスタイプの理論的最大フレームレートは、付録Aに記載されています。
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.
IPアドレスの選択に関する考慮事項を分析する必要があるIPv6ベンチマークテストには、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を参照）。このブロックのアドレスはグローバルにルーティング可能ではなく、インターネットソースまたは宛先アドレスとして使用してはなりません。
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に設定する必要があります。Link Local 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ソースおよび宛先アドレスは、セクション8で定義されているように、IANAによって割り当てられたIPv6範囲に属する必要があります。ソースアドレスは範囲の半分に属し、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:
個々の拡張ヘッダーを含むトラフィックを含むテストは、2つ以上の拡張ヘッダーのチェーンを含むテストで補完する必要があります（チェーンにはホップバイホップ拡張ヘッダーを含めてはなりません）。また、上層情報に基づいたフィルターなどのモディファイ因子を使用したテストでは、暗号化されたペイロードを含むトラフィックを使用することはできないため、このチェーンは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.
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 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.
拡張ヘッダーは、IPパケットのペイロードサイズに追加のバイトを追加します。これは、低フレームサイズでテストするときに使用する場合に因数分解する必要があります。それらの存在は、テストで使用される最小パケットサイズを変更します。拡張ヘッダーを備えたトラフィックとフレームサイズが低いトラフィックを持たないトラフィックで得られたデータを直接比較するには、両方のタイプのトラフィックの最小フレームサイズに対して共通の値を選択する必要があります。
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パフォーマンスのより詳細な特性評価のために、単方向トラフィックでテストを実行できます。これらの場合、双方向トラフィックテストは、2つの方向間の最低パフォーマンスのみを明らかにします。
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で定義されている条件は、IPv6がレイヤー2または3のブロードキャストフレームを使用していないことを除いて、IPv4およびIPv6に共通しています。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:
許可または拒否が、フィルターが適用されるインターフェイスを介してパケットを許可または拒否するアクションを示します。プロトコルフィールドは次のように定義されます。
o ipv6: any IP Version 6 traffic
o IPv6：IPバージョン6トラフィック
o tcp: Transmission Control Protocol
o TCP：伝送制御プロトコル
o udp: User Datagram Protocol
o UDP：ユーザーデータグラムプロトコル
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の推奨に基づいて、修飾子の存在下でのパフォーマンスを評価するときに2種類のテストが実行されます。1つは単一のフィルターを備え、もう1つは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
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.
シングルラインフィルターケースは、ネットワーク要素がすべてのTCP/UDP/IPv6トラフィックを許可していることを確認する必要があります。IPv6SA2001：DB8 :: 1からIPv6 DA 2001：db8 :: 2から他のすべてのトラフィックを拒否する拡張ヘッダーの数の有無にかかわらず。
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
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.
このドキュメントでは、DUTセットアップと上記のトラフィックセットアップの考慮事項を観察しながら、RFC 2544で説明されている同じベンチマークテストを推奨します。次のセクションでは、テストタイプを明示的に述べており、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の特異性、特に拡張ヘッダー処理の定義には、追加のベンチマーク手順が必要です。RFC 2544が推奨するテストは、拡張ヘッダーなしのIPv6トラフィックと、1つまたは複数の拡張ヘッダーを使用したIPv6トラフィックについて繰り返す必要があります。
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.
既存のIPv4環境でのIPv6の展開と2つのプロトコルの予想される長い共存により、ネットワークオペレーターは、両方のタイプのトラフィックを処理するプラットフォームのパフォーマンスを理解することに重点を置いています。デバイスリソースは2つのプロトコル間で共有されていますが、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のリストから1つの拡張機能ヘッダーを備えた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% vii) IPv4-IPv6 traffic mix with the ratio 50% vs 50%
vi）IPv4-IPV6トラフィックミックスと比率90％対10％
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-forwardingパフォーマンスの完全なベンチマークのために上記の条件の下で実行する必要がある特定のテストについて説明します。
Objective: To determine the DUT throughput as defined in RFC 1242.
目的：RFC 1242で定義されている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.
目的：RFC 1242で定義されているレイテンシを決定します。
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は、RFC 4773プールの48ビットプレフィックスであるIPv6ベンチマークに2001：0200 ::/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.
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は、この文書の貴重なガイダンスと推奨事項を提供しました。著者は、IPv6ベンチマークの用語を定義することに関して、シンシア・マーティンとジェフ・ダンが行った作業を認めています。著者は、最初の文書とトム・アレクサンダー、ビル・セルベニー、シルヴィハ・ドライ、スヴェン・ランクマンズ、ディーン・リー、アタナシオス・リアコプロス、ブノワ・ルルデレット、アル・モートン、デイビッド・ニューマン、ラジブ・パペイナ、ダン・ロマスカ、そして、ペッカ・サヴォラは非常に役立つフィードバックをしてくれました。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。and 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。and W. Simpson、「PPP Over Sonet/SDH」、RFC 2615、1999年6月。
[4] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[4] Hinden、R。and B. Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、2005年10月。
[5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[5] Kent、S。、「セキュリティペイロード（ESP）のカプセル化IP」、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 4861、2007年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] Simpson、W.、ed。、「HDLCのようなフレーミングのPPP」、STD 51、RFC 1662、1994年7月。
[9] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[9] Bradner、S。およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク方法論」、RFC 2544、1999年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 Computer SocietyのLAN/Man Standards委員会、「IEEE STD 802.3AS-2006、パート3：キャリアセンス衝突検出（CSMA/CD）アクセス方法と物理層の仕様、修正3：フレームフォーマット拡張機能」、11月2006年。
[14] Allyn Romanow (editor), "IEEE Std 802.3ae, Media Access Control (MAC) Security", June 2006.
[14] Allyn Romanow（編集者）、「IEEE STD 802.3AE、Media Access Control（MAC）Security」、2006年6月。
[15] Mick Seaman (editor), "IEEE Std 802.1D-2004, MAC Bridges", February 2004.
[15] Mick Seaman（編集者）、「IEEE STD 802.1D-2004、Mac Bridges」、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.
この付録は、計算する式と、イーサネットとソネットの2つのメディアタイプの理論的最大フレームレートの値を提供します。
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の1秒あたりのフレーム（FPS）のスループットは、次の式で計算できます。
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
サイズ10MB/s 100MB/s 1000MB/s 10000MB/sバイト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
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.
注：イーサネットの最大フレームレートは、クロックスロップによる分散の対象となります。リストされているレートは理論的な最大値であり、実際のテストはA /-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)
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
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
Ciprian Popoviciu Cisco Systems Kit Creek Road RTP、North Carolina 27709 USA
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
アーメドハムザシスコシステム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
Diego Dugatkin FastSoft, Inc. 150 S. Los Robles Ave. Pasadena, CA 91101 USA
Diego Dugatkin FastSoft、Inc。150 S. Los Robles Ave. Pasadena、CA 91101 USA
Phone: +1-626-357-7012
EMail: diego@fastsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。