Network Working Group                                         W. Cerveny
Internet-Draft                                            Arbor Networks
Intended status: Informational                                 R. Bonica
Expires: August 28, 2017                                       R. Thomas
                                                        Juniper Networks
                                                       February 24, 2017


              Benchmarking The Neighbor Discovery Protocol
                       draft-ietf-bmwg-ipv6-nd-05

Abstract

   This document provides benchmarking procedures for Neighbor Discovery
   Protocol (NDP).  It also proposes metrics by which an NDP
   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

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 28, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Cerveny, et al.          Expires August 28, 2017                [Page 1]


Internet-Draft              NDP Benchmarking               February 2017


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Test Setup  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Device Under Test (DUT) . . . . . . . . . . . . . . . . .   4
       2.1.1.  Interfaces  . . . . . . . . . . . . . . . . . . . . .   4
       2.1.2.  Neighbor Discovery Protocol (NDP) . . . . . . . . . .   4
       2.1.3.  Routing . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Tester  . . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.2.1.  Interfaces  . . . . . . . . . . . . . . . . . . . . .   5
       2.2.2.  Neighbor Discovery Protocol (NDP) . . . . . . . . . .   6
       2.2.3.  Routing . . . . . . . . . . . . . . . . . . . . . . .   6
       2.2.4.  Test Traffic  . . . . . . . . . . . . . . . . . . . .   6
       2.2.5.  Counters  . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Baseline Test . . . . . . . . . . . . . . . . . . . . . .   8
       3.1.1.  Procedure . . . . . . . . . . . . . . . . . . . . . .   8
       3.1.2.  Results . . . . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Scaling Test  . . . . . . . . . . . . . . . . . . . . . .   9
       3.2.1.  Procedure . . . . . . . . . . . . . . . . . . . . . .   9
       3.2.2.  Results . . . . . . . . . . . . . . . . . . . . . . .  10
   4.  Measurements Explicitly Excluded  . . . . . . . . . . . . . .  11
     4.1.  DUT CPU Utilization . . . . . . . . . . . . . . . . . . .  11
     4.2.  Malformed Packets . . . . . . . . . . . . . . . . . . . .  11
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   When an IPv6 node forwards a packet, it executes the following
   procedure:

   o  Identify the outbound interface and IPv6 next-hop

   o  Query a local Neighbor Cache (NC) to determine the IPv6 next-hop's
      link-layer address





Cerveny, et al.          Expires August 28, 2017                [Page 2]


Internet-Draft              NDP Benchmarking               February 2017


   o  Encapsulate the packet in a link-layer header.  The link-layer
      header includes the IPv6 next-hop's link-layer address

   o  Forward the packet to the IPv6 next-hop

   IPv6 nodes use the Neighbor Discovery Protocol (NDP) [RFC4861] to
   maintain the NC.  Operational experience [RFC6583] shows that when an
   implementation cannot maintain a sufficiently complete NC, its
   ability to forward packets is impaired.

   NDP, like any other protocol, consumes processing, memory, and
   bandwidth resources.  Its ability to maintain a sufficiently complete
   NC depends upon the availability of the above-mentioned resources.

   This document provides benchmarking procedures for NDP.  Benchmarking
   procedures include a Baseline Test and an NDP Scaling Test.  In both
   tests, the Device Under Test (DUT) is an IPv6 router.  Two physical
   links (A and B) connect the DUT to a Tester.  The Tester sends
   traffic through Link A to the DUT.  The DUT forwards that traffic,
   through Link B, back to the Tester.

   The above-mentioned traffic stream contains one or more interleaved
   flows.  An IPv6 Destination Address uniquely identifies each flow.
   Or, said another way, every packet within a flow has the same IPv6
   Destination Address.

   In the Baseline Test, the traffic stream contains exactly one flow.
   Because every packet in the stream has the same IPv6 Destination
   Address, the DUT can forward the entire stream using exactly one NC
   entry.  NDP is exercised minimally and no packet loss should be
   observed.

   The NDP Scaling Test is identical to the Baseline Test, except that
   the traffic stream contains many flows.  In order to forward the
   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
   loss will be observed and attributed to NDP scaling limitations.

   This document proposes an NDP scaling metric, called NDP-MAX-
   NEIGHBORS.  NDP-MAX-NEIGHBORS is the maximum number of neighbors to
   which an IPv6 node can send traffic during periods of high NDP
   activity.

   The procedures described herein reveal how many IPv6 neighbors an NDP
   implementation can discover.  They also provide a rough estimate of
   the time required to discover those neighbors.  However, that
   estimate does not reflect the maximum rate at which the




Cerveny, et al.          Expires August 28, 2017                [Page 3]


Internet-Draft              NDP Benchmarking               February 2017


   implementation can discover neighbors.  Maximum rate discovery is a
   topic for further exploration.

   The test procedures described herein assume that NDP does not compete
   with other applications for resources on the DUT.  When NDP competes
   for resources, its scaling characteristics may differ from those
   reported by the benchmarks described, and may vary over time.

