Benchmarking Neighbor Discovery Problems

Abstract

This document is a benchmarking instantiation of RFC 6583: "Operational Neighbor Discovery Problems". It describes a general testing procedure and measurements that can be performed to evaluate how the problems described in RFC 6583 may impact the functionality or performance of intermediate nodes.¶

1. Introduction

This document is a benchmarking instantiation of RFC 6583: "Operational Neighbor Discovery Problems" [RFC6583]. It describes a general testing procedure and measurements that can be performed to evaluate how the problems described in RFC 6583 may impact the functionality or performance of intermediate nodes.¶

2. Terminology

Intermediate Node

An intermediate node can be a router, switch, firewall or any other device which separates end-nodes. The tests in this document can be completed with any intermediate node which maintains a list of addresses that traverse the intermediate node, although not all measurements and performance characteristics may apply. While it is likely that the intermediate node which will be the DUT will be at the edge of a network directly adjacent to an end-node, there may be reasons to test intermediate nodes closer to the center of the network path.¶

Neighbor Discovery

See Section 1 of RFC 4861 [RFC4861]¶

NDP Triggering Event

An event which forces the DUT (Device Under Test) to perform a neighbor solicitation. A triggering event could be an ICMPv6 echo request, but could also be any other packets which require discovering the MAC address of existing and non-existing nodes on an IPv6 subnet. A concern with using ICMPv6 echo requests as triggering events is that some immediate nodes deprioritize functions involving ICMPv6 echo requests.¶

Scanner Network

The network from which the scanning device is connected.¶

Target Network

The network for which the scanning tests is targeted.¶

Scanning Interface

The node which is conducting the scanning activity.¶

Target Network Measurement Interface

A node that resides on the target network, which is primarily used to measure DUT performance while the scanning activity is occurring.¶

Non-participating Network

Network connected to DUT, for which nodes are neither activie participants nor being directly impacted by the test traffic.¶

3. Test Setup

The test network design is fairly simple. The network needs to minimally have two subnets: one from which the scanner(s) source their scanning activity and the other which is the target network of the address scans.¶

It is assumed that the latency for all network segments is neglible.¶

At least one node should reside on the target network to confirm some of the performance characteristics.¶

Basic format of test network. Note that optional "non-participating network" is a third network not related to the scanner or target network.¶

+---------------+             +-----------+              +--------------+
|               |   Scanner   |           |   Target     |              |
|   Scanning    |-------------|    DUT    |--------------|Target Network|
|   interface   |   Network   |           |   Network    |  interface   |
|               |             |           |              |              |
+---------------+             +-----------+              +--------------+
                                    |
                                    |
                           +-----------------+
                           |                 |
                           |Non-participating|
                           |    network      |
                           |                 |
                           +-----------------+

4. Measurements

Throughout measurements, two testing interfaces are defined:¶

tester#1-new: Sets up new addresses¶

tester#2-renew: Discovers addresses previously discovered¶

5. Measurements Explicitly Excluded

These are measurements which while possible, aren't being made because of the itemized reasons below:¶

6. DUT initialization

At the beginning of each test, the neighbor cache of the DUT should be initialized¶

10. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/rfc/rfc2119.txt>.

[RFC2544]

Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999, <http://www.rfc-editor.org/rfc/rfc2544.txt>.

[RFC4861]

Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <http://www.rfc-editor.org/rfc/rfc4861.txt>.

[RFC5180]

Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, "IPv6 Benchmarking Methodology for Network Interconnect Devices", RFC 5180, May 2008, <http://www.rfc-editor.org/rfc/rfc5180.txt>.

[RFC6583]

Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, March 2012, <http://www.rfc-editor.org/rfc/rfc6583.txt>.