draft-ietf-bmwg-ipv6-nd-06.txt   rfc8161.txt 
Network Working Group W. Cerveny Internet Engineering Task Force (IETF) W. Cerveny
Internet-Draft Arbor Networks Request for Comments: 8161 Arbor Networks
Intended status: Informational R. Bonica Category: Informational R. Bonica
Expires: September 2, 2017 R. Thomas ISSN: 2070-1721 R. Thomas
Juniper Networks Juniper Networks
March 1, 2017 May 2017
Benchmarking The Neighbor Discovery Protocol Benchmarking the Neighbor Discovery Protocol
draft-ietf-bmwg-ipv6-nd-06
Abstract Abstract
This document provides benchmarking procedures for Neighbor Discovery This document provides benchmarking procedures for the Neighbor
Protocol (NDP). It also proposes metrics by which an NDP Discovery Protocol (NDP). It also proposes metrics by which an NDP
implementation's scaling capabilities can be measured. implementation's scaling capabilities can be measured.
Requirements Language
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].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on September 2, 2017. 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.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................2
2. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language ......................................4
2.1. Device Under Test (DUT) . . . . . . . . . . . . . . . . . 4 2. Test Setup ......................................................4
2.1.1. Interfaces . . . . . . . . . . . . . . . . . . . . . 4 2.1. Device Under Test (DUT) ....................................4
2.1.2. Neighbor Discovery Protocol (NDP) . . . . . . . . . . 4 2.1.1. Interfaces ..........................................4
2.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.2. Neighbor Discovery Protocol (NDP) ...................5
2.2. Tester . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.3. Routing .............................................5
2.2.1. Interfaces . . . . . . . . . . . . . . . . . . . . . 5 2.2. Tester .....................................................6
2.2.2. Neighbor Discovery Protocol (NDP) . . . . . . . . . . 6 2.2.1. Interfaces ..........................................6
2.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2. Neighbor Discovery Protocol (NDP) ...................6
2.2.4. Test Traffic . . . . . . . . . . . . . . . . . . . . 6 2.2.3. Routing .............................................6
2.2.5. Counters . . . . . . . . . . . . . . . . . . . . . . 7 2.2.4. Test Traffic ........................................7
3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.5. Counters ............................................8
3.1. Baseline Test . . . . . . . . . . . . . . . . . . . . . . 8 3. Tests ...........................................................8
3.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Baseline Test ..............................................8
3.1.2. Baseline Test Procedure Flow Chart . . . . . . . . . 8 3.1.1. Procedure ...........................................9
3.1.3. Results . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.2. Baseline Test Procedure Flow Chart ..................9
3.2. Scaling Test . . . . . . . . . . . . . . . . . . . . . . 10 3.1.3. Results ............................................11
3.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Scaling Test ..............................................11
3.2.2. Scaling Test Procedure Flow Chart . . . . . . . . . . 11 3.2.1. Procedure ..........................................11
3.2.3. Results . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.2. Scaling Test Procedure Flow Chart ..................13
4. Measurements Explicitly Excluded . . . . . . . . . . . . . . 14 3.2.3. Results ............................................15
4.1. DUT CPU Utilization . . . . . . . . . . . . . . . . . . . 14 4. Measurements Explicitly Excluded ...............................15
4.2. Malformed Packets . . . . . . . . . . . . . . . . . . . . 14 4.1. DUT CPU Utilization .......................................15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4.2. Malformed Packets .........................................15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations ............................................16
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations ........................................16
8. Normative References . . . . . . . . . . . . . . . . . . . . 15 7. Normative References ...........................................16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgments ...................................................16
Authors' Addresses ................................................17
1. Introduction 1. Introduction
When an IPv6 node forwards a packet, it executes the following When an IPv6 node forwards a packet, it executes the following
procedure: procedure:
o Identifies the outbound interface and IPv6 next-hop o Identifies the outbound interface and IPv6 next hop.
o Queries a local Neighbor Cache (NC) to determine the IPv6 next- o Queries a local Neighbor Cache (NC) to determine the IPv6 next
hop's link-layer address hop's link-layer address.
o Encapsulates the packet in a link-layer header. The link-layer o Encapsulates the packet in a link-layer header. The link-layer
header includes the IPv6 next-hop's link-layer address header includes the IPv6 next hop's link-layer address.
o Forwards the packet to the IPv6 next-hop o Forwards the packet to the IPv6 next hop.
IPv6 nodes use the Neighbor Discovery Protocol (NDP) [RFC4861] to IPv6 nodes use the Neighbor Discovery Protocol (NDP) [RFC4861] to
maintain the NC. Operational experience [RFC6583] shows that when an maintain the NC. Operational experience [RFC6583] shows that when an
implementation cannot maintain a sufficiently complete NC, its implementation cannot maintain a sufficiently complete NC, its
ability to forward packets is impaired. ability to forward packets is impaired.
NDP, like any other protocol, consumes processing, memory, and NDP, like any other protocol, consumes processing, memory, and
bandwidth resources. Its ability to maintain a sufficiently complete bandwidth resources. Its ability to maintain a sufficiently complete
NC depends upon the availability of the above-mentioned resources. NC depends upon the availability of the above-mentioned resources.
skipping to change at page 3, line 34 skipping to change at page 3, line 29
through Link B, back to the Tester. through Link B, back to the Tester.
The above-mentioned traffic stream contains one or more interleaved The above-mentioned traffic stream contains one or more interleaved
flows. An IPv6 Destination Address uniquely identifies each flow. flows. An IPv6 Destination Address uniquely identifies each flow.
Or, said another way, every packet within a flow has the same IPv6 Or, said another way, every packet within a flow has the same IPv6
Destination Address. Destination Address.
In the Baseline Test, the traffic stream contains exactly one flow. In the Baseline Test, the traffic stream contains exactly one flow.
Because every packet in the stream has the same IPv6 Destination Because every packet in the stream has the same IPv6 Destination
Address, the DUT can forward the entire stream using exactly one NC Address, the DUT can forward the entire stream using exactly one NC
entry. NDP is exercised minimally and no packet loss should be entry. NDP is exercised minimally, and no packet loss should be
observed. observed.
The NDP Scaling Test is identical to the Baseline Test, except that The NDP Scaling Test is identical to the Baseline Test, except that
the traffic stream contains many flows. In order to forward the the traffic stream contains many flows. In order to forward the
stream without loss, the DUT must maintain one NC entry for each 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 flow. If the DUT cannot maintain one NC entry for each flow, packet
loss will be observed and attributed to NDP scaling limitations. loss will be observed and attributed to NDP scaling limitations.
This document proposes an NDP scaling metric, called NDP-MAX- This document proposes an NDP scaling metric, called NDP-MAX-
NEIGHBORS. NDP-MAX-NEIGHBORS is the maximum number of neighbors to NEIGHBORS. NDP-MAX-NEIGHBORS is the maximum number of neighbors to
skipping to change at page 4, line 10 skipping to change at page 4, line 8
The procedures described herein reveal how many IPv6 neighbors an NDP The procedures described herein reveal how many IPv6 neighbors an NDP
implementation can discover. They also provide a rough estimate of implementation can discover. They also provide a rough estimate of
the time required to discover those neighbors. However, that the time required to discover those neighbors. However, that
estimate does not reflect the maximum rate at which the estimate does not reflect the maximum rate at which the
implementation can discover neighbors. Maximum rate discovery is a implementation can discover neighbors. Maximum rate discovery is a
topic for further exploration. topic for further exploration.
The test procedures described herein assume that NDP does not compete The test procedures described herein assume that NDP does not compete
with other applications for resources on the DUT. When NDP competes with other applications for resources on the DUT. When NDP competes
for resources, its scaling characteristics may differ from those for resources, its scaling characteristics may differ from those
reported by the benchmarks described, and may vary over time. reported by the benchmarks described and may vary over time.
1.1. Requirements Language
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].
2. Test Setup 2. Test Setup
+---------------+ +-----------+ +---------------+ +-----------+
| | | | | | | |
| | Link A | Device | | | Link A | Device |
| |------------>| Under | | |------------>| Under |
| Tester | | Test | | Tester | | Test |
| |<------------| (DUT) | | |<------------| (DUT) |
| | Link B | | | | Link B | |
skipping to change at page 4, line 39 skipping to change at page 4, line 43
Gigabit Ethernet port. Gigabit Ethernet port.
2.1. Device Under Test (DUT) 2.1. Device Under Test (DUT)
2.1.1. Interfaces 2.1.1. Interfaces
DUT interfaces are numbered as follows: DUT interfaces are numbered as follows:
o Link A - 2001:2:0:0::2/64 o Link A - 2001:2:0:0::2/64
o Link B- 2001:2:0:1::1/64 o Link B - 2001:2:0:1::1/64
Both DUT interfaces should be configured with a 1500-byte MTU. Both DUT interfaces should be configured with a 1500-byte MTU.
However, if they cannot support a 1500-byte MTU, they may be However, if they cannot support a 1500-byte MTU, they may be
configured with a 1280-byte MTU. configured with a 1280-byte MTU.
2.1.2. Neighbor Discovery Protocol (NDP) 2.1.2. Neighbor Discovery Protocol (NDP)
NDP is enabled on both DUT interfaces. Therefore, the DUT emits both NDP is enabled on both DUT interfaces. Therefore, the DUT emits both
solicited and unsolicited Router Advertisement (RA) messages. The solicited and unsolicited Router Advertisement (RA) messages. The
DUT emits an RA message at least once every 600 seconds and no more DUT emits an RA message at least once every 600 seconds and no more
skipping to change at page 5, line 14 skipping to change at page 5, line 21
When the DUT sends an RA message, it includes the following When the DUT sends an RA message, it includes the following
information: information:
o Router Lifetime - 1800 seconds o Router Lifetime - 1800 seconds
o Reachable Time - 0 seconds o Reachable Time - 0 seconds
o Retrans Time - 0 seconds o Retrans Time - 0 seconds
o Source Link Layer Address - Link layer address of DUT interface o Source Link-Layer Address - link-layer address of DUT interface
o M-bit is clear (0) o M-bit is clear (0)
o O-bit is clear (0) o O-bit is clear (0)
The above-mentioned values are chosen because they are the default The above-mentioned values are chosen because they are the default
values specified in RFC 4861. values specified in RFC 4861.
NDP manages the NC. Each NC entry represents an on-link neighbor and 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 is identified by the neighbor's on-link unicast IP address. As per
skipping to change at page 5, line 49 skipping to change at page 6, line 17
2.2.1. Interfaces 2.2.1. Interfaces
Interfaces are numbered as follows: Interfaces are numbered as follows:
o Link A - 2001:2:0:0::1/64 o Link A - 2001:2:0:0::1/64
o Link B - Multiple addresses are configured on Link B. These o Link B - Multiple addresses are configured on Link B. These
addresses are drawn sequentially from the 2001:2:0:1::/64 address addresses are drawn sequentially from the 2001:2:0:1::/64 address
block. The first address is 2001:2:0:1::2/64. Subsequent 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, addresses are 2001:2:0:1::3/64, 2001:2:0:1::4/64,
2001:2:0:1::5/64, et cetera. The number of configured addresses 2001:2:0:1::5/64, etc. The number of configured addresses should
should be the expected value of NDP-MAX-NEIGHBORS times 1.1. be the expected value of NDP-MAX-NEIGHBORS times 1.1.
Both Tester interfaces should be configured with a 1500-byte MTU. Both Tester interfaces should be configured with a 1500-byte MTU.
However, if they cannot support a 1500-byte MTU, they may be However, if they cannot support a 1500-byte MTU, they may be
configured with a 1280-byte MTU. configured with a 1280-byte MTU.
2.2.2. Neighbor Discovery Protocol (NDP) 2.2.2. Neighbor Discovery Protocol (NDP)
NDP is enabled on both Tester interfaces. Therefore, upon NDP is enabled on both Tester interfaces. Therefore, upon
initiation, the Tester sends Router Solicitation (RS) messages and initiation, the Tester sends Router Solicitation (RS) messages and
waits for Router Advertisement (RA) messages. The Tester also waits for Router Advertisement (RA) messages. The Tester also
skipping to change at page 6, line 32 skipping to change at page 7, line 11
It also maintains a direct route to 2001:2:0:1/64 through Link B. No 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 static routes or dynamic routing protocols are configured on the
Tester. Tester.
2.2.4. Test Traffic 2.2.4. Test Traffic
The Tester sends a stream of test traffic through Link A to the DUT. The Tester sends a stream of test traffic through Link A to the DUT.
The test traffic stream contains one or more interleaved flows. The test traffic stream contains one or more interleaved flows.
Flows are numbered 1 through N, sequentially. Flows are numbered 1 through N, sequentially.
Within each flow, each packet contains an IPv6 header and each IPv6 Within each flow, each packet contains an IPv6 header, and each IPv6
header contains the following information: header contains the following information:
o Version - 6 o Version - 6
o Traffic Class - 0 o Traffic Class - 0
o Flow Label - 0 o Flow Label - 0
o Payload Length - 0 o Payload Length - 0
o Next Header - IPv6-NoNxt (59) o Next Header - IPv6-NoNxt (59)
o Hop Limit - 255 o Hop Limit - 255
o Source Address - 2001:2:0:0::1 o Source Address - 2001:2:0:0::1
o Destination Address - The first 64 bits of the Destination Address o Destination Address - The first 64 bits of the Destination Address
are 2001:2:0:1::. The next 64 are uniquely associated with the are 2001:2:0:1::. The next 64 are uniquely associated with the
flow. Every packet in the first flow carries the Destination flow. Every packet in the first flow carries the Destination
address 2001:2:0:1::2. Every subsequent flow has an IP address 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, one greater than the last (i.e., 2001:2:0:1::3, 2001:2:0:1::4,
etc.) etc.).
In order to avoid link congestion, test traffic is offered at a rate 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 not to exceed 50% of available link bandwidth. In order to avoid
burstiness and buffer occupancy, every packet in the stream is burstiness and buffer occupancy, every packet in the stream is
exactly 40 bytes long (i.e., the length of an IPv6 header with no exactly 40 bytes long (i.e., the length of an IPv6 header with no
IPv6 payload). Furthermore, the gap between packets is identical. IPv6 payload). Furthermore, the gap between packets is identical.
During the course of a test, the number of flows that the test stream 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 contains may increase. When this occurs, the rate at which test
traffic is offered remains constant. For example, assume that a test traffic is offered remains constant. For example, assume that a test
skipping to change at page 7, line 22 skipping to change at page 8, line 4
During the course of a test, the number of flows that the test stream 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 contains may increase. When this occurs, the rate at which test
traffic is offered remains constant. For example, assume that a 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 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 contains two flows, each contributing 500 packets per second to the
1,000 packet per second aggregate. When a third stream is added to 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 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 order to maintain the 1,000 packet per second limit. (As in this
example, rounding error is acceptable.) example, rounding error is acceptable.)
The DUT attempts to forward every packet in the test stream through The DUT attempts to forward every packet in the test stream through
Link B to the Tester. It does this because: Link B to the Tester. It does this because:
o Every packet in the test stream has a destination address drawn o Every packet in the test stream has a Destination Address drawn
from the 2001:2:0:1::/64 address block from the 2001:2:0:1::/64 address block.
o The DUT has a direct route to 2001:2:0:1/64 through Link B o The DUT has a direct route to 2001:2:0:1/64 through Link B.
2.2.5. Counters 2.2.5. Counters
On the Tester, two counters are configured for each flow. One On the Tester, two counters are configured for each flow. One
counter, configured on Link A, increments when the Tester sends a counter, configured on Link A, increments when the Tester sends a
packet belonging to the flow. The other counter, configured on Link packet belonging to the flow. The other counter, configured on Link
B, increments when the Tester receives packet from the flow. In B, increments when the Tester receives a packet from the flow. In
order for a packet to be associated with a flow, the following order for a packet to be associated with a flow, the following
conditions must all be true: conditions must all be true:
o The IPv6 Destination Address must be that of the flow o The IPv6 Destination Address must be that of the flow.
o The IPv6 Next Header must be IPv6-NoNxt (59) o The IPv6 Next Header must be IPv6-NoNxt (59).
The following counters also are configured on both Tester Interfaces: The following counters also are configured on both Tester Interfaces:
o RS packets sent o RS packets sent
o RA packets received o RA packets received
o NS packets sent o NS packets sent
o NS packets received o NS packets received
o NA packets sent o NA packets sent
o NA packets received o NA packets received
o Total packets sent o Total packets sent
o Total packets received o Total packets received
skipping to change at page 8, line 24 skipping to change at page 9, line 7
3. Tests 3. Tests
3.1. Baseline Test 3.1. Baseline Test
The purpose of the Baseline Test is to ensure that the DUT can 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 forward every packet in the test stream, without loss, when NDP is
minimally exercised and not operating near its scaling limit. minimally exercised and not operating near its scaling limit.
3.1.1. Procedure 3.1.1. Procedure
o On the DUT, clear the NC o On the DUT, clear the NC.
o On the Tester, clear all counters o On the Tester, clear all counters.
o On the Tester, set a timer to expire in 60 seconds o On the Tester, set a timer to expire in 60 seconds.
o On the Tester, start the test stream with exactly one flow (i.e., o On the Tester, start the test stream with exactly one flow (i.e.,
IPv6 Destination Address equals 2001:2:0:1::2) IPv6 Destination Address equals 2001:2:0:1::2).
o Wait for either the timer to expire or the packets-received o Wait for either the timer to expire or the packets-received
counter associated with the flow to increment counter associated with the flow to increment.
o If the timer expires, stop the test stream and end the test o If the timer expires, stop the test stream and end the test.
o If the packets-received counter increments, pause the traffic o If the packets-received counter increments, pause the traffic
stream, log the initial counter values, clear the counters, reset stream, log the initial counter values, clear the counters, reset
the timer to expire in 1800 seconds and restart the traffic stream the timer to expire in 1800 seconds, and restart the traffic
stream.
o When the timer expires, stop the test stream, wait sufficient time o When the timer expires, stop the test stream, wait sufficient time
for any queued packets to exit, log the final counter values and for any queued packets to exit, log the final counter values, and
end the test end the test.
3.1.2. Baseline Test Procedure Flow Chart 3.1.2. Baseline Test Procedure Flow Chart
+--------------------------+ +--------------------------+
| On the DUT, clear the NC | | On the DUT, clear the NC |
+-------------|------------+ +-------------|------------+
| |
+------------------v------------------+ +------------------v------------------+
| On the tester, clear all counters | | On the Tester, clear all counters |
+------------------|------------------+ +------------------|------------------+
| |
+------------------v-----------------+ +------------------v-----------------+
| On the tester, set a | | On the Tester, set a |
| timer to expire in | | timer to expire in |
| 60 seconds | | 60 seconds |
+------------------|-----------------+ +------------------|-----------------+
| |
+------------------v-----------------+ +------------------v-----------------+
|On the tester, start the test stream| |On the Tester, start the test stream|
|with exactly one flow (i.e., IPv6 | |with exactly one flow (i.e., IPv6 |
|destination address equals | |Destination Address equals |
|2001:2:0:0:1::2) | |2001:2:0:0:1::2) |
+------------------|-----------------+ +------------------|-----------------+
| |
|
+------------------v-----------------+ +------------------v-----------------+
|Wait for either the timer to expire | |Wait for either the timer to expire |
|or packets-received counter | |or packets-received counter |
|associated with the flow to | |associated with the flow to |
|increment | |increment |
+------------------|-----------------+ +------------------|-----------------+
| |
/-------v-------\ /-------v-------\
/ \ Yes +--------------+ / \ Yes +--------------+
|Did timer expire?|-------| End the test | |Did timer expire?|-------| End the test |
skipping to change at page 9, line 47 skipping to change at page 10, line 30
/ \ No +--------------+ / \ No +--------------+
|Did packets-received|------| End the test | |Did packets-received|------| End the test |
|counter increment? | +--------------+ |counter increment? | +--------------+
\ / \ /
\---------|--------/ \---------|--------/
| Yes | Yes
| |
+------------------v-----------------+ +------------------v-----------------+
|Pause traffic stream, log initial | |Pause traffic stream, log initial |
|counter values, clear the counters, | |counter values, clear the counters, |
|reset the time to expire in 1800 | |reset the timer to expire in 1800 |
|seconds and restart traffic stream | |seconds, and restart traffic stream |
+------------------|-----------------+ +------------------|-----------------+
| |
+------------------v-----------------+ +------------------v-----------------+
|When timer expires, stop the test | |When timer expires, stop the test |
|stream, wait sufficient time for | |stream, wait sufficient time for |
|any queued packets to exit, log the | |any queued packets to exit, log the |
|final counter values | |final counter values |
+------------------|-----------------+ +------------------|-----------------+
| |
+----v---+ +----v---+
skipping to change at page 10, line 46 skipping to change at page 11, line 35
3.2. Scaling Test 3.2. Scaling Test
The purpose of the Scaling Test is to discover the number of The purpose of the Scaling Test is to discover the number of
neighbors to which an IPv6 node can send traffic during periods of neighbors to which an IPv6 node can send traffic during periods of
high NDP activity. We call this number NDP-MAX-NEIGHBORS. high NDP activity. We call this number NDP-MAX-NEIGHBORS.
3.2.1. Procedure 3.2.1. Procedure
Execute the following procedure: Execute the following procedure:
o On the DUT, clear the NC o On the DUT, clear the NC.
o On the Tester, clear all counters o On the Tester, clear all counters.
o On the Tester, set a timer to expire in 60 seconds.
o On the Tester, set a timer to expire in 60 seconds
o On the Tester, start the test stream with exactly one flow (i.e., o On the Tester, start the test stream with exactly one flow (i.e.,
IPv6 Destination Address equals 2001:2:0:1::2) IPv6 Destination Address equals 2001:2:0:1::2).
o Wait for either the timer to expire or the packets-received o Wait for either the timer to expire or the packets-received
counter associated with the flow to increment counter associated with the flow to increment.
o If the timer expires, stop the test stream and end the test
o If the packets-received counter increments, proceed as described o If the timer expires, stop the test stream and end the test.
below:
Execute the following procedure N times, starting at 2 and ending at o If the packets-received counter increments, execute the following
the number of expected value of NDP-MAX-NEIGHBORS times 1.1. procedure N times, starting at 2 and ending at the expected value
of NDP-MAX-NEIGHBORS times 1.1.
o Pause the test stream * Pause the test stream.
o Log the time and the value of N minus one * Log the time and the value of N minus one.
o Clear the packets-sent and packets-received counters associated * Clear the packets-sent and packets-received counters associated
with the previous flow (i.e., N minus one) with the previous flow (i.e., N minus one).
o Reset the timer to expire in 60 seconds * Reset the timer to expire in 60 seconds.
o Add the next flow to the test stream (i.e.,IPv6 Destination * Add the next flow to the test stream (i.e., IPv6 Destination
Address is a function of N) Address is a function of N).
o Restart the test stream * Restart the test stream.
o Wait for either the timer to expire or the packets-received * Wait for either the timer to expire or the packets-received
counter associated with the new flow to increment counter associated with the new flow to increment.
After the above described procedure had been executed N times, clear After the procedure described above has been executed N times, clear
the timer and reset it to expire in 1800 seconds. When the timer 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 expires, stop the stream, log all counters, and end the test (after
waiting sufficient time for any queued packets to exit). waiting sufficient time for any queued packets to exit).
3.2.2. Scaling Test Procedure Flow Chart 3.2.2. Scaling Test Procedure Flow Chart
+--------------------------+ +--------------------------+
| On the DUT, clear the NC | | On the DUT, clear the NC |
+-------------|------------+ +-------------|------------+
| |
+------------------v------------------+ +------------------v------------------+
| On the tester, clear all counters | | On the Tester, clear all counters |
+------------------|------------------+ +------------------|------------------+
| |
+------------------v-----------------+ +------------------v-----------------+
| On the tester, set a | | On the Tester, set a |
| timer to expire in | | timer to expire in |
| 60 seconds | | 60 seconds |
+------------------|-----------------+ +------------------|-----------------+
| |
+------------------v-----------------+ +------------------v-----------------+
|On the tester, start the test stream| |On the Tester, start the test stream|
|with exactly one flow (i.e., IPv6 | |with exactly one flow (i.e., IPv6 |
|destination address equals | |Destination Address equals |
|2001:2:0:0:1::2) | |2001:2:0:0:1::2) |
+------------------|-----------------+ +------------------|-----------------+
| |
+------------------v-----------------+ +------------------v-----------------+
|Wait for either the timer to expire | |Wait for either the timer to expire |
|or packets-received counter | |or packets-received counter |
|associated with the flow to | |associated with the flow to |
|increment | |increment |
+------------------|-----------------+ +------------------|-----------------+
| |
skipping to change at page 13, line 10 skipping to change at page 14, line 21
| | Yes | | Yes
| +-----------v----------+ | +-----------v----------+
| |Pause the test stream | | |Pause the test stream |
| +-----------|----------+ | +-----------|----------+
| | | |
| +----------v----------+ | +----------v----------+
| |Log the time and the | | |Log the time and the |
| |value of N minus one | | |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----------+ | +----------v----------+
| |Reset the timer to | | |Reset the timer to |
| |expire in 60 seconds | | |expire in 60 seconds |
| +----------|----------+ | +----------|----------+
| | | |
| +--------------v---------------+ | +--------------v---------------+
| |Add the next flow to the test | | |Add the next flow to the test |
| |stream (i.e., IPv6 destination| | |stream (i.e., IPv6 Destination|
| |address is a function of N) | | |Address is a function of N) |
| +--------------|---------------+ | +--------------|---------------+
| | | |
| +------v------+
| | N=N+1 |
| +------|------+
| |
| +----------v------------+ | +----------v------------+
------------|Restart the test stream| ------------|Restart the test stream|
+-----------------------+ +-----------------------+
Figure 3: Scaling Test Procedure Flow Chart Figure 3: Scaling Test Procedure Flow Chart
3.2.3. Results 3.2.3. Results
The test report includes the following: The test report includes the following:
o A description of the DUT (make, model, processor, memory, o A description of the DUT (make, model, processor, memory, and
interfaces) interfaces)
o Rate at which the Tester offers test traffic to the DUT (measured o Rate at which the Tester offers test traffic to the DUT (measured
in packets per second) in packets per second)
o A log that records the time at which each flow was introduced to o A log that records the time at which each flow was introduced to
the test stream and the final value of all counters the test stream and the final value of all counters
o The expected value of NDP-MAX-NEIGHBORS o The expected value of NDP-MAX-NEIGHBORS
o The actual value of NDP-MAX-NEIGHBORS o The actual value of NDP-MAX-NEIGHBORS
NDP-MAX-NEIGHBORS is equal to the number of counter pairs where NDP-MAX-NEIGHBORS is equal to the number of counter pairs where
packets-sent is equal to packets-received. Two counters are members packets-sent is equal to packets-received. Two counters are members
of a pair if they are both associated with the same flow. If of a pair if they are both associated with the same flow. If
packets-sent is equal to packets-recieved for every counter pair, the packets-sent is equal to packets-received for every counter pair, the
test should be repeated with a larger expected value of NDP-MAX- test should be repeated with a larger expected value of NDP-MAX-
NEIGHBORS. NEIGHBORS.
If an implementation abides by the recommendation of Section 7.1 of If an implementation abides by the recommendation of Section 7.1 of
RFC 6583, for any given counter pair, packets-received will either be RFC 6583, for any given counter pair, packets-received will either be
equal to zero or packets-sent. equal to zero or packets-sent.
The log documents the time at which each flow was introduced to the 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 test stream. This log reveals the effect of NC size to the time
required to discover a new IPv6 neighbor. required to discover a new IPv6 neighbor.
4. Measurements Explicitly Excluded 4. Measurements Explicitly Excluded
These are measurements which aren't recommended because of the These measurements aren't recommended because of the itemized reasons
itemized reasons below: below:
4.1. DUT CPU Utilization 4.1. DUT CPU Utilization
This measurement relies on the DUT to provide utilization This measurement relies on the DUT to provide utilization
information, which is not externally observable (not black-box). information, which is not externally observable (not black-box).
However, some testing organizations may find the CPU utilization is However, some testing organizations may find the CPU utilization is
useful auxiliary information specific to the DUT model, etc. useful auxiliary information specific to the DUT model, etc.
4.2. Malformed Packets 4.2. Malformed Packets
This benchmarking test is not intended to test DUT behavior in the This benchmarking test is not intended to test DUT behavior in the
presence of malformed packets. presence of malformed packets.
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document does not require any IANA actions.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations 6. Security Considerations
Benchmarking activities as described in this memo are limited to Benchmarking activities as described in this memo are limited to
technology characterization using controlled stimuli in a laboratory technology characterization using controlled stimuli in a laboratory
environment, with dedicated address space and the constraints environment, with dedicated address space and the constraints
specified in the sections above. specified in the sections above.
The benchmarking network topology will be an independent test setup The benchmarking network topology will be an independent test setup
and MUST NOT be connected to devices that may forward the test and MUST NOT be connected to devices that may forward the test
traffic into a production network, or misroute traffic to the test traffic into a production network or misroute traffic to the test
management network. management network.
Further, benchmarking is performed on a "black-box" basis, relying Further, benchmarking is performed on a "black-box" basis, relying
solely on measurements observable external to the DUT/SUT. Special solely on measurements observable external to the DUT or System Under
capabilities SHOULD NOT exist in the DUT/SUT specifically for Test (SUT). Special capabilities SHOULD NOT exist in the DUT/SUT
benchmarking purposes. specifically for benchmarking purposes.
Any implications for network security arising from the DUT/SUT SHOULD Any implications for network security arising from the DUT/SUT SHOULD
be identical in the lab and in production networks. be identical in the lab and in production networks.
7. Acknowledgments 7. Normative References
Helpful comments and suggestions were offered by Al Morton, Joel
Jaeggli, Nalini Elkins, Scott Bradner, and Ram Krishnan, on the BMWG
e-mail list and at BMWG meetings. Precise grammatical corrections
and suggestions were offered by Ann Cerveny.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012. Neighbor Discovery Problems", RFC 6583,
DOI 10.17487/RFC6583, March 2012,
<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.
Authors' Addresses Authors' Addresses
Bill Cerveny Bill Cerveny
Arbor Networks Arbor Networks
2727 South State Street 2727 South State Street
Ann Arbor, MI 48104 Ann Arbor, MI 48104
USA United States of America
Email: wcerveny@arbor.net Email: wcerveny@arbor.net
Ron Bonica Ron Bonica
Juniper Networks Juniper Networks
2251 Corporate Park Drive 2251 Corporate Park Drive
Herndon, VA 20170 Herndon, VA 20170
USA United States of America
Email: rbonica@juniper.net Email: rbonica@juniper.net
Reji Thomas Reji Thomas
Juniper Networks Juniper Networks
Elnath-Exora Business Park Survey Elnath-Exora Business Park Survey
Bangalore, KA 560103 Bangalore, KA 560103
India India
Email: rejithomas@juniper.net Email: rejithomas@juniper.net
 End of changes. 79 change blocks. 
147 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/