idnits 2.17.1 draft-ietf-bmwg-ipv6-nd-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 9 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 17, 2016) is 2716 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Cerveny 3 Internet-Draft Arbor Networks 4 Intended status: Informational R. Bonica 5 Expires: May 21, 2017 R. Thomas 6 Juniper Networks 7 November 17, 2016 9 Benchmarking The Neighbor Discovery Protocol 10 draft-ietf-bmwg-ipv6-nd-04 12 Abstract 14 This document provides benchmarking procedures for Neighbor Discovery 15 Protocol (NDP). It also proposes metrics by which an NDP 16 implementation's scaling capabilities can be measured. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 21, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Device Under Test (DUT) . . . . . . . . . . . . . . . . . 4 61 2.1.1. Interfaces . . . . . . . . . . . . . . . . . . . . . 4 62 2.1.2. Neighbor Discovery Protocol (NDP) . . . . . . . . . . 4 63 2.1.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. Tester . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2.1. Interfaces . . . . . . . . . . . . . . . . . . . . . 5 66 2.2.2. Neighbor Discovery Protocol (NDP) . . . . . . . . . . 6 67 2.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.2.4. Test Traffic . . . . . . . . . . . . . . . . . . . . 6 69 2.2.5. Counters . . . . . . . . . . . . . . . . . . . . . . 7 70 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.1. Baseline Test . . . . . . . . . . . . . . . . . . . . . . 8 72 3.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 8 73 3.1.2. Results . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.2. Scaling Test . . . . . . . . . . . . . . . . . . . . . . 9 75 3.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 9 76 3.2.2. Results . . . . . . . . . . . . . . . . . . . . . . . 10 77 4. Measurements Explicitly Excluded . . . . . . . . . . . . . . 11 78 4.1. DUT CPU Utilization . . . . . . . . . . . . . . . . . . . 11 79 4.2. Malformed Packets . . . . . . . . . . . . . . . . . . . . 11 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 83 8. Normative References . . . . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 When an IPv6 node forwards a packet, it executes the following 89 procedure: 91 o Identify the IPv6 next-hop 93 o Query a local Neighbor Cache (NC) to determine the IPv6 next-hop's 94 link-layer address 96 o Encapsulate the packet in a link-layer header. The link-layer 97 header includes the IPv6 next-hop's link-layer address 99 o Forward the packet to the IPv6 next-hop 101 IPv6 nodes use the Neighbor Discovery Protocol (NDP) [RFC4861] to 102 maintain the NC. Operational experience [RFC6583] shows that when an 103 implementation cannot maintain a sufficiently complete NC, its 104 ability to forward packets is impaired. 106 NDP, like any other protocol, consumes processing, memory, and 107 bandwidth resources. Its ability to maintain a sufficiently complete 108 NC depends upon the availability of the above-mentioned resources. 110 This document provides benchmarking procedures for NDP. Benchmarking 111 procedures include a Baseline Test and an NDP Scaling Test. In both 112 tests, the Device Under Test (DUT) is an IPv6 router. Two physical 113 links (A and B) connect the DUT to a Tester. The Tester sends 114 traffic through Link A to the DUT. The DUT forwards that traffic, 115 through Link B, back to the Tester. 117 The above-mentioned traffic stream contains one or more interleaved 118 flows. An IPv6 Destination Address uniquely identifies each flow. 119 Or, said another way, every packet within a flow has the same IPv6 120 Destination Address. 122 In the Baseline Test, the traffic stream contains exactly one flow. 123 Because every packet in the stream has the same IPv6 Destination 124 Address, the DUT can forward the entire stream using exactly one NC 125 entry. NDP is exercised minimally and no packet loss should be 126 observed. 128 The NDP Scaling Test is identical to the Baseline Test, except that 129 the traffic stream contains many flows. In order to forward the 130 stream without loss, the DUT must maintain one NC entry for each 131 flow. If the DUT cannot maintain one NC entry for each flow, packet 132 loss will be observed and attributed to NDP scaling limitations. 134 This document proposes an NDP scaling metric, called NDP-MAX- 135 NEIGHBORS. NDP-MAX-NEIGHBORS is the maximum number of neighbors to 136 which an IPv6 node can send traffic during periods of high NDP 137 activity. 139 The procedures described herein reveal how many IPv6 neighbors an NDP 140 implementation can discover. They also provide a rough estimate of 141 the time required to discover those neighbors. However, that 142 estimate does not reflect the maximum rate at which the 143 implementation can discover neighbors. Maximum rate discovery is a 144 topic for further exploration. 146 The test procedures described herein assume that NDP does not compete 147 with other applications for resources on the DUT. When NDP competes 148 for resources, its scaling characteristics may differ from those 149 reported by the benchmarks described, and may vary over time. 151 2. Test Setup 153 +---------------+ +-----------+ 154 | | | | 155 | | Link A | Device | 156 | |------------>| Under | 157 | Tester | | Test | 158 | |<------------| (DUT) | 159 | | Link B | | 160 +---------------+ +-----------+ 162 Figure 1: Test Setup 164 The DUT is an IPv6 router. Two links (A and B) connect the DUT to 165 the Tester. Link A capabilities must be identical to Link B 166 capabilities. For example, if the interface to Link A is a 10 167 Gigabit Ethernet port, the interface to Link B must also be a 10 168 Gigabit Ethernet port. Furthermore, Link A and Link B must be 169 lossless. 171 2.1. Device Under Test (DUT) 173 2.1.1. Interfaces 175 DUT interfaces are numbered as follows: 177 o Link A - 2001:2:0:0::2/64 179 o Link B- 2001:2:0:1::1/64 181 Both DUT interfaces should be configured with a 1500-byte MTU. 182 However, if they cannot support a 1500-byte MTU, they may be 183 configured with a 1280-byte MTU. 185 2.1.2. Neighbor Discovery Protocol (NDP) 187 NDP is enabled on both DUT interfaces. Therefore, the DUT emits both 188 solicited and unsolicited Router Advertisement (RA) messages. The 189 DUT emits an RA message at least once every 600 seconds and no more 190 frequently than once every 200 seconds. 192 When the DUT sends an RA message, it includes the following 193 information: 195 o Router Lifetime - 1800 seconds 197 o Reachable Time - 0 seconds 199 o Retrans Time - 0 seconds 201 o Source Link Layer Address - Link layer address of DUT interface 203 The above-mentioned values are chosen because they are the default 204 values specified in RFC 4861. 206 NDP manages the NC. Each NC entry represents an on-link neighbor and 207 is identified by the neighbor's on-link unicast IP address. As per 208 RFC 4861, each NC entry needs to be refreshed periodically. NDP 209 refreshes NC entries by exchanging Neighbor Solicitation (NS) and 210 Neighbor Advertisement (NA) messages. 212 No static NC entries are configured on the DUT. 214 2.1.3. Routing 216 The DUT maintains a direct route to 2001:2:0:0/64 through Link A. It 217 also maintains a direct route to 2001:2:0:1/64 through Link B. No 218 static routes or dynamic routing protocols are configured on the DUT. 220 2.2. Tester 222 2.2.1. Interfaces 224 Interfaces are numbered as follows: 226 o Link A - 2001:2:0:0::1/64 228 o Link B - Multiple addresses are configured on Link B. These 229 addresses are drawn sequentially from the 2001:2:0:1::/64 address 230 block. The first address is 2001:2:0:1::2/64. Subsequent 231 addresses are 2001:2:0:1::3/64, 2001:2:0:1::4/64, 232 2001:2:0:1::5/64, et cetera. The number of configured addresses 233 should be the expected value of NDP-MAX-NEIGHBORS times 1.1. 235 Both Tester interfaces should be configured with a 1500-byte MTU. 236 However, if they cannot support a 1500-byte MTU, they may be 237 configured with a 1280-byte MTU. 239 2.2.2. Neighbor Discovery Protocol (NDP) 241 NDP is enabled on both Tester interfaces. Therefore, upon 242 initiation, the Tester sends Router Solicitation (RS) messages and 243 waits for Router Advertisement (RA) messages. The Tester also 244 exchanges Neighbor Solicitation (NS) and Neighbor Advertisement (NA) 245 messages with the DUT. 247 No static NC entries are configured on the Tester. 249 2.2.3. Routing 251 The Tester maintains a direct route to 2001:2:0:0/64 through Link A. 252 It also maintains a direct route to 2001:2:0:1/64 through Link B. No 253 static routes or dynamic routing protocols are configured on the 254 Tester. 256 2.2.4. Test Traffic 258 The Tester sends a stream of test traffic through Link A to the DUT. 259 The test traffic stream contains one or more interleaved flows. 260 Flows are numbered 1 through N, sequentially. 262 Within each flow, each packet contains an IPv6 header and each IPv6 263 header contains the following information: 265 o Version - 6 267 o Traffic Class - 0 269 o Flow Label - 0 271 o Payload Length - 0 273 o Next Header - IPv6-NoNxt (59) 275 o Hop Limit - 255 277 o Source Address - 2001:2:0:0::1 279 o Destination Address - The first 64 bits of the Destination Address 280 are 2001:2:0:1::. The next 64 are uniquely associated with the 281 flow. Every packet in the first flow carries the Destination 282 address 2001:2:0:1::2. Every subsequent flow has an IP address 283 one greater than the last (i.e., 2001:2:0:1::3, 2001:2:0:1::4, 284 etc.) 286 In order to avoid link congestion, test traffic is offered at a rate 287 not to exceed 50% of available link bandwidth. In order to avoid 288 burstiness and buffer occupancy, every packet in the stream is 289 exactly 40 bytes long (i.e., the length of an IPv6 header with no 290 IPv6 payload). Furthermore, the gap between packets is identical. 292 During the course of a test, the number of flows that the test stream 293 contains may increase. When this occurs, the rate at which test 294 traffic is offered remains constant. For example, assume that a test 295 stream is offered at a rate of 1,000 packets per second. This stream 296 contains two flows, each contributing 500 packets per second to the 297 1,000 packet per second aggregate. When a third stream is added to 298 the flow, all three streams must contribute 333 packets per second in 299 order to maintain the 1,000 packet per second limit. (As in this 300 example, rounding error is acceptable.) 302 The DUT attempts to forward every packet in the test stream through 303 Link B to the Tester. It does this because: 305 o Every packet in the test stream has a destination address drawn 306 from the 2001:2:0:1::/64 address block 308 o The DUT has a direct route to 2001:2:0:1/64 through Link B 310 2.2.5. Counters 312 On the Tester, two counters are configured for each flow. One 313 counter, configured on Link A, increments when the Tester sends a 314 packet belonging to the flow. The other counter, configured on Link 315 B, increments when the Tester receives packet from the flow. In 316 order for a packet to be associated with a flow, the following 317 conditions must all be true: 319 o The IPv6 Destination Address must be that of the flow 321 o The IPv6 Next Header must be IPv6-NoNxt (59) 323 The following counters also are configured on both Tester Interfaces: 325 o RS packets sent 327 o RS packets received 329 o RA packets sent 331 o RA packets received 333 o NS packets sent 334 o NS packets received 336 o NA packets sent 338 o NA packets received 340 o Total packets sent 342 o Total packets received 344 3. Tests 346 3.1. Baseline Test 348 The purpose of the Baseline Test is to ensure that the DUT can 349 forward every packet in the test stream, without loss, when NDP is 350 minimally exercised and not operating near its scaling limit. 352 3.1.1. Procedure 354 o On the DUT, clear the NC 356 o On the Tester, clear all counters 358 o On the Tester, set a timer to expire in 60 seconds 360 o On the Tester, start the test stream with exactly one flow (i.e., 361 IPv6 Destination Address equals 2001:2:0:1::2) 363 o Wait for either the timer to expire or the packets-received 364 counter associated with the flow to increment 366 o If the timer expires, stop the test stream and end the test 368 o If the packets-received counter increments, pause the traffic 369 stream, log the initial counter values, clear the counters, reset 370 the timer to expire in 1800 seconds and restart the traffic stream 372 o When the timer expires, stop the test stream, wait sufficient time 373 for any queued packets to exit, log the final counter values and 374 end the test 376 3.1.2. Results 378 The log contains initial and final values for the following counters: 380 o packets-sent 381 o packets-received 383 The final values of packets-packets sent and packets-recieved should 384 be equal to one another. If they are not, an error has occurred. 385 Because this error is likely to affect Scaling Test results, the 386 error must be corrected before the Scaling Test is executed. 388 The initial values of packets-packets sent and packets-recieved may 389 be equal to one another. If these values are identical, none of the 390 initial packets belonging to the flow were lost. However, if 391 packets-sent is greater than packets received, initial packets were 392 lost. This loss of initial packets is acceptable. 394 3.2. Scaling Test 396 The purpose of the Scaling Test is to discover the number of 397 neighbors to which an IPv6 node can send traffic during periods of 398 high NDP activity. We call this number NDP-MAX-NEIGHBORS. 400 3.2.1. Procedure 402 Execute the following procedure: 404 o On the DUT, clear the NC 406 o On the Tester, clear all counters 408 o On the Tester, set a timer to expire in 60 seconds 410 o On the Tester, start the test stream with exactly one flow (i.e., 411 IPv6 Destination Address equals 2001:2:0:1::2) 413 o Wait for either the timer to expire or the packets-received 414 counter associated with the flow to increment 416 o If the timer expires, stop the test stream and end the test 418 o If the packets-received counter increments, proceed as described 419 below: 421 Execute the following procedure N times, starting at 2 and ending at 422 the number of expected value of NDP-MAX-NEIGHBORS times 1.1. 424 o Pause the test stream 426 o Log the time and the value of N minus one 427 o Clear the packets-sent and packets-received counters associated 428 with the previous flow (i.e., N minus one) 430 o Reset the timer to expire in 60 seconds 432 o Add the next flow to the test stream (i.e.,IPv6 Destination 433 Address is a function of N) 435 o Restart the test stream 437 o Wait for either the timer to expire or the packets-received 438 counter associated with the new flow to increment 440 After the above described procedure had been executed N times, clear 441 the timer and reset it to expire in 1800 seconds. When the timer 442 expires, stop the stream, log all counters and end the test (after 443 waiting sufficient time for any queued packets to exit). 445 3.2.2. Results 447 The test report includes the following: 449 o A description of the DUT (make, model, processor, memory, 450 interfaces) 452 o Rate at which the Tester offers test traffic to the DUT (measured 453 in packets per second) 455 o A log that records the time at which each flow was introduced to 456 the test stream and the final value of all counters 458 o The expected value of NDP-MAX-NEIGHBORS 460 o The actual value of NDP-MAX-NEIGHBORS 462 NDP-MAX-NEIGHBORS is equal to the number of counter pairs where 463 packets-sent is equal to packets-recieved. Two counters are members 464 of a pair if they are both associated with the same flow. If 465 packets-sent is equal to packets-recieved for every counter pair, the 466 test should be repeated with a larger expected value of NDP-MAX- 467 NEIGHBORS. 469 If an implementation abides by the recommendation of Section 7.1 of 470 RFC 6583, for any given counter pair, packets-received will either be 471 equal to zero or packets-received. 473 The log documents the time at which each flow was introduced to the 474 test stream. This log reveals the effect of NC size to the time 475 required to discover a new IPv6 neighbor. 477 4. Measurements Explicitly Excluded 479 These are measurements which aren't recommended because of the 480 itemized reasons below: 482 4.1. DUT CPU Utilization 484 This measurement relies on the DUT to provide utilization 485 information, which is not externally observable (not black-box). 486 However, some testing organizations may find the CPU utilization is 487 useful auxiliary information specific to the DUT model, etc. 489 4.2. Malformed Packets 491 This benchmarking test is not intended to test DUT behavior in the 492 presence of malformed packets. 494 5. IANA Considerations 496 This document makes no request of IANA. 498 Note to RFC Editor: this section may be removed on publication as an 499 RFC. 501 6. Security Considerations 503 Benchmarking activities as described in this memo are limited to 504 technology characterization using controlled stimuli in a laboratory 505 environment, with dedicated address space and the constraints 506 specified in the sections above. 508 The benchmarking network topology will be an independent test setup 509 and MUST NOT be connected to devices that may forward the test 510 traffic into a production network, or misroute traffic to the test 511 management network. 513 Further, benchmarking is performed on a "black-box" basis, relying 514 solely on measurements observable external to the DUT/SUT. Special 515 capabilities SHOULD NOT exist in the DUT/SUT specifically for 516 benchmarking purposes. 518 Any implications for network security arising from the DUT/SUT SHOULD 519 be identical in the lab and in production networks. 521 7. Acknowledgements 523 Helpful comments and suggestions were offered by Al Morton, Joel 524 Jaeggli, Nalini Elkins, Scott Bradner, and Ram Krishnan, on the BMWG 525 e-mail list and at BMWG meetings. Precise grammatical corrections 526 and suggestions were offered by Ann Cerveny. 528 8. Normative References 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, 532 DOI 10.17487/RFC2119, March 1997, 533 . 535 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 536 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 537 DOI 10.17487/RFC4861, September 2007, 538 . 540 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 541 Neighbor Discovery Problems", RFC 6583, 542 DOI 10.17487/RFC6583, March 2012, 543 . 545 Authors' Addresses 547 Bill Cerveny 548 Arbor Networks 549 2727 South State Street 550 Ann Arbor, MI 48104 551 USA 553 Email: wcerveny@arbor.net 555 Ron Bonica 556 Juniper Networks 557 2251 Corporate Park Drive 558 Herndon, VA 20170 559 USA 561 Email: rbonica@juniper.net 562 Reji Thomas 563 Juniper Networks 564 Elnath-Exora Business Park Survey 565 Bangalore, KA 560103 566 India 568 Email: rejithomas@juniper.net