[要約] RFC 8161は、Neighbor Discovery Protocol（NDP）のベンチマークテストに関する情報を提供するものであり、NDPのパフォーマンス評価と改善を目的としています。
Internet Engineering Task Force (IETF) W. Cerveny
Request for Comments: 8161 Arbor Networks
Category: Informational R. Bonica
ISSN: 2070-1721 R. Thomas
Juniper Networks
May 2017
Benchmarking the Neighbor Discovery Protocol
近隣探索プロトコルのベンチマーク
Abstract
概要
This document provides benchmarking procedures for the Neighbor Discovery Protocol (NDP). It also proposes metrics by which an NDP implementation's scaling capabilities can be measured.
このドキュメントでは、近隣探索プロトコル（NDP）のベンチマーク手順について説明します。また、NDP実装のスケーリング機能を測定できるメトリックを提案します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8161.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8161で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................4
2. Test Setup ......................................................4
2.1. Device Under Test (DUT) ....................................4
2.1.1. Interfaces ..........................................4
2.1.2. Neighbor Discovery Protocol (NDP) ...................5
2.1.3. Routing .............................................5
2.2. Tester .....................................................6
2.2.1. Interfaces ..........................................6
2.2.2. Neighbor Discovery Protocol (NDP) ...................6
2.2.3. Routing .............................................6
2.2.4. Test Traffic ........................................7
2.2.5. Counters ............................................8
3. Tests ...........................................................8
3.1. Baseline Test ..............................................8
3.1.1. Procedure ...........................................9
3.1.2. Baseline Test Procedure Flow Chart ..................9
3.1.3. Results ............................................11
3.2. Scaling Test ..............................................11
3.2.1. Procedure ..........................................11
3.2.2. Scaling Test Procedure Flow Chart ..................13
3.2.3. Results ............................................15
4. Measurements Explicitly Excluded ...............................15
4.1. DUT CPU Utilization .......................................15
4.2. Malformed Packets .........................................15
5. IANA Considerations ............................................16
6. Security Considerations ........................................16
7. Normative References ...........................................16
Acknowledgments ...................................................16
Authors' Addresses ................................................17
When an IPv6 node forwards a packet, it executes the following procedure:
IPv6ノードがパケットを転送するとき、次の手順を実行します。
o Identifies the outbound interface and IPv6 next hop.
o 発信インターフェイスとIPv6ネクストホップを識別します。
o Queries a local Neighbor Cache (NC) to determine the IPv6 next hop's link-layer address.
o ローカルの近隣キャッシュ（NC）を照会して、IPv6ネクストホップのリンク層アドレスを決定します。
o Encapsulates the packet in a link-layer header. The link-layer header includes the IPv6 next hop's link-layer address.
o パケットをリンク層ヘッダーにカプセル化します。リンク層ヘッダーには、IPv6ネクストホップのリンク層アドレスが含まれます。
o Forwards the packet to the IPv6 next hop.
o パケットをIPv6ネクストホップに転送します。
IPv6 nodes use the Neighbor Discovery Protocol (NDP) [RFC4861] to maintain the NC. Operational experience [RFC6583] shows that when an implementation cannot maintain a sufficiently complete NC, its ability to forward packets is impaired.
IPv6ノードは、近隣探索プロトコル（NDP）[RFC4861]を使用してNCを維持します。運用経験[RFC6583]は、実装が十分に完全なNCを維持できない場合、パケットを転送する能力が損なわれることを示しています。
NDP, like any other protocol, consumes processing, memory, and bandwidth resources. Its ability to maintain a sufficiently complete NC depends upon the availability of the above-mentioned resources.
NDPは、他のプロトコルと同様に、処理、メモリ、および帯域幅のリソースを消費します。十分に完全なNCを維持する機能は、上記のリソースの可用性に依存します。
This document provides benchmarking procedures for NDP. Benchmarking procedures include a Baseline Test and an NDP Scaling Test. In both tests, the Device Under Test (DUT) is an IPv6 router. Two physical links (A and B) connect the DUT to a Tester. The Tester sends traffic through Link A to the DUT. The DUT forwards that traffic, through Link B, back to the Tester.
このドキュメントでは、NDPのベンチマーク手順について説明します。ベンチマーク手順には、ベースラインテストとNDPスケーリングテストが含まれます。どちらのテストでも、テスト対象デバイス（DUT）はIPv6ルーターです。 2つの物理リンク（AおよびB）がDUTをテスターに接続します。テスターは、リンクAを介してトラフィックをDUTに送信します。 DUTはリンクBを介してそのトラフィックをテスターに転送します。
The above-mentioned traffic stream contains one or more interleaved flows. An IPv6 Destination Address uniquely identifies each flow. Or, said another way, every packet within a flow has the same IPv6 Destination Address.
上記のトラフィックストリームには、1つ以上のインターリーブフローが含まれています。 IPv6宛先アドレスは、各フローを一意に識別します。または、別の言い方をすると、フロー内のすべてのパケットは同じIPv6宛先アドレスを持っています。
In the Baseline Test, the traffic stream contains exactly one flow. Because every packet in the stream has the same IPv6 Destination Address, the DUT can forward the entire stream using exactly one NC entry. NDP is exercised minimally, and no packet loss should be observed.
ベースラインテストでは、トラフィックストリームに含まれるフローは1つだけです。ストリーム内のすべてのパケットは同じIPv6宛先アドレスを持つため、DUTは1つのNCエントリを使用してストリーム全体を転送できます。 NDPは最小限に行使され、パケット損失は観察されません。
The NDP Scaling Test is identical to the Baseline Test, except that the traffic stream contains many flows. In order to forward the stream without loss, the DUT must maintain one NC entry for each flow. If the DUT cannot maintain one NC entry for each flow, packet loss will be observed and attributed to NDP scaling limitations.
NDPスケーリングテストは、トラフィックストリームに多くのフローが含まれていることを除いて、ベースラインテストと同じです。ストリームを損失なく転送するために、DUTはフローごとに1つのNCエントリを維持する必要があります。 DUTがフローごとに1つのNCエントリを維持できない場合、パケット損失が観察され、NDPスケーリング制限に起因します。
This document proposes an NDP scaling metric, called NDP-MAX-NEIGHBORS. NDP-MAX-NEIGHBORS is the maximum number of neighbors to which an IPv6 node can send traffic during periods of high NDP activity.
このドキュメントでは、NDP-MAX-NEIGHBORSと呼ばれるNDPスケーリングメトリックを提案します。 NDP-MAX-NEIGHBORSは、NDPアクティビティが高い期間にIPv6ノードがトラフィックを送信できるネイバーの最大数です。
The procedures described herein reveal how many IPv6 neighbors an NDP implementation can discover. They also provide a rough estimate of the time required to discover those neighbors. However, that estimate does not reflect the maximum rate at which the implementation can discover neighbors. Maximum rate discovery is a topic for further exploration.
ここで説明する手順は、NDP実装が発見できるIPv6ネイバーの数を明らかにします。それらはまたそれらの隣人を発見するのに必要な時間の大まかな見積もりを提供します。ただし、その見積もりは、実装がネイバーを検出できる最大レートを反映していません。最大レートの発見は、さらなる調査のためのトピックです。
The test procedures described herein assume that NDP does not compete with other applications for resources on the DUT. When NDP competes for resources, its scaling characteristics may differ from those reported by the benchmarks described and may vary over time.
ここで説明するテスト手順は、NDPがDUT上のリソースについて他のアプリケーションと競合しないことを前提としています。 NDPがリソースをめぐって競合する場合、そのスケーリング特性は、説明されているベンチマークで報告されたものとは異なる場合があり、時間とともに変化する場合があります。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
+---------------+ +-----------+
| | | |
| | Link A | Device |
| |------------>| Under |
| Tester | | Test |
| |<------------| (DUT) |
| | Link B | |
+---------------+ +-----------+
Figure 1: Test Setup
図1：テストのセットアップ
The DUT is an IPv6 router. Two links (A and B) connect the DUT to the Tester. Link A capabilities must be identical to Link B capabilities. For example, if the interface to Link A is a 10 Gigabit Ethernet port, the interface to Link B must also be a 10 Gigabit Ethernet port.
DUTはIPv6ルーターです。 2つのリンク（AおよびB）がDUTをテスターに接続します。リンクAの機能は、リンクBの機能と同じでなければなりません。たとえば、リンクAへのインターフェイスが10ギガビットイーサネットポートである場合、リンクBへのインターフェイスも10ギガビットイーサネットポートである必要があります。
DUT interfaces are numbered as follows:
DUTインターフェイスには次のように番号が付けられています。
o Link A - 2001:2:0:0::2/64
o リンクA-2001：2：0：0 :: 2/64
o Link B - 2001:2:0:1::1/64
o リンクB-2001：2：0：1 :: 1/64
Both DUT interfaces should be configured with a 1500-byte MTU. However, if they cannot support a 1500-byte MTU, they may be configured with a 1280-byte MTU.
両方のDUTインターフェイスは、1500バイトのMTUで構成する必要があります。ただし、1500バイトのMTUをサポートできない場合は、1280バイトのMTUで構成できます。
NDP is enabled on both DUT interfaces. Therefore, the DUT emits both solicited and unsolicited Router Advertisement (RA) messages. The DUT emits an RA message at least once every 600 seconds and no more frequently than once every 200 seconds.
NDPは両方のDUTインターフェイスで有効です。したがって、DUTは送信請求メッセージと非送信請求ルーターアドバタイズ（RA）メッセージの両方を送信します。 DUTは、少なくとも600秒に1回、200秒に1回以下の頻度でRAメッセージを送信します。
When the DUT sends an RA message, it includes the following information:
DUTがRAメッセージを送信すると、次の情報が含まれます。
o Router Lifetime - 1800 seconds
o ルーターの寿命-1800秒
o Reachable Time - 0 seconds
o 到達可能時間-0秒
o Retrans Time - 0 seconds
o 再送時間-0秒
o Source Link-Layer Address - link-layer address of DUT interface
o ソースリンク層アドレス-DUTインターフェースのリンク層アドレス
o M-bit is clear (0)
o Mビットはクリア（0）
o O-bit is clear (0)
o Oビットはクリア（0）
The above-mentioned values are chosen because they are the default values specified in RFC 4861.
上記の値は、RFC 4861で指定されているデフォルト値であるために選択されています。
NDP manages the NC. Each NC entry represents an on-link neighbor and is identified by the neighbor's on-link unicast IP address. As per RFC 4861, each NC entry needs to be refreshed periodically. NDP refreshes NC entries by exchanging Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages.
NDPはNCを管理します。各NCエントリはオンリンクネイバーを表し、ネイバーのオンリンクユニキャストIPアドレスによって識別されます。 RFC 4861に従って、各NCエントリは定期的に更新する必要があります。 NDPは、近隣要請（NS）メッセージと近隣アドバタイズ（NA）メッセージを交換することにより、NCエントリを更新します。
No static NC entries are configured on the DUT.
DUTに静的NCエントリが構成されていません。
The DUT maintains a direct route to 2001:2:0:0/64 through Link A. It also maintains a direct route to 2001:2:0:1/64 through Link B. No static routes or dynamic routing protocols are configured on the DUT.
DUTは、リンクAを介して2001：2：0：0/64への直接ルートを維持します。また、リンクBを介して2001：2：0：1/64への直接ルートを維持します。静的ルートまたは動的ルーティングプロトコルは構成されていませんDUT。
Interfaces are numbered as follows:
インターフェイスには次のように番号が付けられています。
o Link A - 2001:2:0:0::1/64
o リンクA-2001：2：0：0 :: 1/64
o Link B - Multiple addresses are configured on Link B. These addresses are drawn sequentially from the 2001:2:0:1::/64 address block. The first address is 2001:2:0:1::2/64. Subsequent addresses are 2001:2:0:1::3/64, 2001:2:0:1::4/64, 2001:2:0:1::5/64, etc. The number of configured addresses should be the expected value of NDP-MAX-NEIGHBORS times 1.1.
o リンクB-複数のアドレスがリンクBで構成されています。これらのアドレスは、2001：2：0：1 :: / 64アドレスブロックから順番に描画されます。最初のアドレスは2001：2：0：1 :: 2/64です。後続のアドレスは2001：2：0：1 :: 3 / 64、2001：2：0：1 :: 4 / 64、2001：2：0：1 :: 5/64などです。構成されたアドレスの数はNDP-MAX-NEIGHBORSの1.1倍の期待値になります。
Both Tester interfaces should be configured with a 1500-byte MTU. However, if they cannot support a 1500-byte MTU, they may be configured with a 1280-byte MTU.
両方のテスターインターフェイスは、1500バイトのMTUで構成する必要があります。ただし、1500バイトのMTUをサポートできない場合は、1280バイトのMTUで構成できます。
NDP is enabled on both Tester interfaces. Therefore, upon initiation, the Tester sends Router Solicitation (RS) messages and waits for Router Advertisement (RA) messages. The Tester also exchanges Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages with the DUT.
NDPは両方のテスターインターフェイスで有効になっています。したがって、開始時に、テスターはルーター要請（RS）メッセージを送信し、ルーターアドバタイズ（RA）メッセージを待ちます。テスターは、近隣要請（NS）および近隣アドバタイズ（NA）メッセージもDUTと交換します。
No static NC entries are configured on the Tester.
テスターで静的NCエントリが構成されていません。
The Tester maintains a direct route to 2001:2:0:0/64 through Link A. It also maintains a direct route to 2001:2:0:1/64 through Link B. No static routes or dynamic routing protocols are configured on the Tester.
テスターは、リンクAを介して2001：2：0：0/64への直接ルートを維持します。また、リンクBを介して2001：2：0：1/64への直接ルートを維持します。静的ルートまたは動的ルーティングプロトコルは構成されていませんテスター。
The Tester sends a stream of test traffic through Link A to the DUT. The test traffic stream contains one or more interleaved flows. Flows are numbered 1 through N, sequentially.
テスターは、リンクAを介してテストトラフィックのストリームをDUTに送信します。テストトラフィックストリームには、1つ以上のインターリーブフローが含まれています。フローには1からNまでの番号が付けられます。
Within each flow, each packet contains an IPv6 header, and each IPv6 header contains the following information:
各フロー内で、各パケットにはIPv6ヘッダーが含まれており、各IPv6ヘッダーには次の情報が含まれています。
o Version - 6
o バージョン-6
o Traffic Class - 0
o トラフィッククラス-0
o Flow Label - 0
o フローラベル-0
o Payload Length - 0
o ペイロード長-0
o Next Header - IPv6-NoNxt (59)
o 次のヘッダー-IPv6-NoNxt（59）
o Hop Limit - 255
o ホップ制限-255
o Source Address - 2001:2:0:0::1
o 送信元アドレス-2001：2：0：0 :: 1
o Destination Address - The first 64 bits of the Destination Address are 2001:2:0:1::. The next 64 are uniquely associated with the flow. Every packet in the first flow carries the Destination Address 2001:2:0:1::2. Every subsequent flow has an IP address one greater than the last (i.e., 2001:2:0:1::3, 2001:2:0:1::4, etc.).
o 宛先アドレス-宛先アドレスの最初の64ビットは2001：2：0：1 ::です。次の64はフローに一意に関連付けられています。最初のフローのすべてのパケットは、宛先アドレス2001：2：0：1 :: 2を伝送します。後続のすべてのフローには、最後よりも1つ大きいIPアドレスがあります（つまり、2001：2：0：1 :: 3、2001：2：0：1 :: 4など）。
In order to avoid link congestion, test traffic is offered at a rate not to exceed 50% of available link bandwidth. In order to avoid burstiness and buffer occupancy, every packet in the stream is exactly 40 bytes long (i.e., the length of an IPv6 header with no IPv6 payload). Furthermore, the gap between packets is identical.
リンクの輻輳を回避するために、テストトラフィックは、使用可能なリンク帯域幅の50％を超えないレートで提供されます。バースト性とバッファの占有を回避するために、ストリーム内のすべてのパケットは正確に40バイトの長さ（つまり、IPv6ペイロードのないIPv6ヘッダーの長さ）です。さらに、パケット間のギャップは同じです。
During the course of a test, the number of flows that the test stream contains may increase. When this occurs, the rate at which test traffic is offered remains constant. For example, assume that a test stream is offered at a rate of 1,000 packets per second. This stream contains two flows, each contributing 500 packets per second to the 1,000 packet per second aggregate. When a third stream is added to the flow, all three streams must contribute 333 packets per second in order to maintain the 1,000 packet per second limit. (As in this example, rounding error is acceptable.) The DUT attempts to forward every packet in the test stream through Link B to the Tester. It does this because:
テスト中に、テストストリームに含まれるフローの数が増える場合があります。これが発生しても、テストトラフィックが提供されるレートは一定のままです。たとえば、1秒あたり1,000パケットの速度でテストストリームが提供されると仮定します。このストリームには2つのフローが含まれており、それぞれが毎秒500パケットから毎秒1,000パケットの総計に寄与しています。 3番目のストリームがフローに追加されると、1,000パケット/秒の制限を維持するために、3つのストリームすべてが333パケット/秒を提供する必要があります。 （この例のように、丸め誤差は許容されます。）DUTは、リンクBを介してテストストリーム内のすべてのパケットをテスターに転送しようとします。これは次の理由で行われます。
o Every packet in the test stream has a Destination Address drawn from the 2001:2:0:1::/64 address block.
o テストストリームのすべてのパケットには、2001：2：0：1 :: / 64アドレスブロックから取得された宛先アドレスがあります。
o The DUT has a direct route to 2001:2:0:1/64 through Link B.
o DUTには、リンクBを介して2001：2：0：1/64への直接ルートがあります。
On the Tester, two counters are configured for each flow. One counter, configured on Link A, increments when the Tester sends a packet belonging to the flow. The other counter, configured on Link B, increments when the Tester receives a packet from the flow. In order for a packet to be associated with a flow, the following conditions must all be true:
テスターでは、フローごとに2つのカウンターが構成されます。リンクAで構成された1つのカウンターは、テスターがフローに属するパケットを送信すると増分します。リンクBに設定されているもう1つのカウンターは、テスターがフローからパケットを受信すると増分します。パケットをフローに関連付けるには、次の条件をすべて満たす必要があります。
o The IPv6 Destination Address must be that of the flow.
o IPv6宛先アドレスはフローのものでなければなりません。
o The IPv6 Next Header must be IPv6-NoNxt (59).
o IPv6次ヘッダーはIPv6-NoNxt（59）でなければなりません。
The following counters also are configured on both Tester Interfaces:
次のカウンターも両方のテスターインターフェイスで構成されます。
o RS packets sent
o 送信されたRSパケット
o RA packets received
o 受信したRAパケット
o NS packets sent
o 送信されたNSパケット
o NS packets received
o 受信したNSパケット
o NA packets sent
o 聖パケット
o NA packets received
o 受信したNAパケット
o Total packets sent
o 送信されたパケットの合計
o Total packets received
o 受信したパケットの合計
The purpose of the Baseline Test is to ensure that the DUT can forward every packet in the test stream, without loss, when NDP is minimally exercised and not operating near its scaling limit.
ベースラインテストの目的は、NDPの実行が最小限に抑えられ、スケーリングの制限に近づいていない場合に、DUTがテストストリーム内のすべてのパケットを損失なく転送できることを確認することです。
o On the DUT, clear the NC.
o DUTでNCをクリアします。
o On the Tester, clear all counters.
o テスターで、すべてのカウンターをクリアします。
o On the Tester, set a timer to expire in 60 seconds.
o テスターで、タイマーが60秒で期限切れになるように設定します。
o On the Tester, start the test stream with exactly one flow (i.e., IPv6 Destination Address equals 2001:2:0:1::2).
o テスターで、1つのフローでテストストリームを開始します（つまり、IPv6宛先アドレスは2001：2：0：1 :: 2です）。
o Wait for either the timer to expire or the packets-received counter associated with the flow to increment.
o タイマーが期限切れになるか、フローに関連付けられたパケット受信カウンタが増加するのを待ちます。
o If the timer expires, stop the test stream and end the test.
o タイマーが切れた場合は、テストストリームを停止してテストを終了します。
o If the packets-received counter increments, pause the traffic stream, log the initial counter values, clear the counters, reset the timer to expire in 1800 seconds, and restart the traffic stream.
o パケット受信カウンターが増加する場合は、トラフィックストリームを一時停止し、初期カウンター値をログに記録し、カウンターをクリアし、タイマーをリセットして1800秒で期限が切れ、トラフィックストリームを再開します。
o When the timer expires, stop the test stream, wait sufficient time for any queued packets to exit, log the final counter values, and end the test.
o タイマーの期限が切れたら、テストストリームを停止し、キューに入れられたパケットが終了するのに十分な時間待機し、最終的なカウンター値を記録して、テストを終了します。
+--------------------------+
| On the DUT, clear the NC |
+-------------|------------+
|
+------------------v------------------+
| On the Tester, clear all counters |
+------------------|------------------+
|
+------------------v-----------------+
| On the Tester, set a |
| timer to expire in |
| 60 seconds |
+------------------|-----------------+
|
+------------------v-----------------+
|On the Tester, start the test stream|
|with exactly one flow (i.e., IPv6 |
|Destination Address equals |
|2001:2:0:0:1::2) |
+------------------|-----------------+
|
|
+------------------v-----------------+
|Wait for either the timer to expire |
|or packets-received counter |
|associated with the flow to |
|increment |
+------------------|-----------------+
|
/-------v-------\
/ \ Yes +--------------+
|Did timer expire?|-------| End the test |
\ / +--------------+
\-------|-------/
| No
|
/---------v--------\
/ \ No +--------------+
|Did packets-received|------| End the test |
|counter increment? | +--------------+
\ /
\---------|--------/
| Yes
|
+------------------v-----------------+
|Pause traffic stream, log initial |
|counter values, clear the counters, |
|reset the timer to expire in 1800 |
|seconds, and restart traffic stream |
+------------------|-----------------+
|
+------------------v-----------------+
|When timer expires, stop the test |
|stream, wait sufficient time for |
|any queued packets to exit, log the |
|final counter values |
+------------------|-----------------+
|
+----v---+
|End test|
+--------+
Figure 2: Baseline Test Procedure Flow Chart
図2：ベースラインテスト手順のフローチャート
The log contains initial and final values for the following counters:
ログには、次のカウンタの初期値と最終値が含まれています。
o packets-sent
o パケット送信
o packets-received
o パケット受信
The initial values of packets-sent and packets-received may be equal to one another. If these values are identical, none of the initial packets belonging to the flow were lost. However, if the initial value of packets-sent is greater than the initial value of packets-received, initial packets were lost. This loss of initial packets is acceptable.
送信済みパケットと受信済みパケットの初期値は、互いに等しい場合があります。これらの値が同一の場合、フローに属する最初のパケットはどれも失われていません。ただし、送信パケットの初期値が受信パケットの初期値より大きい場合、初期パケットは失われました。この初期パケットの損失は許容範囲です。
The final values of packets-sent and packets-received should be equal to one another. If they are not, an error has occurred. Because this error is likely to affect Scaling Test results, the error must be corrected before the Scaling Test is executed.
送信されたパケットと受信されたパケットの最終的な値は互いに等しいはずです。そうでない場合は、エラーが発生しています。このエラーはスケーリングテストの結果に影響する可能性があるため、スケーリングテストを実行する前にエラーを修正する必要があります。
The purpose of the Scaling Test is to discover the number of neighbors to which an IPv6 node can send traffic during periods of high NDP activity. We call this number NDP-MAX-NEIGHBORS.
スケーリングテストの目的は、NDPアクティビティが高い期間にIPv6ノードがトラフィックを送信できるネイバーの数を検出することです。この番号をNDP-MAX-NEIGHBORSと呼びます。
Execute the following procedure:
以下の手順を実行してください。
o On the DUT, clear the NC.
o DUTでNCをクリアします。
o On the Tester, clear all counters.
o テスターで、すべてのカウンターをクリアします。
o On the Tester, set a timer to expire in 60 seconds.
o テスターで、タイマーが60秒で期限切れになるように設定します。
o On the Tester, start the test stream with exactly one flow (i.e., IPv6 Destination Address equals 2001:2:0:1::2).
o テスターで、1つのフローでテストストリームを開始します（つまり、IPv6宛先アドレスは2001：2：0：1 :: 2です）。
o Wait for either the timer to expire or the packets-received counter associated with the flow to increment.
o タイマーが期限切れになるか、フローに関連付けられたパケット受信カウンタが増加するのを待ちます。
o If the timer expires, stop the test stream and end the test.
o タイマーが切れた場合は、テストストリームを停止してテストを終了します。
o If the packets-received counter increments, execute the following procedure N times, starting at 2 and ending at the expected value of NDP-MAX-NEIGHBORS times 1.1.
o パケット受信カウンタが増加する場合、次の手順をN回実行します。2から開始し、NDP-MAX-NEIGHBORSの期待値×1.1で終了します。
* Pause the test stream.
* テストストリームを一時停止します。
* Log the time and the value of N minus one.
* 時間とN-1の値を記録します。
* Clear the packets-sent and packets-received counters associated with the previous flow (i.e., N minus one).
* 前のフローに関連付けられた送信済みパケットと受信済みパケットのカウンターをクリアします（つまり、N-1）。
* Reset the timer to expire in 60 seconds.
* タイマーをリセットして60秒で期限切れにします。
* Add the next flow to the test stream (i.e., IPv6 Destination Address is a function of N).
* 次のフローをテストストリームに追加します（つまり、IPv6宛先アドレスはNの関数です）。
* Restart the test stream.
* テストストリームを再開します。
* Wait for either the timer to expire or the packets-received counter associated with the new flow to increment.
* タイマーが期限切れになるか、新しいフローに関連付けられたパケット受信カウンタが増加するのを待ちます。
After the procedure described above has been executed N times, clear the timer and reset it to expire in 1800 seconds. When the timer expires, stop the stream, log all counters, and end the test (after waiting sufficient time for any queued packets to exit).
上記の手順をN回実行した後、タイマーをクリアし、1800秒で期限切れになるようにリセットします。タイマーが切れたら、ストリームを停止し、すべてのカウンターをログに記録して、テストを終了します（キューに入れられたパケットが終了するのに十分な時間待機した後）。
+--------------------------+
| On the DUT, clear the NC |
+-------------|------------+
|
+------------------v------------------+
| On the Tester, clear all counters |
+------------------|------------------+
|
+------------------v-----------------+
| On the Tester, set a |
| timer to expire in |
| 60 seconds |
+------------------|-----------------+
|
+------------------v-----------------+
|On the Tester, start the test stream|
|with exactly one flow (i.e., IPv6 |
|Destination Address equals |
|2001:2:0:0:1::2) |
+------------------|-----------------+
|
+------------------v-----------------+
|Wait for either the timer to expire |
|or packets-received counter |
|associated with the flow to |
|increment |
+------------------|-----------------+
|
/-------v-------\
/ \ Yes +--------------+
|Did timer expire?|-------| End test |
\ / | and return |
\-------|-------/ +--------------+
| No
|
/---------v--------\
/ \ No +--------------+
|Did packets-received|------| End test |
|counter increment? | | and return |
\ / +--------------+
\---------|--------/
| Yes
|
+------v------+
| N=2 |
+------|------+
|
/--------------v-------------\
/ Is \ No +----------+
| N < NDP-MAX-NEIGHBORS |----| End test |
-------| times 1.1 | +----------+
| \ /
| \--------------|-------------/
| | Yes
| +-----------v----------+
| |Pause the test stream |
| +-----------|----------+
| |
| +----------v----------+
| |Log the time and the |
| |value of N minus one |
| +----------|----------+
| |
| +-----------v-----------+
| |Clear the packets-sent |
| |and packets-received |
| |counters associated |
| |with the previous flow |
| |(i.e., N minus one) |
| +-----------|-----------+
| |
| +----------v----------+
| |Reset the timer to |
| |expire in 60 seconds |
| +----------|----------+
| |
| +--------------v---------------+
| |Add the next flow to the test |
| |stream (i.e., IPv6 Destination|
| |Address is a function of N) |
| +--------------|---------------+
| |
| +------v------+
| | N=N+1 |
| +------|------+
| |
| +----------v------------+
------------|Restart the test stream|
+-----------------------+
Figure 3: Scaling Test Procedure Flow Chart
図3：スケーリングテスト手順のフローチャート
The test report includes the following:
テストレポートには以下が含まれます。
o A description of the DUT (make, model, processor, memory, and interfaces)
o DUTの説明（メーカー、モデル、プロセッサ、メモリ、インターフェース）
o Rate at which the Tester offers test traffic to the DUT (measured in packets per second)
o テスターがテストトラフィックをDUTに提供するレート（パケット/秒で測定）
o A log that records the time at which each flow was introduced to the test stream and the final value of all counters
o 各フローがテストストリームに導入された時刻とすべてのカウンターの最終値を記録するログ
o The expected value of NDP-MAX-NEIGHBORS
o NDP-MAX-NEIGHBORSの期待値
o The actual value of NDP-MAX-NEIGHBORS
o NDP-MAX-NEIGHBORSの実際の値
NDP-MAX-NEIGHBORS is equal to the number of counter pairs where packets-sent is equal to packets-received. Two counters are members of a pair if they are both associated with the same flow. If packets-sent is equal to packets-received for every counter pair, the test should be repeated with a larger expected value of NDP-MAX-NEIGHBORS.
NDP-MAX-NEIGHBORSは、送信されたパケットが受信されたパケットと等しいカウンターペアの数と同じです。 2つのカウンターが両方とも同じフローに関連付けられている場合、それらはペアのメンバーです。送信されたパケットがすべてのカウンタペアで受信されたパケットと等しい場合、NDP-MAX-NEIGHBORSの期待値を大きくしてテストを繰り返す必要があります。
If an implementation abides by the recommendation of Section 7.1 of RFC 6583, for any given counter pair, packets-received will either be equal to zero or packets-sent.
実装がRFC 6583のセクション7.1の推奨事項に準拠している場合、特定のカウンターペアについて、受信パケットはゼロまたはパケット送信のいずれかになります。
The log documents the time at which each flow was introduced to the test stream. This log reveals the effect of NC size to the time required to discover a new IPv6 neighbor.
ログには、各フローがテストストリームに導入された時刻が記録されます。このログは、新しいIPv6ネイバーを検出するために必要な時間に対するNCサイズの影響を明らかにします。
These measurements aren't recommended because of the itemized reasons below:
これらの測定値は、以下の項目別の理由により推奨されません。
This measurement relies on the DUT to provide utilization information, which is not externally observable (not black-box). However, some testing organizations may find the CPU utilization is useful auxiliary information specific to the DUT model, etc.
この測定はDUTに依存して、外部からは観測できない（ブラックボックスではない）使用率情報を提供します。ただし、一部のテスト組織では、CPU使用率がDUTモデルに固有の有用な補助情報などであることに気付く場合があります。
This benchmarking test is not intended to test DUT behavior in the presence of malformed packets.
このベンチマークテストは、不正なパケットが存在する場合のDUTの動作をテストするためのものではありません。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
Benchmarking activities as described in this memo are limited to technology characterization using controlled stimuli in a laboratory environment, with dedicated address space and the constraints specified in the sections above.
このメモに記載されているベンチマーク活動は、専用のアドレススペースと上記のセクションで指定された制約を使用して、実験環境で制御された刺激を使用した技術の特性評価に限定されます。
The benchmarking network topology will be an independent test setup and MUST NOT be connected to devices that may forward the test traffic into a production network or misroute traffic to the test management network.
ベンチマークネットワークトポロジは独立したテストセットアップであり、テストトラフィックを実稼働ネットワークに転送したり、トラフィックをテスト管理ネットワークに誤ってルーティングする可能性のあるデバイスに接続してはなりません。
Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the DUT or System Under Test (SUT). Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes.
さらに、ベンチマークは「ブラックボックス」ベースで実行され、DUTまたはSystem Under Test（SUT）の外部で観測可能な測定のみに依存します。特別な機能は、特にベンチマークの目的でDUT / SUTに存在すべきではありません。
Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and in production networks.
DUT / SUTから生じるネットワークセキュリティへの影響は、ラボと実稼働ネットワークで同じである必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<http：/ /www.rfc-editor.org/info/rfc4861>。
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, DOI 10.17487/RFC6583, March 2012, <http://www.rfc-editor.org/info/rfc6583>.
[RFC6583] Gashinsky、I.、Jaeggli、J。、およびW. Kumari、「Operational Neighbor Discovery Problems」、RFC 6583、DOI 10.17487 / RFC6583、2012年3月、<http://www.rfc-editor.org/info / rfc6583>。
Acknowledgments
謝辞
Helpful comments and suggestions were offered by Al Morton, Joel Jaeggli, Nalini Elkins, Scott Bradner, and Ram Krishnan on the BMWG email list and at BMWG meetings. Precise grammatical corrections and suggestions were offered by Ann Cerveny.
BMWGの電子メールリストとBMWGの会議で、アルモートン、ジョエルジャグリ、ナリーニエルキンス、スコットブラドナー、およびラムクリシュナンから役立つコメントと提案が寄せられました。正確な文法修正と提案は、Ann Cervenyから提供されました。
Authors' Addresses
著者のアドレス
Bill Cerveny Arbor Networks 2727 South State Street Ann Arbor, MI 48104 United States of America
Bill Cerveny Arbor Networks 2727 South State Street Ann Arbor、MI 48104アメリカ合衆国
Email: wcerveny@arbor.net
Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20170 United States of America
ロンボニカジュニパーネットワークス2251コーポレートパークドライブハーンドン、バージニア州20170アメリカ合衆国
Email: rbonica@juniper.net
Reji Thomas Juniper Networks Elnath-Exora Business Park Survey Bangalore, KA 560103 India
れじ てょまｓ じゅにぺｒ ねとぉｒｋｓ えｌなｔｈーえぉら ぶしねっｓ ぱｒｋ すｒゔぇｙ ばんがぉれ、 か ５６０１０３ いんぢあ
Email: rejithomas@juniper.net