draft-ietf-bmwg-ipv6-nd-04.txt   draft-ietf-bmwg-ipv6-nd-05.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: May 21, 2017 R. Thomas Expires: August 28, 2017 R. Thomas
Juniper Networks Juniper Networks
November 17, 2016 February 24, 2017
Benchmarking The Neighbor Discovery Protocol Benchmarking The Neighbor Discovery Protocol
draft-ietf-bmwg-ipv6-nd-04 draft-ietf-bmwg-ipv6-nd-05
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 May 21, 2017. This Internet-Draft will expire on August 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
3.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. Results . . . . . . . . . . . . . . . . . . . . . . . 8 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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 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 o Identify the outbound interface and IPv6 next-hop
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 29 skipping to change at page 4, line 29
| |<------------| (DUT) | | |<------------| (DUT) |
| | Link B | | | | Link B | |
+---------------+ +-----------+ +---------------+ +-----------+
Figure 1: Test Setup Figure 1: Test Setup
The DUT is an IPv6 router. Two links (A and B) connect the DUT to 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 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.
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:
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
skipping to change at page 5, line 16 skipping to change at page 5, line 16
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 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
RFC 4861, each NC entry needs to be refreshed periodically. NDP RFC 4861, each NC entry needs to be refreshed periodically. 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.
skipping to change at page 7, line 46 skipping to change at page 7, line 48
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 RS packets received
o RA 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
skipping to change at page 9, line 6 skipping to change at page 9, line 6
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. 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-recieved should The final values of packets-packets sent and packets-received should
be equal to one another. If they are not, an error has occurred. be equal to one another. If they are not, an error has occurred.
Because this error is likely to affect Scaling Test results, the Because this error is likely to affect Scaling Test results, the
error must be corrected before the Scaling Test is executed. error must be corrected before the Scaling Test is executed.
The initial values of packets-packets sent and packets-recieved may The initial values of packets-packets sent and packets-received may
be equal to one another. If these values are identical, none of the be equal to one another. If these values are identical, none of the
initial packets belonging to the flow were lost. However, if initial packets belonging to the flow were lost. However, if
packets-sent is greater than packets received, initial packets were packets-sent is greater than packets received, initial packets were
lost. This loss of initial packets is acceptable. 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.
skipping to change at page 10, line 40 skipping to change at page 10, line 40
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-recieved. 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-recieved 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-received. 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 are measurements which aren't recommended because of the
itemized reasons below: itemized reasons below:
skipping to change at page 12, line 5 skipping to change at page 12, line 5
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/SUT. Special
capabilities SHOULD NOT exist in the DUT/SUT specifically for capabilities SHOULD NOT exist in the DUT/SUT specifically for
benchmarking purposes. 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. Acknowledgements 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,
 End of changes. 15 change blocks. 
18 lines changed or deleted 17 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/