draft-ietf-bmwg-ipv6-nd-05.txt   draft-ietf-bmwg-ipv6-nd-06.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: August 28, 2017 R. Thomas Expires: September 2, 2017 R. Thomas
Juniper Networks Juniper Networks
February 24, 2017 March 1, 2017
Benchmarking The Neighbor Discovery Protocol Benchmarking The Neighbor Discovery Protocol
draft-ietf-bmwg-ipv6-nd-05 draft-ietf-bmwg-ipv6-nd-06
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 August 28, 2017. This Internet-Draft will expire on September 2, 2017.
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
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 . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.2. Baseline Test Procedure Flow Chart . . . . . . . . . 8
3.2. Scaling Test . . . . . . . . . . . . . . . . . . . . . . 9 3.1.3. Results . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Scaling Test . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. Results . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 10
4. Measurements Explicitly Excluded . . . . . . . . . . . . . . 11 3.2.2. Scaling Test Procedure Flow Chart . . . . . . . . . . 11
4.1. DUT CPU Utilization . . . . . . . . . . . . . . . . . . . 11 3.2.3. Results . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Malformed Packets . . . . . . . . . . . . . . . . . . . . 11 4. Measurements Explicitly Excluded . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4.1. DUT CPU Utilization . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4.2. Malformed Packets . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Normative References . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. Normative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 outbound interface and IPv6 next-hop o Identifies the outbound interface and IPv6 next-hop
o Query a local Neighbor Cache (NC) to determine the IPv6 next-hop's o Queries a local Neighbor Cache (NC) to determine the IPv6 next-
link-layer address hop's link-layer address
o Encapsulate 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 Forward 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 8, line 46 skipping to change at page 8, line 46
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. Results 3.1.2. Baseline Test Procedure Flow Chart
+--------------------------+
| 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 time 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
3.1.3. Results
The log contains initial and final values for the following counters: The log contains initial and final values for the following counters:
o packets-sent o packets-sent
o packets-received o packets-received
The final values of packets-packets sent and packets-received should The initial values of packets-sent and packets-received may be equal
be equal to one another. If they are not, an error has occurred. to one another. If these values are identical, none of the initial
Because this error is likely to affect Scaling Test results, the packets belonging to the flow were lost. However, if the initial
error must be corrected before the Scaling Test is executed. 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 initial values of packets-packets sent and packets-received may The final values of packets-sent and packets-received should be equal
be equal to one another. If these values are identical, none of the to one another. If they are not, an error has occurred. Because
initial packets belonging to the flow were lost. However, if this error is likely to affect Scaling Test results, the error must
packets-sent is greater than packets received, initial packets were be corrected before the Scaling Test is executed.
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:
skipping to change at page 10, line 22 skipping to change at page 11, line 40
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 (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. Results 3.2.2. Scaling Test Procedure Flow Chart
+--------------------------+
| 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----------+
| |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------------+
------------|Restart the test stream|
+-----------------------+
Figure 3: Scaling Test Procedure Flow Chart
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,
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
skipping to change at page 12, line 15 skipping to change at page 15, line 18
7. Acknowledgments 7. Acknowledgments
Helpful comments and suggestions were offered by Al Morton, Joel Helpful comments and suggestions were offered by Al Morton, Joel
Jaeggli, Nalini Elkins, Scott Bradner, and Ram Krishnan, on the BMWG Jaeggli, Nalini Elkins, Scott Bradner, and Ram Krishnan, on the BMWG
e-mail list and at BMWG meetings. Precise grammatical corrections e-mail list and at BMWG meetings. Precise grammatical corrections
and suggestions were offered by Ann Cerveny. and suggestions were offered by Ann Cerveny.
8. Normative References 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, Requirement Levels", BCP 14, RFC 2119, March 1997.
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,
DOI 10.17487/RFC4861, September 2007, 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, Neighbor Discovery Problems", RFC 6583, March 2012.
DOI 10.17487/RFC6583, March 2012,
<http://www.rfc-editor.org/info/rfc6583>.
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 USA
Email: wcerveny@arbor.net Email: wcerveny@arbor.net
 End of changes. 17 change blocks. 
40 lines changed or deleted 186 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/