draft-ietf-bmwg-ipv6-nd-03.txt   draft-ietf-bmwg-ipv6-nd-04.txt 
Network Working Group W. Cerveny Network Working Group W. Cerveny
Internet-Draft Arbor Networks Internet-Draft Arbor Networks
Intended status: Informational R. Bonica Intended status: Informational R. Bonica
Expires: March 26, 2017 R. Thomas Expires: May 21, 2017 R. Thomas
Juniper Networks Juniper Networks
September 22, 2016 November 17, 2016
Benchmarking The Neighbor Discovery Protocol Benchmarking The Neighbor Discovery Protocol
draft-ietf-bmwg-ipv6-nd-03 draft-ietf-bmwg-ipv6-nd-04
Abstract Abstract
This document provides benchmarking procedures for Neighbor Discovery This document provides benchmarking procedures for Neighbor Discovery
Protocol (NDP). It also proposes metrics by which an NDP 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 Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 26, 2017. This Internet-Draft will expire on May 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
2.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Tester . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Tester . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Interfaces . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Interfaces . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Neighbor Discovery Protocol (NDP) . . . . . . . . . . 6 2.2.2. Neighbor Discovery Protocol (NDP) . . . . . . . . . . 6
2.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.4. Test Traffic . . . . . . . . . . . . . . . . . . . . 6 2.2.4. Test Traffic . . . . . . . . . . . . . . . . . . . . 6
2.2.5. Counters . . . . . . . . . . . . . . . . . . . . . . 7 2.2.5. Counters . . . . . . . . . . . . . . . . . . . . . . 7
3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Baseline Test . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Baseline Test . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. Results . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. Results . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Scaling Test . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Scaling Test . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Results . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Results . . . . . . . . . . . . . . . . . . . . . . . 10
4. Measurements Explicitly Excluded . . . . . . . . . . . . . . 11 4. Measurements Explicitly Excluded . . . . . . . . . . . . . . 11
4.1. DUT CPU Utilization . . . . . . . . . . . . . . . . . . . 11 4.1. DUT CPU Utilization . . . . . . . . . . . . . . . . . . . 11
4.2. Malformed Packets . . . . . . . . . . . . . . . . . . . . 11 4.2. Malformed Packets . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. Normative References . . . . . . . . . . . . . . . . . . . . 12 8. Normative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 Identify the IPv6 next-hop (i.e., the next IPv6 node that the o Identify the IPv6 next-hop
packet traverses on route to its ultimate destination)
o Query a local Neighbor Cache (NC) to determine the IPv6 next-hop's o Query a local Neighbor Cache (NC) to determine the IPv6 next-hop's
link-layer address link-layer address
o Encapsulate the packet in a link-layer header. The link-layer o Encapsulate 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 Forward the packet to the IPv6 next-hop o Forward 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
skipping to change at page 4, line 7 skipping to change at page 4, line 7
which an IPv6 node can send traffic during periods of high NDP which an IPv6 node can send traffic during periods of high NDP
activity. activity.
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 on the DUT, NDP does The test procedures described herein assume that NDP does not compete
not compete for resources with other applications. When NDP with other applications for resources on the DUT. When NDP competes
completes for resources, its scaling characteristics may not be for resources, its scaling characteristics may differ from those
commensurate with those reported by the benchmarks described herein. reported by the benchmarks described, and may vary over time.
2. Test Setup 2. Test Setup
+---------------+ +-----------+ +---------------+ +-----------+
| | | | | | | |
| | Link A | Device | | | Link A | Device |
| |------------>| Under | | |------------>| Under |
| Tester | | Test | | Tester | | Test |
| |<------------| (DUT) | | |<------------| (DUT) |
| | Link B | | | | Link B | |
+---------------+ +-----------+ +---------------+ +-----------+
Figure 1: Test Setup Figure 1: Test Setup
The DUT is an IPv6 router. The DUT is connected to a Tester by two The DUT is an IPv6 router. Two links (A and B) connect the DUT to
links (A and B). Link A capabilities must be identical to Link B the Tester. Link A capabilities must be identical to Link B
capabilities. For example, if the interface to Link A is a 10 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, the interface to Link B must also be a 10
Gigabit Ethernet port. Furthermore, Link A and Link B must be Gigabit Ethernet port. Furthermore, Link A and Link B must be
lossless. lossless.
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:
skipping to change at page 5, line 19 skipping to change at page 5, line 19
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
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 also manages the NC. Each NC entry represents an on-link NDP manages the NC. Each NC entry represents an on-link neighbor and
neighbor and is identified by the neighbor's on-link unicast IP is identified by the neighbor's on-link unicast IP address. As per
address. NC entries contain the neighbor's link-layer address, a RFC 4861, each NC entry needs to be refreshed periodically. NDP
state variable, and several timers that are used by the Neighbor
Unreachability Detection (NUD) algorithm. Section 7.3 of RFC 4861
provides NUD details. On the DUT, NUD uses the protocol constants
defined in Section 10 of RFC 4861. As per these specifications, each
NC entry needs to be refreshed at least every 60 seconds. NDP
refreshes NC entries by exchanging Neighbor Solicitation (NS) and refreshes NC entries by exchanging Neighbor Solicitation (NS) and
Neighbor Advertisement (NA) messages. Neighbor Advertisement (NA) messages.
No static NC entries are configured on the DUT. No static NC entries are configured on the DUT.
2.1.3. Routing 2.1.3. Routing
The DUT maintains a direct route to 2001:2:0:0/64 through Link A. It 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 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. static routes or dynamic routing protocols are configured on the DUT.
skipping to change at page 6, line 28 skipping to change at page 6, line 24
2.2.3. Routing 2.2.3. Routing
The Tester maintains a direct route to 2001:2:0:0/64 through Link A. 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 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 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
skipping to change at page 7, line 13 skipping to change at page 7, line 11
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 procedure, the number of flows that the During the course of a test, the number of flows that the test stream
test stream contains may increase. When this occurs, the rate at contains may increase. When this occurs, the rate at which test
which test traffic is offered remains constant. For example, assume traffic is offered remains constant. For example, assume that a test
that a test stream is offered at a rate of 1,000 packets per second. stream is offered at a rate of 1,000 packets per second. This stream
This stream contains two flows, each contributing 500 packets per contains two flows, each contributing 500 packets per second to the
second to the 1,000 packet per second aggregate. When a third stream 1,000 packet per second aggregate. When a third stream is added to
is added to the flow, all three streams must contribute 333 packets the flow, all three streams must contribute 333 packets per second in
per second in order to maintain the 1,000 packet per second limit. order to maintain the 1,000 packet per second limit. (As in this
(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
For each address configured on the Tester interface to Link B, two On the Tester, two counters are configured for each flow. One
counters are configured. One counter, configured on the Tester counter, configured on Link A, increments when the Tester sends a
interface to Link A, increments when the Tester detects an outgoing packet belonging to the flow. The other counter, configured on Link
packet from the associated flow. The other counter, configured on B, increments when the Tester receives packet from the flow. In
the Tester interface to Link B, increments when the Tester detects an order for a packet to be associated with a flow, the following
incoming packet from the associated flow. In order for a packet to conditions must all be true:
be associated with a flow, the following 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 RS packets received o RS packets received
skipping to change at page 8, line 23 skipping to change at page 8, line 19
o Total packets sent o Total packets sent
o Total packets received o Total packets received
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, wThithout 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 Reset all counters on the Tester o On the DUT, clear the NC
o Clear the NC on the DUT o On the Tester, clear all counters
o Set a timer to expire in 60 seconds o On the Tester, set a timer to expire in 60 seconds
o Start the test stream with exactly one flow (i.e., IPv6 o On the Tester, start the test stream with exactly one flow (i.e.,
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, clear the timer, log the counters associated with the stream, log the initial counter values, clear the counters, reset
flow, clear the counters associated with the flow, reset the timer the timer to expire in 1800 seconds and restart the traffic stream
to expire in 1800 seconds and restart the traffic stream
o When the timer expires, stop the test stream, log all counters and 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 end the test
3.1.2. Results 3.1.2. Results
The two counters associated with the flow (packets-sent and packets- The log contains initial and final values for the following counters:
received) must have equal values. If they do 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 log contains two counters (packets-sent and packets-received) for o packets-sent
the flow. If these values are identical, none of the initial packets o packets-received
belonging to the flow were lost. However, if packets-sent is greater
than packets received, initial packets were lost. This loss of The final values of packets-packets sent and packets-recieved should
initial packets is acceptable. 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 initial values of packets-packets sent and packets-recieved may
be equal to one another. If these values are identical, none of the
initial packets belonging to the flow were lost. However, if
packets-sent is greater than packets received, initial packets were
lost. This loss of initial packets is acceptable.
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 Clear all counters on the Tester o On the DUT, clear the NC
o Clear the NC on the DUT o On the Tester, clear all counters
o Set a timer to expire in 60 seconds o On the Tester, set a timer to expire in 60 seconds
o Start the test stream with exactly one flow (i.e., IPv6 o On the Tester, start the test stream with exactly one flow (i.e.,
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, proceed as described o If the packets-received counter increments, proceed as described
below: below:
Execute the following procedure N times, starting at 2 and ending at Execute the following procedure N times, starting at 2 and ending at
the number of expected value of NDP-MAX-NEIGHBORS time 1.1. the number of expected value of NDP-MAX-NEIGHBORS times 1.1.
o Pause the test stream o Pause the test stream
o Clear the timer o Log the time and the value of N minus one
o Log the time, the value of N minus one, and the packets-sent and
packets-received counters associated with the previous flow (i.e.,
N minus one)
o Clear the packets-sent and packets-received counters associated o 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 o Reset the timer to expire in 60 seconds
o Add the next flow to the test stream (i.e.,IPv6 Destination o 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 o Restart the test stream
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 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 above described procedure had 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. expires, stop the stream, log all counters and end the test (after
waiting sufficient time for any queued packets to exit).
3.2.2. Results 3.2.2. 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,
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 the test stream and the final value of all counters
o All counter values o The expected 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-recieved. Two counters are members packets-sent is equal to packets-recieved. Two counters are members
of a pair if they are both associated with the same IPv6 address. If of a pair if they are both associated with the same flow. If
packets-sent is greater than zero and equal to packets-recieved for packets-sent is equal to packets-recieved for every counter pair, the
every counter pair, the test should be repeated with a larger test should be repeated with a larger expected value of NDP-MAX-
expected value of NDP-MAX-NEIGHBORS. NEIGHBORS.
If an implementation abides by the recommendation of RFC 6583, for If an implementation abides by the recommendation of Section 7.1 of
any given counter pair, packets-received will either be equal to zero RFC 6583, for any given counter pair, packets-received will either be
or packets-received. equal to zero or packets-received.
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.
The log contains two counters (packets-sent and packets-received) for
each flow. If these values are identical, none of the initial
packets belonging to the flow were lost. However, if packets-sent is
greater than packets received, initial packets were lost. This loss
of initial packets is acceptable.
4. Measurements Explicitly Excluded 4. Measurements Explicitly Excluded
These are measurements which aren't recommended because of the These are measurements which aren't recommended because of the
itemized reasons below: itemized reasons 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 subjective. 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.
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 makes no request of IANA.
 End of changes. 34 change blocks. 
86 lines changed or deleted 78 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/