2.  Test Setup

                +---------------+             +-----------+
                |               |             |           |
                |               |   Link A    |   Device  |
                |               |------------>|   Under   |
                |    Tester     |             |   Test    |
                |               |<------------|   (DUT)   |
                |               |   Link B    |           |
                +---------------+             +-----------+

                           Figure 1: Test Setup

   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
   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.

2.1.  Device Under Test (DUT)

2.1.1.  Interfaces

   DUT interfaces are numbered as follows:

   o  Link A - 2001:2:0:0::2/64

   o  Link B- 2001:2:0:1::1/64

   Both DUT interfaces should be configured with a 1500-byte MTU.
   However, if they cannot support a 1500-byte MTU, they may be
   configured with a 1280-byte MTU.

2.1.2.  Neighbor Discovery Protocol (NDP)

   NDP is enabled on both DUT interfaces.  Therefore, the DUT emits both
   solicited and unsolicited Router Advertisement (RA) messages.  The
   DUT emits an RA message at least once every 600 seconds and no more
   frequently than once every 200 seconds.




Cerveny, et al.          Expires August 28, 2017                [Page 4]


Internet-Draft              NDP Benchmarking               February 2017


   When the DUT sends an RA message, it includes the following
   information:

   o  Router Lifetime - 1800 seconds

   o  Reachable Time - 0 seconds

   o  Retrans Time - 0 seconds

   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
   values specified in RFC 4861.

   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
   RFC 4861, each NC entry needs to be refreshed periodically.  NDP
   refreshes NC entries by exchanging Neighbor Solicitation (NS) and
   Neighbor Advertisement (NA) messages.

   No static NC entries are configured on the DUT.

2.1.3.  Routing

   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
   static routes or dynamic routing protocols are configured on the DUT.

2.2.  Tester

2.2.1.  Interfaces

   Interfaces are numbered as follows:

   o  Link A - 2001:2:0:0::1/64

   o  Link B - Multiple addresses are configured on Link B.  These
      addresses are drawn sequentially from the 2001:2:0:1::/64 address
      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,
      2001:2:0:1::5/64, et cetera.  The number of configured addresses
      should be the expected value of NDP-MAX-NEIGHBORS times 1.1.





Cerveny, et al.          Expires August 28, 2017                [Page 5]


Internet-Draft              NDP Benchmarking               February 2017


   Both Tester interfaces should be configured with a 1500-byte MTU.
   However, if they cannot support a 1500-byte MTU, they may be
   configured with a 1280-byte MTU.

2.2.2.  Neighbor Discovery Protocol (NDP)

   NDP is enabled on both Tester interfaces.  Therefore, upon
   initiation, the Tester sends Router Solicitation (RS) messages and
   waits for Router Advertisement (RA) messages.  The Tester also
   exchanges Neighbor Solicitation (NS) and Neighbor Advertisement (NA)
   messages with the DUT.

   No static NC entries are configured on the Tester.

2.2.3.  Routing

   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
   static routes or dynamic routing protocols are configured on the
   Tester.

2.2.4.  Test Traffic

   The Tester sends a stream of test traffic through Link A to the DUT.
   The test traffic stream contains one or more interleaved flows.
   Flows are numbered 1 through N, sequentially.

   Within each flow, each packet contains an IPv6 header and each IPv6
   header contains the following information:

   o  Version - 6

   o  Traffic Class - 0

   o  Flow Label - 0

   o  Payload Length - 0

   o  Next Header - IPv6-NoNxt (59)

   o  Hop Limit - 255

   o  Source Address - 2001:2:0:0::1

   o  Destination Address - The first 64 bits of the Destination Address
      are 2001:2:0:1::. The next 64 are uniquely associated with the
      flow.  Every packet in the first flow carries the Destination
      address 2001:2:0:1::2.  Every subsequent flow has an IP address



Cerveny, et al.          Expires August 28, 2017                [Page 6]


Internet-Draft              NDP Benchmarking               February 2017


      one greater than the last (i.e., 2001:2:0:1::3, 2001:2:0:1::4,
      etc.)

   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
   burstiness and buffer occupancy, every packet in the stream is
   exactly 40 bytes long (i.e., the length of an IPv6 header with no
   IPv6 payload).  Furthermore, the gap between packets is identical.

   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
   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
   contains two flows, each contributing 500 packets per second to the
   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
   order to maintain the 1,000 packet per second limit.  (As in this
   example, rounding error is acceptable.)

   The DUT attempts to forward every packet in the test stream through
   Link B to the Tester.  It does this because:

   o  Every packet in the test stream has a destination address drawn
      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

2.2.5.  Counters

   On the Tester, two counters are configured for each flow.  One
   counter, configured on Link A, increments when the Tester sends a
   packet belonging to the flow.  The other counter, configured on Link
   B, increments when the Tester receives packet from the flow.  In
   order for a packet to 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 Next Header must be IPv6-NoNxt (59)

   The following counters also are configured on both Tester Interfaces:

   o  RS packets sent

   o  RA packets received

   o  NS packets sent




