RFC5180 日本語訳
5180 IPv6 Benchmarking Methodology for Network Interconnect Devices.C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin. May 2008. (Format: TXT=41712 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Popoviciuがコメントのために要求するワーキンググループC.をネットワークでつないでください: 5180年のA.ハムザカテゴリ: 情報のG.のバン・デ・ベルデシスコシステムズD.Dugatkin FastSoft株式会社2008年5月
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.
RFC2544で定義されたベンチマーキング方法論はIPバージョン独立者です。 しかしながら、RFC2544はIPv6のいくつかの特異性を扱いません。 このドキュメントは追加ベンチマーキングガイドラインを提供します。(RFC2544に関連して、ガイドラインはネットワーク内部連絡デバイスのIPv6性能の、より完全で現実的な評価につながります)。 このドキュメントの範囲の外にIPv6変遷メカニズムがあります。
Popoviciu, et al. Informational [Page 1] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [1ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
Table of Contents
目次
1. Introduction ....................................................2
2. Existing Definitions ............................................3
3. Tests and Results Evaluation ....................................3
4. Test Environment Setup ..........................................3
5. Test Traffic ....................................................4
5.1. Frame Formats and Sizes ....................................4
5.1.1. Frame Sizes to Be Used on Ethernet ..................5
5.1.2. Frame Sizes to Be Used on SONET .....................5
5.2. Protocol Addresses Selection ...............................6
5.2.1. DUT Protocol Addresses ..............................6
5.2.2. Test Traffic Protocol Addresses .....................7
5.3. Traffic with Extension Headers .............................7
5.4. Traffic Setup ..............................................9
6. Modifiers .......................................................9
6.1. Management and Routing Traffic .............................9
6.2. Filters ...................................................10
6.2.1. Filter Format ......................................10
6.2.2. Filter Types .......................................11
7. Benchmarking Tests .............................................12
7.1. Throughput ................................................13
7.2. Latency ...................................................13
7.3. Frame Loss ................................................13
7.4. Back-to-Back Frames .......................................13
7.5. System Recovery ...........................................14
7.6. Reset .....................................................14
8. IANA Considerations ............................................14
9. Security Considerations ........................................14
10. Conclusions ...................................................15
11. Acknowledgements ..............................................15
12. References ....................................................15
12.1. Normative References .....................................15
12.2. Informative References ...................................16
Appendix A. Theoretical Maximum Frame Rates Reference ............17
A.1. Ethernet .................................................17
A.2. Packet over SONET ........................................18
1. 序論…2 2. 既存の定義…3 3. テストと結果評価…3 4. 環境セットアップをテストしてください…3 5. トラフィックをテストしてください…4 5.1. 形式とサイズを縁どってください…4 5.1.1. サイズを縁どって、イーサネットで使用されてください…5 5.1.2. サイズを縁どって、Sonetで使用されてください…5 5.2. プロトコルは選択を扱います…6 5.2.1. DUTはアドレスについて議定書の中で述べます…6 5.2.2. テストトラフィックはアドレスについて議定書の中で述べます…7 5.3. 拡張ヘッダーがいるトラフィック…7 5.4. トラフィックはセットアップされます…9 6. 修飾語…9 6.1. 管理とルート設定トラフィック…9 6.2. フィルタ…10 6.2.1. 形式をフィルターにかけてください…10 6.2.2. タイプはフィルターにかけます…11 7. ベンチマーキングはテストされます…12 7.1. スループット…13 7.2. 潜在…13 7.3. 損失を縁どってください…13 7.4. 背中合わせのフレーム…13 7.5. システム回復…14 7.6. リセットします。14 8. IANA問題…14 9. セキュリティ問題…14 10. 結論…15 11. 承認…15 12. 参照…15 12.1. 標準の参照…15 12.2. 有益な参照…16の付録のA.の理論上の最大のフレームは参照を評定します…17 A.1。 イーサネット…17 A.2。 Sonetの上のパケット…18
1. Introduction
1. 序論
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).
RFC2544[9]によって定義されたベンチマーキング方法論は一貫してネットワーク要素のIPv4推進性能を評価する際に役に立つと判明しています。 これらのテストと結果分析手順への固守は様々な製品と様々な個人によって測定されたIPv4性能データの客観的な比較を容易にします。 RFC2544で紹介された方法論の後ろの原則は主にIPバージョン独立者ですが、プロトコルは、発展し続けていました、特にバージョン6(IPv6)で。
Popoviciu, et al. Informational [Page 2] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [2ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
This document provides benchmarking methodology recommendations that address IPv6-specific aspects, such as evaluating the forwarding performance of traffic containing extension headers, as defined in RFC 2460 [2]. These recommendations are defined within the RFC 2544 framework, and they complement the test and result analysis procedures as described in RFC 2544.
このドキュメントはIPv6特有の局面を扱うベンチマーキング方法論推薦を提供します、拡張ヘッダーを含むトラフィックの推進性能を評価するのなどように、RFC2460[2]で定義されるように。 これらの推薦は2544年のRFCフレームワークの中で定義されます、そして、それらはRFC2544で説明されるようにテストと結果分析手順の補足となります。
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]。 この用語SHOULD、このドキュメントの推薦を使用するか、または適用する前に、相談されてください。
Any methodology aspects not covered in this document SHOULD be assumed to be treated based on the RFC 2544 recommendations.
どんな方法論局面も本書ではSHOULDをカバーしませんでした。2544年のRFC推薦に基づいて扱われると思われてください。
2. Existing Definitions
2. 既存の定義
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。 RFC2119は、標準化過程ドキュメントの意図をできるだけ明確にするのを助けるためにこれらのキーワードの使用を定義します。 このドキュメントはこれらのキーワードを使用しますが、このドキュメントは標準化過程ドキュメントではありません。
3. Tests and Results Evaluation
3. テストと結果評価
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.
一般に、テスト実行と見ている間、分析を実行しなければならないという結果は、再現可能性に関する習慣、変化、および少ない数のトライアルの統計的な意味をテストしながら、受け入れました。
4. Test Environment Setup
4. 試験環境セットアップ
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業績評価のために推薦された試験環境セットアップオプションはものがRFC2544のセクション6で説明したのと同じです、ただ一つのポートとマルチポートシナリオの両方で。 単一のポートテストは1インタフェースあたりの推進性能を測定しますが、マルチポートテストは全体のプラットホームの向こう側に推進性能のスケーラビリティを測定します。
Popoviciu, et al. Informational [Page 3] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [3ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
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.
テストの間中、関連リソース(プロセッサ、メモリなど)利用のために、Device Under Test(DUT)をモニターできます。 このデータはIPv6のために割り当てなければならない各DUTとリソースにトラフィック処理を解釈するのにおいて有益であるかもしれません。 それは、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と対話するところでダイナミックなオプションは好まれます。 隣人「非-可到達性」検出(NUD)メカニズム[6]による隣人懇願(NS)と隣人広告(NA)嵐を避けるために、テストシナリオは、テストトラフィックがDUTでワンバウンドであることのエンドポイント、IPv6ソース、および送付先アドレスをシミュレートすると仮定します。
5. Test Traffic
5. テストトラフィック
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.
テストが説明したすべてに使用されるトラフィックはこのドキュメントSHOULDでこのセクションで説明された必要条件を満たします。 これらの要件は、IPv6ユニキャストトラフィックの特性を反映するように設計されています。 お勧めのIPv6トラフィックプロフィールを使用するのはネットワーク要素性能の完全な評価に通じます。
5.1. Frame Formats and Sizes
5.1. フレーム形式とサイズ
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つのタイプのメディアは、一般的に配布されて各SHOULDです。ネットワーク要素が、それがタイプのメディアであるとサポートするなら、テストされてください: イーサネットとSonet(同期式光通信網)。 このセクションはそれぞれのメディアタイプにおいて使用されていた状態でSHOULDがあるフレーム・サイズを特定します。 他のすべてのメディアタイプについてRFC2544の推薦を参照してください。
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の1フレーム処理あたりのオーバーヘッドを特徴付けるのを助けます。 最小のIPv6パケットサイズ(40バイト)がIPv4パケット(20バイト)のものより大きいことに注意してください。 テストはこの違いを補うべきです。
Popoviciu, et al. Informational [Page 4] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [4ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
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.
以下に注意してください。 テスト・ツールは、どんなパケット滴も故障しているパケットもないことを確かめるか、または遅れやジターなどの様々な統計について計算するのに一般的にテストトラフィックパケットを特定する署名を使用します。 これはテスト・ツールを通して選択可能な最小のフレーム・サイズが本書では提示された理論上のものほど低くないかもしれない理由であるかもしれません。
5.1.1. Frame Sizes to Be Used on Ethernet
5.1.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.
すべてのタイプでは、イーサネットは今日のネットワークで最も一般的にメディアに配布されるようになりました。 以下のフレームはSHOULDを大きさで分けます。ベンチマーキングには、このメディアタイプで、使用されてください: 64、128、256、512、1024、1280、および1518バイト。
Note: The recommended 1518-byte frame size represents the maximum size of an untagged Ethernet frame. According to the IEEE 802.3as standard [13], the frame size can be increased up to 2048 bytes to accommodate frame tags and other encapsulation required by the IEEE 802.1AE MAC [14] security protocol. A frame size commonly used in operational environments is 1522 bytes, the max length for a VLAN-tagged frame, as per 802.1D [15].
以下に注意してください。 お勧めの1518年のバイトのフレーム・サイズは非タグ付けをされたイーサネットフレームの最大サイズを表します。 IEEE 802.3as規格[13]によると、フレームタグを収容するためにフレーム・サイズを2048バイトまで増強できます、そして、他のカプセル化がIEEE 802.1AE MAC[14]セキュリティプロトコルが必要です。 運用環境に一般的に使用されるフレーム・サイズは1522バイトです、VLANによってタグ付けをされたフレームへの最大の長さ、802.1D[15]に従って。
Note: While jumbo frames are outside the scope of the 802.3 IEEE standard, tests SHOULD be executed with frame sizes selected based on the values supported by the device under test. Examples of commonly used jumbo frame sizes are: 4096, 8192, and 9216 bytes.
以下に注意してください。 範囲の外にジャンボなフレームがある間、標準の802.3IEEEテストSHOULDでは、フレーム・サイズがデバイスによってテストでサポートされた値に基づいた選択にされるので実行されてください。 一般的に使用されたジャンボなフレーム・サイズに関する例は以下の通りです。 4096、8192、および9216バイト。
The maximum frame rates for each frame size and the various Ethernet interface types are provided in Appendix A.
それぞれのフレーム・サイズの最大のフレームレートと様々なイーサネットインターフェース型をAppendix Aに提供します。
5.1.2. Frame Sizes to Be Used on SONET
5.1.2. サイズを縁どって、Sonetで使用されてください。
Packet over SONET (PoS) interfaces are commonly used for edge uplinks and high-bandwidth core links. Evaluating the forwarding performance of PoS interfaces supported by the DUT is recommended. The following frame sizes SHOULD be used for this media type: 47, 64, 128, 256, 512, 1024, 1280, 1518, 2048, 4096 bytes.
Sonet(PoS)インタフェースの上のパケットは縁のアップリンクと高帯域コアリンクに一般的に使用されます。 DUTによってサポートされたPoSインタフェースの推進性能を評価するのはお勧めです。 以下のフレームはSHOULDを大きさで分けます。このメディアタイプには、使用されてください: 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インターフェース型をAppendix Aに提供します。
Popoviciu, et al. Informational [Page 5] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [5ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
5.2. Protocol Addresses Selection
5.2. プロトコルは選択を扱います。
There are two aspects of IPv6 benchmarking testing where IP address selection considerations MUST be analyzed: the selection of IP addresses for the DUT and the selection of addresses for test traffic.
IPv6ベンチマーキングテストの2つの局面がIPアドレス選択問題を分析しなければならないところにあります: IPの選択はテストのためのアドレスのDUTと品揃えのためにトラフィックを扱います。
5.2.1. DUT Protocol Addresses
5.2.1. 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は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.
RFC2544のAppendix Cと同様です、この範囲SHOULDの前半からのアドレスは入力されるように見られたポートに使用されて、もう片方から出力ポートに半分の範囲を扱います。
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.
64〜126値以外の128の範囲が言及した選択されたコネが上であったなら、いいえは長さのSHOULDを前に置きます。
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のInterface ID部分はSHOULDを扱います。以下のことように設定されてください:1. 地方のIPv6が扱うリンクのInterface ID部分の選択には要件が全くありません。
Popoviciu, et al. Informational [Page 6] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [6ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
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経路指定テーブルに反映します、そして、それらは、基線性能測定基準を証明するために代表しているべきです。
5.2.2. Test Traffic Protocol Addresses
5.2.2. テストトラフィックプロトコルアドレス
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.
テストがSHOULDを流すので、IPv6ソースと送付先アドレスはIANAによって割り当てられたIPv6範囲に属します、セクション8で定義されるように。 ソースアドレスSHOULDは範囲の半分ともう片方への送付先アドレスに属します、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.
SHOULDをテストする、まず最初に、ただ一つのストリームが1ソース目的地アドレス組を利用していて、実行されてください。 繰り返されて、トラフィックが対応する範囲でa無作為の送付先アドレスを使用している状態で、その時、SHOULDをテストします。 ネットワーク要素接頭語であるなら、ルックアップ能力は評価されて、テストはIPv6の関連接頭語限界のSHOULD焦点です: 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.
以下に注意してください。 静的に定義された隣人が使用されていないとき、Neighbor Unreachability Detectionに影響するパラメタは一貫して設定されるべきです。 ルータ通知SHOULDにおけるIPv6の接頭語届いている時間、30秒に設定されてください。
5.3. Traffic with Extension Headers
5.3. 拡張ヘッダーがいるトラフィック
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ベースのトラフィックを断片化して、認証して、暗号化しました。 これらの理由、このドキュメントSHOULDで説明されたすべてのテストには、拡張ヘッダーが全くいないトラフィックと1セットの拡張ヘッダーがいるトラフィックの両方で、実行されてください。 ヘッダーがあることができるのをタイプする拡大はパケットでの複数の拡張ヘッダーのお勧めの注文を反映する以下のリスト[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 Destinationオプションヘッダーoルート設定ヘッダーo Fragmentヘッダーo Authenticationヘッダーo Encapsulatingセキュリティペイロード(超能力)ヘッダーo Destinationオプションヘッダーo Mobilityヘッダー
Popoviciu, et al. Informational [Page 7] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [7ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
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.
プロトコルの本質的な部分と彼らは拡張ヘッダーがそうので、異なる役割を実現させます、ベンチマーキング。トラフィックがそれぞれの拡張ヘッダーSHOULDを含むのにおいて、個別に実行されてください。
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人以上の拡張ヘッダーのチェーンを含むテストを補わなければなりません(チェーンはホップごとの拡張ヘッダーを含んではいけません)。 また、このチェーンは超能力[5]拡張ヘッダーを除くべきです、上側の層の情報に基づくフィルタなどの修飾語でテストで暗号化されたペイロードがあるトラフィックを使用できないので(セクション5を見てください)。 DUTが拡張ヘッダーの内容を分析していないので、テストで拡張ヘッダーのどんな組み合わせも使用できます。 テストするために推薦された拡張ヘッダーチェーンは以下の通りです。
o Routing header - 24-32 bytes
o Destination options header - 8 bytes
o Fragment header - 8 bytes
o ルート設定ヘッダー--24-32バイトoのDestinationオプションヘッダー--8バイトのo Fragmentヘッダー--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パケットで見つけられる現実の拡張ヘッダーチェーンです。 記載された拡張ヘッダーの長さはテスト・ツールデフォルトを表します。 拡張ヘッダーの全長はSHOULDをチェーニングします。32バイトより大きくいてください。
Extension headers add extra bytes to the payload size of the IP packets, which MUST be factored in when used in testing at low frame sizes. Their presence will modify the minimum packet size used in
拡張ヘッダーはIPパケットのペイロードサイズに付加的なバイトを加えて、低フレーム・サイズでテストする際に使用されると、どれがあるに違いないかは計算に入れました。 それらの存在は中で使用された最小のパケットサイズを変更するでしょう。
Popoviciu, et al. Informational [Page 8] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [8ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
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.
テスト。 それには、トラフィックで得られたデータの間の直接比較には、拡張ヘッダーがいます、そして、彼らが低フレーム・サイズ、一般的な値のSHOULDにいないトラフィックで、両方のタイプのトラフィックの最もわずかなフレーム・サイズのために選ばれてください。
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 MUSTは拡張ヘッダーのチェーン、性能に影響を与えることができたプロセスを横断します。
5.4. Traffic Setup
5.4. トラフィックセットアップ
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.
すべてのテストが、このドキュメントSHOULDで双方向のトラフィックで実行されるように勧めました。 非対称の状況において、テストはDUT性能の、より粒状の特殊化のためにuni方向のトラフィックで実行されるかもしれません。 これらの場合では、双方向のトラフィックテストは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.
他のすべてのトラフィックがまた、このテストで適用されていて、RFC2544SHOULDで説明された特性の輪郭を描きます。 このドキュメントの範囲の外にIPv6マルチキャストベンチマーキングがあります。
6. Modifiers
6. 修飾語
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.
RFC2544はある稼動状況の下でネットワーク要素の性能を評価することの重要を強調します。 RFC2544のセクション11で定義された状態はIPv4とIPv6に共通です、IPv6が層2か3の放送フレームを使わないのを除いて。 IPv6は層2か層3の放送を使用しません。 このセクションはIPv6に特定の追加条件を提供します。 テストのスイートは、このドキュメントSHOULDで最初にこれらの状態がないとき実行されるように勧めて、次に、別々にそれぞれに関するこれらの条件のもとで繰り返されました。
6.1. Management and Routing Traffic
6.1. 管理とルート設定トラフィック
The procedures defined in Sections 11.2 and 11.3 of RFC 2544 are applicable for IPv6 management and routing update frames as well.
また、IPv6管理とルーティングアップデートフレームに、RFC2544のセクション11.2と11.3で定義された手順は適切です。
Popoviciu, et al. Informational [Page 9] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [9ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
6.2. Filters
6.2. フィルタ
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.
RFC2544のセクション11.4で定義されたフィルタはまた、IPv6ベンチマーキングに適用されます。 拡張ヘッダーがいるIPv6の重要な建築部品であるトラフィックの取り扱いを分析するために合っている上側の層のプロトコル情報を含むようにフィルター定義を広げなければなりません。
6.2.1. Filter Format
6.2.1. フィルタ形式
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.
RFC2544で定義されたフィルタ書式はまた、IPv6に適切です、ソースアドレス(SA)と送付先アドレス(DA)がIPv6アドレスであるのを除いて。 これらの基本的なフィルタに加えて、IPv6性能SHOULDの評価は拡張ヘッダーによるトラフィックの正しいフィルタリングと取り扱いを分析します。
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トラフィックのネットワーク要素取り扱いを評価するなら、上側の層のプロトコル情報に適用された状態を含むようにフィルタの定義を広げなければなりません。 以下は形式SHOULDをフィルターにかけます。このタイプの評価には、使用されてください:
[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を表します。
Popoviciu, et al. Informational [Page 10] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [10ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
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)に適用されます。
6.2.2. Filter Types
6.2.2. フィルタタイプ
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::.
修飾語があるとき性能を評価するとき、RFC2544推薦に基づいて、2つのタイプのテストは実行されます: 単一のフィルタがある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
TCPには、トラフィックをフィルターにかけてください--tcp2001: DB8を可能にしてください:、:1 2001 : DB8:、:2 UDPには、トラフィックをフィルターにかけてください--udp2001: 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.
単線フィルタ・ケースSHOULDは、すべてのTCP/UDP/IPv6がいずれものあるなしにかかわらず取引するネットワーク要素許可証がIPv6 SA2001: DB8からの拡張ヘッダーに以下に付番することを確かめます:IPv6 DA2001: DB8への1:、:そして、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
tcp2001:DB8:1を否定してください:、:1 2001: DB8: 1:、:2 tcp2001:DB8:2を否定してください:、:1 2001: DB8: 2:、:2 tcp2001:DB8:3を否定してください:、:1 2001: DB8: 3:、:2 … tcp2001:DB8:Cを否定してください:、:1 2001:DB8:C:、:2 tcp2001:DB8:99を可能にしてください:、:1 2001: DB8: 99:、:2 tcp2001:DB8:Dを否定してください:、:1 2001: DB8: D:、:2 tcp2001:DB8:Eを否定してください:、:1 2001:DB8:E:、:2 tcp2001: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.
ルータSHOULDは、すべてがSA2001:DB8:99があるTCPトラフィック以外の拡張ヘッダーのあるなしにかかわらず以下を取引することを否定します:1とDA2001:DB8:99:、:2.
Popoviciu, et al. Informational [Page 11] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [11ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
7. Benchmarking Tests
7. ベンチマーキングテスト
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セットアップと問題が上で説明したトラフィックセットアップを観測している間にRFC2544で説明された同じベンチマーキングテストを推薦します。 以下のセクションは明らかに視力検査表を述べます、そして、彼らはRFC2544のセクション26で説明されたものに関して存在するかもしれない方法論差だけを目立たせます。
The specificities of IPv6, particularly the definition of extension header processing, require additional benchmarking steps. The tests recommended by RFC 2544 MUST be repeated for IPv6 traffic without extension headers and for IPv6 traffic with one or multiple extension headers.
IPv6の特異性(特に拡張ヘッダー処理の定義)は追加ベンチマーキングステップを必要とします。 拡張ヘッダーのいないIPv6トラフィックと1があるIPv6トラフィックか複数の拡張ヘッダーのためにRFC2544によって推薦されたテストを繰り返さなければなりません。
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.
2つのプロトコルの既存のIPv4環境と予想された長い共存におけるIPv6の展開は、ネットワーク・オペレータがプラットホームの性能が両方のタイプのトラフィックを処理するのを理解していることへのかなりの強調を置くように導きます。 デバイスリソースは2つのプロトコルの間で共有されますが、IPv6によって可能にされたプラットホームが降格しているIPv4性能を経験しないのは、重要です。 その結果、IPv6ベンチマーキングSHOULD、スタンドアロンのプロトコルの文脈と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:
ベンチマーキングテストはそれぞれ以下の実行された下が状態であったならこのセクションでSHOULDについて説明しました:
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%
vi) IPv4-IPv6トラフィックは10%に対して90%の比率を混ぜます。
Popoviciu, et al. Informational [Page 12] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [12ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
vii) IPv4-IPv6 traffic mix with the ratio 50% vs 50%
vii) IPv4-IPv6トラフィックは50%に対して50%の比率を混ぜます。
viii) IPv4-IPv6 traffic mix with the ratio 10% vs 90%
viii) IPv4-IPv6トラフィックは90%に対して10%の比率を混ぜます。
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のためにリストアップされた試験条件を結合するのは大きい適用範囲マトリクスに通じます。 必要最小限では、共存テストはトラフィックが混ぜる拡張ヘッダーと10%から90%も、90%から10%も、またはIPv4/IPv6なしで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-推進性能の完全なベンチマーキングのために上にリストアップされた条件のもとで実行しなければならない特異的な試験について説明します。
7.1. Throughput
7.1. スループット
Objective: To determine the DUT throughput as defined in RFC 1242.
目的: RFC1242で定義されるようにDUTスループットを測定するために。
Procedure: Same as RFC 2544.
手順: RFC2544と同じです。
Reporting Format: Same as RFC 2544.
報告形式: RFC2544と同じです。
7.2. Latency
7.2. 潜在
Objective: To determine the latency as defined in RFC 1242.
目的: RFC1242で定義されるように潜在を決定するために。
Procedure: Same as RFC 2544.
手順: RFC2544と同じです。
Reporting Format: Same as RFC 2544.
報告形式: RFC2544と同じです。
7.3. Frame Loss
7.3. フレームの損失
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のフレーム損失率(RFC1242で定義されるように)を測定するために。
Procedure: Same as RFC 2544.
手順: RFC2544と同じです。
Reporting Format: Same as RFC 2544.
報告形式: RFC2544と同じです。
7.4. Back-to-Back Frames
7.4. 背中合わせのフレーム
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ベンチマーキングのためにもう推薦されません。
Popoviciu, et al. Informational [Page 13] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [13ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
7.5. System Recovery
7.5. システムの復旧
Objective: To characterize the speed at which a DUT recovers from an overload condition.
目的: DUTが過負荷条件から回復する速度を特徴付けるために。
Procedure: Same as RFC 2544.
手順: RFC2544と同じです。
Reporting Format: Same as RFC 2544.
報告形式: RFC2544と同じです。
7.6. Reset
7.6. リセット
Objective: To characterize the speed at which a DUT recovers from a device or software reset.
目的: DUTがデバイスかソフトウェアリセットから回復する速度を特徴付けるために。
Procedure: Same as RFC 2544.
手順: RFC2544と同じです。
Reporting Format: Same as RFC 2544.
報告形式: RFC2544と同じです。
8. IANA Considerations
8. IANA問題
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は2001を割り当てました:、0200:、:IPv6ベンチマーキングのための/48(48ビットです)はRFCから4773年のプールを前に置きます。 この配分は198.18と同様です。.0 RFC3330[10]で定義された.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.
以下に注意してください。 1918年のRFCアドレス空間のベンチマーキングテストの使用を避けるRFC2544と同様です、このドキュメントは操作上のトラフィックとの闘争の可能性を最小にするためにRFC4193[4](ユニークなLocal Addresses)の使用を推薦しません。
9. Security Considerations
9. セキュリティ問題
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トラフィックにテストトラフィックを送るかもしれないデバイスに接続されてはいけません。
Popoviciu, et al. Informational [Page 14] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [14ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the DUT/SUT (System Under Test).
DUT/SUT(システムUnder Test)に外部であることの形で唯一観察可能な測定に依存して、さらに、ベンチマーキングは「ブラックボックス」ベースに実行されます。
Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks.
特別な能力SHOULD NOTは特にベンチマーキング目的のためのDUT/SUTに存在しています。 同じコネが研究室であったならDUT/SUT SHOULDから起こるネットワークセキュリティと生産ネットワークにおけるどんな含意。
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で可能にされないという事実の孤立している本質はベンチマーキングプロセスに特定のどんなセキュリティ問題も必要としません。
10. Conclusions
10. 結論
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.
Network Interconnect DevicesドキュメントのためのBenchmarking Methodology(RFC2544[9])はネットワーク要素のIPv6性能を評価するのにだいたい適切です。 このドキュメントはRFC2544の推薦を適用するとき観測しなければならないIPv6-決められた一定の要求を扱います。 これらの追加要件はIPv6のアーキテクチャの特性によります。 このドキュメントが交換品でない、しかし、補数、RFC2544
11. Acknowledgements
11. 承認
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ベンチマーキングのために用語を定義することに関してシンシア・マーチンとジェフ・ダンによって行われた仕事を承諾します。 作者は彼らの非常に役立っているフィードバックのために初期のドキュメントと、そして、トム・アレクサンダーと、ビル・チェルベニと、シルビヤDryと、スベンLanckmansと、ディーン・リーと、Athanassios Liakopoulosと、ブノワLourdelet、アル・モートンと、デヴィッド・ニューマンと、ラジブPapejnaと、ダンRomascanuと、ペッカSavolaへの彼の貢献についてビルKineに感謝したがっています。 マリアム・ハムザは、このドキュメントを完成するために作者を奮い立たせました。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[2] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
Popoviciu, et al. Informational [Page 15] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [15ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
[3] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June
1999.
[3]MalisとA.とW.シンプソン、「Sonet/SDHの上のppp」、RFC2615、1999年6月。
[4] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[4]HindenとR.とB.ハーバーマン、「ユニークなローカルのIPv6ユニキャストアドレス」、RFC4193、2005年10月。
[5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
[5] ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、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.ソリマン、「IPバージョン6のための隣人ディスカバリー(IPv6)」、RFC4861(2007年9月)。
12.2. Informative References
12.2. 有益な参照
[7] Bradner, S., "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, July 1991.
[7] ブラドナー、S.、「ネットワーク相互接続デバイスのためのベンチマーキング用語」、RFC1242、1991年7月。
[8] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662,
July 1994.
[8] エドシンプソン、W.、STD51、RFC1662、「HDLCのようのpppは縁どっている」7月1994日
[9] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999.
[9] ブラドナーとS.とJ.McQuaid、「ネットワーク内部連絡デバイスのためのベンチマーキング方法論」、RFC2544、1999年3月。
[10] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[10]IANA、「特別な使用IPv4アドレス」、RFC3330、2002年9月。
[11] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004.
2004年7月の[11] ヒューストンとG.と主、A.とP.スミス、「ドキュメンテーションのために予約されたIPv6アドレス接頭語」RFC3849。
[12] Newman, D. and T. Player, "Hash and Stuffing: Overlooked
Factors in Network Device Benchmarking", RFC 4814, March 2007.
[12] ニューマン、D.、T.プレーヤー、「ハッシュ、以下を詰めること」。 「ネットワークデバイスベンチマーキングの見落とされた要素」、RFC4814、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]LAN/男性規格委員会、IEEEコンピュータ社会では、「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(エディタ)、2006年6月の「IEEE Std 802.3ae、メディアアクセス制御(MAC)セキュリティ」
[15] Mick Seaman (editor), "IEEE Std 802.1D-2004, MAC Bridges",
February 2004.
[15] ミック船員(エディタ)、「IEEE Std 802.1D-2004、MACはブリッジする」2004年2月。
Popoviciu, et al. Informational [Page 16] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [16ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
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.
この付録は2つのメディアタイプの理論上の最大のフレームレートに計算する定石と値を提供します: イーサネットとSonet。
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のための2番目の(fps)あたりのフレームのスループットについて計算できます:
Line Rate (bps)
------------------------------
(8bits/byte)*(X+20)bytes/frame
ライン料率(ビーピーエス)------------------------------ (8ビット/バイト)*(X+20)バイト/フレーム
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/s1000 100Mb/s Mb/s10000Mb/s Bytes pps pps pps pps
64 14,880 148,809 1,488,095 14,880,952
128 8,445 84,459 844,594 8,445,945
256 4,528 45,289 452,898 4,528,985
512 2,349 23,496 234,962 2,349,624
1024 1,197 11,973 119,731 1,197,318
1280 961 9,615 96,153 961,538
1518 812 8,127 81,274 812,743
1522 810 8,106 81,063 810,635
2048 604 6,044 60,444 604,448
4096 303 3,036 30,396 303,691
8192 152 1,522 15,221 152,216
9216 135 1,353 13,534 135,339
64 14,880 148,809 1,488,095 14,880,952 128 8,445 84,459 844,594 8,445,945 256 4,528 45,289 452,898 4,528,985 512 2,349 23,496 234,962 2,349,624 1024 1,197 11,973 119,731 1,197,318 1280 961 9,615 96,153 961,538 1518 812 8,127 81,274 812,743 1522 810 8,106 81,063 810,635 2048 604 6,044 60,444 604,448 4096 303 3,036 30,396 303,691 8192 152 1,522 15,221 152,216 9216 135 1,353 13,534 135,339
Note: Ethernet's maximum frame rates are subject to variances due to clock slop. The listed rates are theoretical maximums, and actual tests should account for a +/- 100 ppm tolerance.
以下に注意してください。 イーサネットの最大のフレームレートは時間を計るのにおいて当然の変化への対象がこぼれるということです。 記載されたレートは理論上の最大です、そして、実際のテストは+/- 100ppmの寛容を説明するべきです。
Popoviciu, et al. Informational [Page 17] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [17ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
A.2. Packet over SONET
A.2。 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)のインターフェース型でのさまざまなPacketのために最大の利用可能な帯域幅について計算するのに公式を提供します:
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バイトのFrame Check Sequence(FCS)分野、そして、すべてである1バイトのFlagは総合的でフレーム・サイズを説明しました。 公式(Xがバイトで表現されるフレーム・サイズを表すところ)で様々なインターフェース型の最大のフレームレートについて計算できます:
Line Rate (bps)
------------------------------
(8bits/byte)*(X+1)bytes/frame
ライン料率(ビーピーエス)------------------------------ (8ビット/バイト)*(X+1)バイト/フレーム
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 Bytes fps fps fps fps fps
47 390,000 1,560,000 6,240,000 24,960,000 99,840,000
64 288,000 1,152,000 4,608,000 18,432,000 73,728,000
128 145,116 580,465 2,321,860 9,287,441 37,149,767
256 72,840 291,361 1,165,447 4,661,789 18,647,159
512 36,491 145,964 583,859 2,335,438 9,341,754
1024 18,263 73,053 292,214 1,168,858 4,675,434
2048 9,136 36,544 146,178 584,714 2,338,857
4096 4,569 18,276 73,107 292,428 1,169,714
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.
試験の成績が様々なメディアによって実行されたビット・スタッフィングのためAppendices A.1とA.2に提示された値から変えるかもしれないスループットが[12]をタイプすることに注意するのは重要です。 理論上のスループット番号は概数に切り下げられました。
Popoviciu, et al. Informational [Page 18] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [18ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
Authors' Addresses
作者のアドレス
Ciprian Popoviciu Cisco Systems Kit Creek Road RTP, North Carolina 27709 USA
Ciprian Popoviciuシスコシステムズキットクリーク道路RTP、ノースカロライナ27709米国
Phone: 919 787 8162 EMail: cpopovic@cisco.com
以下に電話をしてください。 8162年の919 787メール: cpopovic@cisco.com
Ahmed Hamza Cisco Systems 3000 Innovation Drive Kanata K2K 3E8 Canada
アフマドハムザシスコシステムズ3000革新ドライブKanata K2K3の8Eのカナダ
Phone: 613 254 3656 EMail: ahamza@cisco.com
以下に電話をしてください。 3656年の613 254メール: ahamza@cisco.com
Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium
Gunterバン・デ・ベルデシスコシステムズDe Kleetlaan 6a Diegem1831ベルギー
Phone: +32 2704 5473 EMail: gunter@cisco.com
以下に電話をしてください。 +32 2704 5473はメールされます: gunter@cisco.com
Diego Dugatkin FastSoft, Inc. 150 S. Los Robles Ave. Pasadena, CA 91101 USA
150秒間ディエゴDugatkin FastSoft Inc.ロスロブレスAve。 パサディナ、カリフォルニア91101米国
Phone: +1-626-357-7012 EMail: diego@fastsoft.com
以下に電話をしてください。 +1-626-357-7012 メールしてください: diego@fastsoft.com
Popoviciu, et al. Informational [Page 19] RFC 5180 IPv6 Benchmarking Methodology May 2008
Popoviciu、他 [19ページ]情報のRFC5180IPv6ベンチマーキング方法論2008年5月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Popoviciu, et al. Informational [Page 20]
Popoviciu、他 情報[20ページ]
一覧
スポンサーリンク
