Network Working Group C. Popoviciu
Request for Comments: 5180 A. Hamza
Category: Informational G. Van de Velde
Cisco Systems
D. Dugatkin
FastSoft Inc.
May 2008
IPv6 Benchmarking Methodology for Network Interconnect Devices
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
The benchmarking methodologies defined in RFC 2544 are IP version independent. However, RFC 2544 does not address some of the specificities of IPv6. This document provides additional benchmarking guidelines, which in conjunction with RFC 2544, lead to a more complete and realistic evaluation of the IPv6 performance of network interconnect devices. IPv6 transition mechanisms are outside the scope of this document.
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 [9] 2544によって定義されたベンチマークの方法論は、一貫してネットワーク要素の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で定義されるように、そのようなトラフィックを含む拡張ヘッダの転送性能を評価するようなIPv6固有の側面に対応ベンチマーク手法の推奨を提供する[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の勧告に基づいて扱われることを前提とすべきである（SHOULD）。
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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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]、テストシナリオは、試験トラフィックがDUTを超えて1つのホップであるエンドポイントと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.
注：テストツールは、一般的に何パケットが低下しないか、またはアウトオブオーダーパケット、またはそのような遅延およびジッタのような種々の統計を計算するために存在することを確認するテストトラフィックのパケットを識別するために署名を使用。これはテストツールで選択可能最小フレームサイズは、この文書の理論上の1の低さではないかもしれない理由である可能性があります。
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バイトまで増加させることができます。一般的動作環境で使用されるフレーム・サイズは、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.
各フレームのサイズと様々な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ベンチマークテストの2つの側面があります。IPの選択は、DUTとテストトラフィックのためのアドレスの選択に対応しています。
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（セクション8を参照）のIPv6ベンチマークテストで使用するためのIPv6アドレスブロックを予約しました。このブロックのアドレスは、グローバルにルーティング可能ではないと仮定することができる、と彼らはインターネットの送信元または宛先アドレスとして使用してはいけません。
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.
セクション8で定義されるように、IANAによって割り当てられたIPv6の範囲に属している必要があり、テストストリームのIPv6送信元アドレスと宛先アドレスは、送信元アドレスは、DUTインタフェースIPv6アドレスを反映して、1つの範囲の半分と他の宛先アドレスに属している必要があります選択。
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セキュリティペイロード（ESP）モビリティヘッダOヘッダO宛先オプションヘッダをカプセル化するoを認証ヘッダ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:
各個々の拡張ヘッダを含むトラフィックを用いた試験は、二つ以上の拡張ヘッダー（鎖はホップバイホップ拡張ヘッダが含まれていなければならない）の鎖を含有する試験で補完されなければなりません。暗号化されたペイロードを有するトラフィックは、上位レイヤ情報（セクション5を参照）に基づいて、フィルタとして改質剤を用いた試験で使用することができないので、この鎖はまた、ESP [5]拡張ヘッダを除外すべきです。 DUTは、拡張ヘッダの内容を解析していないので、拡張ヘッダの任意の組み合わせは、試験に使用することができます。試験のために推奨される拡張ヘッダ鎖です。
o Routing header - 24-32 bytes o Destination options header - 8 bytes o Fragment header - 8 bytes
Oルーティングヘッダ - 24-32バイトO宛先オプションヘッダは、 - フラグメントヘッダO 8つのバイト - 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.
これは、2つのモバイルノード間の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 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のパフォーマンスをより細かく特徴付けのための片方向トラフィックで実行することができます。これらのケースでは、双方向のトラフィックテストは二つの方向の間の唯一の最低のパフォーマンスを明らかにする。
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.
送信元アドレス（SA）と宛先アドレス（DA）は、IPv6のアドレスであることを除き、RFC 2544で定義されたフィルタの形式は、同様に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::.
25のフィルタを有する単一のフィルタと互いに1：改質剤の存在下での性能を評価する場合、RFC 2544件の勧告に基づいて、試験の二つのタイプが実行されます。 DB8 ::：推奨されるフィルタの例としては、IPv6文書接頭辞[11] 2001を使用して示されています。
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
TCPトラフィックのフィルタ - 許可TCP 2001：DB8 :: 1 2001：DB8 :: UDPトラフィック用の2フィルタ - 許可UDP 2001：DB8 :: 1 2001：用DB8 :: 2フィルタのIPv6トラフィック - 許可の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から拡張ヘッダの任意の数の有無にかかわらず、すべてのTCP / UDP / IPv6トラフィックを許可することを確認する必要があり、単一の行：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
TCP 2001を拒否：DB8：1 :: 1 2001：DB8：1 :: 2がTCP 2001を拒否：DB8：2 :: 1 2001：DB8：DB8：3 :: 1 2001：2 :: 2は、TCP 2001を否定DB8を： 3 :: 2 ...拒否TCP 2001：DB8：C :: 1 2001：DB8：C :: 2許可TCP 2001：DB8：99 :: 1 2001：DB8：DB8：99 :: 2は、TCP 2001拒否D :: 1 2001：DB8：TCP 2001を否定... E :: 2：DB8：：E :: 1 2001：DB8 :: D 2は、TCP 2001を否定DB8：19 :: 1 2001：DB8：19 :: 2任意の任意のIPv6を否定
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.
DB8：：99 :: 1とDA 2001：DB8：99 :: 2ルータは、SA 2001との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トラフィック用の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
5.3節のリストから1つの拡張ヘッダを持つII）IPv6トラフィック
iii) IPv6 traffic with the chain of extension headers described in Section 5.3
セクション5.3で説明拡張ヘッダーの鎖を有するIII）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%
比90％対10％VIIとVI）のIPv4-IPv6トラフィックミックス）50％対比50％のIPv4-IPv6トラフィックミックス
viii) IPv4-IPv6 traffic mix with the ratio 10% vs 90%
90％対比10％VIII）のIPv4-IPv6トラフィックミックス
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をベンチマーキングするために記載されている試験条件と共存テストを組み合わせることにより、大カバレッジ行列につながります。 90％、90％-10％、またはIPv4 / IPv6トラフィックミックス - 最小要件で、共存試験はない拡張ヘッダと10％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.
目的：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.
RFC 4773プールからの48ビットのプレフィックスであるIPv6のベンチマークのために0200 :: / 48：IANAは2001を割り当てています。この割り当ては、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 1918アドレス空間の使用を避けるRFC 2544と同様に、この文書では、[4]（ユニークローカルアドレス）運用トラフィックとの競合の可能性を最小限にするために、RFC 4193の使用を推奨していません。
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.
ベンチマークネットワークトポロジは、独立したテストのセットアップになり、テスト管理ネットワークへの生産ネットワークやmisrouteトラフィックにテストトラフィックを転送することができるデバイスに接続しないでください。
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の性能を評価に適用できるほとんどの部分です。この文書では、これらの追加要件は、IPv6のアーキテクチャ特性に由来RFC 2544の推奨を適用するときに観察されなければならないIPv6固有の要件に対応しています。この文書は、の代替が、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.
スコット・ブラッドナーは、この文書のための貴重な指導と勧告を提供しました。著者は、IPv6ベンチマーキングのための用語を定義に関してシンシアマーティンとジェフ・ダンによって行われた仕事を認めています。作者は最初の文書に、トム・アレクサンダー、ビルCerveny、Silvijaドライ、スヴェンLanckmans、ディーン・リー、Athanassios Liakopoulos、ブノワLourdelet、アル・モートン、デヴィッド・ニューマン、ラジブPapejna、ダンRomascanuへの彼の貢献のための法案雌牛に感謝したいと思い、そして彼らの非常に有用なフィードバックのためのペッカSavola。マリアムハムザは、この文書を完了するために、著者に影響を与えました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[2]デアリング、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.シンプソン、 "PPP SONET上/ SDH"、RFC 2615、1999年6月。
[4] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[4] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。
[5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[5]ケント、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.、シンプソン、W.、およびH.ソリマン、RFC 4861 "IPバージョン6（IPv6）のための近隣探索" 2007年9月。
[7] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.
[7]ブラドナーの、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 1662、1994年7月。
[9] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[9]ブラドナー、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]ヒューストン、G.、主よ、A.、およびP.スミス、 "ドキュメンテーションのための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]ニューマン、D.と、T.プレーヤー "ハッシュと詰め物：ネットワークデバイスで見落とさ要因はベンチマーキング"、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コンピュータ社会のLAN / MAN標準委員会、「IEEE STDの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]アリンRomanow（編集者）、 "IEEE規格802.3aeの、メディアアクセス制御（MAC）セキュリティ"、2006年6月。
[15] Mick Seaman (editor), "IEEE Std 802.1D-2004, MAC Bridges", February 2004.
[15]ミック・シーマン（編集者）、 "IEEE 802.1D STD-2004、MACブリッジ"、2004年2月。
Appendix A. Theoretical Maximum Frame Rates Reference
付録A.理論上の最大フレームレートリファレンス
This appendix provides the formulas to calculate and the values for the theoretical maximum frame rates for two media types: Ethernet and SONET.
イーサネットおよびSONET：この付録では、計算するための式と2つのメディアタイプのための理論上の最大フレームレートの値を提供します。
A.1. Ethernet
A.1。イーサネット
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
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
PPS PPSの100Mb / sの1000MB / sの10000Mb / sのバイトPPS PPSサイズの10Mb / sの
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.
注意：イーサネットの最大フレームレートは、クロックスロップによる分散の対象となっています。記載されている料金は、理論上の最大値であり、実際のテストは+/- 100ppmの許容差を考慮する必要があります。
A.2. Packet over SONET
A.2。たPacket over SONET
ANSI T1.105 SONET provides the formula for calculating the maximum available bandwidth for the various Packet over SONET (PoS) interface types:
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行）*（8ビット/バイト）*（8000フレーム/秒）
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 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.
試験結果が起因し、様々なメディアタイプ[12]によって実行されるビットスタッフィングに付録のA.1およびA.2に示された値から変化してもよいことスループットを留意することが重要です。理論上のスループット番号は切り捨てました。
Authors' Addresses
著者のアドレス
Ciprian Popoviciu Cisco Systems Kit Creek Road RTP, North Carolina 27709 USA
シプリアンPopoviciuシスコシステムズキットクリーク道路RTP、ノースカロライナ州27709 USA
Phone: 919 787 8162 EMail: cpopovic@cisco.com
電話：919 787 8162 Eメール：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 Eメール：ahamza@cisco.com
Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium
ギュンター・ヴァン・デ・ヴェルデシスコシステムズKleetlaan図6aディーゲム1831ベルギー
Phone: +32 2704 5473 EMail: gunter@cisco.com
電話：+32 2704 5473 Eメール：gunter@cisco.com
Diego Dugatkin FastSoft, Inc. 150 S. Los Robles Ave. Pasadena, CA 91101 USA
Dugatkin FastSoftサンディエゴ、Inc.の150 S.ロスロブレスアベニューパサデナ、CA 91101 USA
Phone: +1-626-357-7012 EMail: diego@fastsoft.com
電話：+ 1-626-357-7012 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。