Cerveny, et al.          Expires August 28, 2017                [Page 7]


Internet-Draft              NDP Benchmarking               February 2017


   o  NS packets received

   o  NA packets sent

   o  NA packets received

   o  Total packets sent

   o  Total packets received

3.  Tests

3.1.  Baseline Test

   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
   minimally exercised and not operating near its scaling limit.

3.1.1.  Procedure

   o  On the DUT, clear the NC

   o  On the Tester, clear all counters

   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.,
      IPv6 Destination Address equals 2001:2:0:1::2)

   o  Wait for either the timer to expire or the packets-received
      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, pause the traffic
      stream, log the initial counter values, clear the counters, reset
      the timer to expire in 1800 seconds and restart the traffic stream

   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

3.1.2.  Results

   The log contains initial and final values for the following counters:

   o  packets-sent




Cerveny, et al.          Expires August 28, 2017                [Page 8]


Internet-Draft              NDP Benchmarking               February 2017


   o  packets-received

   The final values of packets-packets sent and packets-received should
   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-received 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

   The purpose of the Scaling Test is to discover the number of
   neighbors to which an IPv6 node can send traffic during periods of
   high NDP activity.  We call this number NDP-MAX-NEIGHBORS.

3.2.1.  Procedure

   Execute the following procedure:

   o  On the DUT, clear the NC

   o  On the Tester, clear all counters

   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.,
      IPv6 Destination Address equals 2001:2:0:1::2)

   o  Wait for either the timer to expire or the packets-received
      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
      below:

   Execute the following procedure N times, starting at 2 and ending at
   the number of expected value of NDP-MAX-NEIGHBORS times 1.1.

   o  Pause the test stream

   o  Log the time and the value of N minus one





Cerveny, et al.          Expires August 28, 2017                [Page 9]


Internet-Draft              NDP Benchmarking               February 2017


   o  Clear the packets-sent and packets-received counters associated
      with the previous flow (i.e., N minus one)

   o  Reset the timer to expire in 60 seconds

   o  Add the next flow to the test stream (i.e.,IPv6 Destination
      Address is a function of N)

   o  Restart the test stream

   o  Wait for either the timer to expire or the packets-received
      counter associated with the new flow to increment

   After the above described procedure had been executed N times, clear
   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
   waiting sufficient time for any queued packets to exit).

3.2.2.  Results

   The test report includes the following:

   o  A description of the DUT (make, model, processor, memory,
      interfaces)

   o  Rate at which the Tester offers test traffic to the DUT (measured
      in packets per second)

   o  A log that records the time at which each flow was introduced to
      the test stream and the final value of all counters

   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
   packets-sent is equal to packets-received.  Two counters are members
   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
   test should be repeated with a larger expected value of NDP-MAX-
   NEIGHBORS.

   If an implementation abides by the recommendation of Section 7.1 of
   RFC 6583, for any given counter pair, packets-received will either be
   equal to zero or packets-sent.






Cerveny, et al.          Expires August 28, 2017               [Page 10]


Internet-Draft              NDP Benchmarking               February 2017


   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
   required to discover a new IPv6 neighbor.

4.  Measurements Explicitly Excluded

   These are measurements which aren't recommended because of the
   itemized reasons below:

4.1.  DUT CPU Utilization

   This measurement relies on the DUT to provide utilization
   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

   This benchmarking test is not intended to test DUT behavior in the
   presence of malformed packets.

5.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

6.  Security Considerations

   Benchmarking activities as described in this memo are limited to
   technology characterization using controlled stimuli in a laboratory
   environment, with dedicated address space and the constraints
   specified in the sections above.

   The benchmarking network topology will be an independent test setup
   and MUST NOT be connected to devices that may forward the test
   traffic into a production network, or misroute traffic to the test
   management network.

   Further, benchmarking is performed on a "black-box" basis, relying
   solely on measurements observable external to the DUT/SUT.  Special
   capabilities SHOULD NOT exist in the DUT/SUT specifically for
   benchmarking purposes.

   Any implications for network security arising from the DUT/SUT SHOULD
   be identical in the lab and in production networks.




Cerveny, et al.          Expires August 28, 2017               [Page 11]


Internet-Draft              NDP Benchmarking               February 2017


7.  Acknowledgments

   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
              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,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <http://www.rfc-editor.org/info/rfc4861>.

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

Authors' Addresses

   Bill Cerveny
   Arbor Networks
   2727 South State Street
   Ann Arbor, MI  48104
   USA

   Email: wcerveny@arbor.net


   Ron Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, VA  20170
   USA

   Email: rbonica@juniper.net









Cerveny, et al.          Expires August 28, 2017               [Page 12]


Internet-Draft              NDP Benchmarking               February 2017


   Reji Thomas
   Juniper Networks
   Elnath-Exora Business Park Survey
   Bangalore, KA  560103
   India

   Email: rejithomas@juniper.net












































Cerveny, et al.          Expires August 28, 2017               [Page 13]