idnits 2.17.1 draft-ietf-bmwg-ipv6-nd-03.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 (September 22, 2016) is 2773 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: March 26, 2017 R. Thomas 6 Juniper Networks 7 September 22, 2016 9 Benchmarking The Neighbor Discovery Protocol 10 draft-ietf-bmwg-ipv6-nd-03 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 March 26, 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 . . . . . . . . . . . . . . . . . . . . . . . 9 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 (i.e., the next IPv6 node that the 92 packet traverses on route to its ultimate destination) 94 o Query a local Neighbor Cache (NC) to determine the IPv6 next-hop's 95 link-layer address 97 o Encapsulate the packet in a link-layer header. The link-layer 98 header includes the IPv6 next-hop's link-layer address 100 o Forward the packet to the IPv6 next-hop 102 IPv6 nodes use the Neighbor Discovery Protocol (NDP) [RFC4861] to 103 maintain the NC. Operational experience [RFC6583] shows that when an 104 implementation cannot maintain a sufficiently complete NC, its 105 ability to forward packets is impaired. 107 NDP, like any other protocol, consumes processing, memory, and 108 bandwidth resources. Its ability to maintain a sufficiently complete 109 NC depends upon the availability of the above-mentioned resources. 111 This document provides benchmarking procedures for NDP. Benchmarking 112 procedures include a Baseline Test and an NDP Scaling Test. In both 113 tests, the Device Under Test (DUT) is an IPv6 router. Two physical 114 links (A and B) connect the DUT to a Tester. The Tester sends 115 traffic through Link A to the DUT. The DUT forwards that traffic, 116 through Link B, back to the Tester. 118 The above-mentioned traffic stream contains one or more interleaved 119 flows. An IPv6 Destination Address uniquely identifies each flow. 120 Or, said another way, every packet within a flow has the same IPv6 121 Destination Address. 123 In the Baseline Test, the traffic stream contains exactly one flow. 124 Because every packet in the stream has the same IPv6 Destination 125 Address, the DUT can forward the entire stream using exactly one NC 126 entry. NDP is exercised minimally and no packet loss should be 127 observed. 129 The NDP Scaling Test is identical to the Baseline Test, except that 130 the traffic stream contains many flows. In order to forward the 131 stream without loss, the DUT must maintain one NC entry for each 132 flow. If the DUT cannot maintain one NC entry for each flow, packet 133 loss will be observed and attributed to NDP scaling limitations. 135 This document proposes an NDP scaling metric, called NDP-MAX- 136 NEIGHBORS. NDP-MAX-NEIGHBORS is the maximum number of neighbors to 137 which an IPv6 node can send traffic during periods of high NDP 138 activity. 140 The procedures described herein reveal how many IPv6 neighbors an NDP 141 implementation can discover. They also provide a rough estimate of 142 the time required to discover those neighbors. However, that 143 estimate does not reflect the maximum rate at which the 144 implementation can discover neighbors. Maximum rate discovery is a 145 topic for further exploration. 147 The test procedures described herein assume that on the DUT, NDP does 148 not compete for resources with other applications. When NDP 149 completes for resources, its scaling characteristics may not be 150 commensurate with those reported by the benchmarks described herein. 152 2. Test Setup 154 +---------------+ +-----------+ 155 | | | | 156 | | Link A | Device | 157 | |------------>| Under | 158 | Tester | | Test | 159 | |<------------| (DUT) | 160 | | Link B | | 161 +---------------+ +-----------+ 163 Figure 1: Test Setup 165 The DUT is an IPv6 router. The DUT is connected to a Tester by two 166 links (A and B). Link A capabilities must be identical to Link B 167 capabilities. For example, if the interface to Link A is a 10 168 Gigabit Ethernet port, the interface to Link B must also be a 10 169 Gigabit Ethernet port. Furthermore, Link A and Link B must be 170 lossless. 172 2.1. Device Under Test (DUT) 174 2.1.1. Interfaces 176 DUT interfaces are numbered as follows: 178 o Link A - 2001:2:0:0::2/64 180 o Link B- 2001:2:0:1::1/64 182 Both DUT interfaces should be configured with a 1500-byte MTU. 183 However, if they cannot support a 1500-byte MTU, they may be 184 configured with a 1280-byte MTU. 186 2.1.2. Neighbor Discovery Protocol (NDP) 188 NDP is enabled on both DUT interfaces. Therefore, the DUT emits both 189 solicited and unsolicited Router Advertisement (RA) messages. The 190 DUT emits an RA message at least once every 600 seconds and no more 191 frequently than once every 200 seconds. 193 When the DUT sends an RA message, it includes the following 194 information: 196 o Router Lifetime - 1800 seconds 198 o Reachable Time - 0 seconds 200 o Retrans Time - 0 seconds 202 o Source Link Layer Address - Link layer address of DUT interface 204 The above-mentioned values are chosen because they are the default 205 values specified in RFC 4861. 207 NDP also manages the NC. Each NC entry represents an on-link 208 neighbor and is identified by the neighbor's on-link unicast IP 209 address. NC entries contain the neighbor's link-layer address, a 210 state variable, and several timers that are used by the Neighbor 211 Unreachability Detection (NUD) algorithm. Section 7.3 of RFC 4861 212 provides NUD details. On the DUT, NUD uses the protocol constants 213 defined in Section 10 of RFC 4861. As per these specifications, each 214 NC entry needs to be refreshed at least every 60 seconds. NDP 215 refreshes NC entries by exchanging Neighbor Solicitation (NS) and 216 Neighbor Advertisement (NA) messages. 218 No static NC entries are configured on the DUT. 220 2.1.3. Routing 222 The DUT maintains a direct route to 2001:2:0:0/64 through Link A. It 223 also maintains a direct route to 2001:2:0:1/64 through Link B. No 224 static routes or dynamic routing protocols are configured on the DUT. 226 2.2. Tester 228 2.2.1. Interfaces 230 Interfaces are numbered as follows: 232 o Link A - 2001:2:0:0::1/64 234 o Link B - Multiple addresses are configured on Link B. These 235 addresses are drawn sequentially from the 2001:2:0:1::/64 address 236 block. The first address is 2001:2:0:1::2/64. Subsequent 237 addresses are 2001:2:0:1::3/64, 2001:2:0:1::4/64, 238 2001:2:0:1::5/64, et cetera. The number of configured addresses 239 should be the expected value of NDP-MAX-NEIGHBORS times 1.1. 241 Both Tester interfaces should be configured with a 1500-byte MTU. 242 However, if they cannot support a 1500-byte MTU, they may be 243 configured with a 1280-byte MTU. 245 2.2.2. Neighbor Discovery Protocol (NDP) 247 NDP is enabled on both Tester interfaces. Therefore, upon 248 initiation, the Tester sends Router Solicitation (RS) messages and 249 waits for Router Advertisement (RA) messages. The Tester also 250 exchanges Neighbor Solicitation (NS) and Neighbor Advertisement (NA) 251 messages with the DUT. 253 No static NC entries are configured on the Tester. 255 2.2.3. Routing 257 The Tester maintains a direct route to 2001:2:0:0/64 through Link A. 258 It also maintains a direct route to 2001:2:0:1/64 through Link B. No 259 static routes or dynamic routing protocols are configured on the 260 Tester. 262 2.2.4. Test Traffic 264 The Tester sends a stream test traffic through Link A to the DUT. 265 The test traffic stream contains one or more interleaved flows. 266 Flows are numbered 1 through N, sequentially. 268 Within each flow, each packet contains an IPv6 header and each IPv6 269 header contains the following information: 271 o Version - 6 273 o Traffic Class - 0 275 o Flow Label - 0 277 o Payload Length - 0 279 o Next Header - IPv6-NoNxt (59) 281 o Hop Limit - 255 283 o Source Address - 2001:2:0:0::1 285 o Destination Address - The first 64 bits of the Destination Address 286 are 2001:2:0:1::. The next 64 are uniquely associated with the 287 flow. Every packet in the first flow carries the Destination 288 address 2001:2:0:1::2. Every subsequent flow has an IP address 289 one greater than the last (i.e., 2001:2:0:1::3, 2001:2:0:1::4, 290 etc.) 292 In order to avoid link congestion, test traffic is offered at a rate 293 not to exceed 50% of available link bandwidth. In order to avoid 294 burstiness and buffer occupancy, every packet in the stream is 295 exactly 40 bytes long (i.e., the length of an IPv6 header with no 296 IPv6 payload). Furthermore, the gap between packets is identical. 298 During the course of a test procedure, the number of flows that the 299 test stream contains may increase. When this occurs, the rate at 300 which test traffic is offered remains constant. For example, assume 301 that a test stream is offered at a rate of 1,000 packets per second. 302 This stream contains two flows, each contributing 500 packets per 303 second to the 1,000 packet per second aggregate. When a third stream 304 is added to the flow, all three streams must contribute 333 packets 305 per second in order to maintain the 1,000 packet per second limit. 306 (As in this example, rounding error is acceptable.) 308 The DUT attempts to forward every packet in the test stream through 309 Link B to the Tester. It does this because: 311 o Every packet in the test stream has a destination address drawn 312 from the 2001:2:0:1::/64 address block 314 o The DUT has a direct route to 2001:2:0:1/64 through Link B 316 2.2.5. Counters 318 For each address configured on the Tester interface to Link B, two 319 counters are configured. One counter, configured on the Tester 320 interface to Link A, increments when the Tester detects an outgoing 321 packet from the associated flow. The other counter, configured on 322 the Tester interface to Link B, increments when the Tester detects an 323 incoming packet from the associated flow. In order for a packet to 324 be associated with a flow, the following conditions must all be true: 326 o The IPv6 Destination Address must be that of the flow 328 o The IPv6 Next Header must be IPv6-NoNxt (59) 330 The following counters also are configured on both Tester Interfaces: 332 o RS packets sent 334 o RS packets received 336 o RA packets sent 337 o RA packets received 339 o NS packets sent 341 o NS packets received 343 o NA packets sent 345 o NA packets received 347 o Total packets sent 349 o Total packets received 351 3. Tests 353 3.1. Baseline Test 355 The purpose of the Baseline Test is to ensure that the DUT can 356 forward every packet in the test stream, wThithout loss, when NDP is 357 minimally exercised and not operating near its scaling limit. 359 3.1.1. Procedure 361 o Reset all counters on the Tester 363 o Clear the NC on the DUT 365 o Set a timer to expire in 60 seconds 367 o Start the test stream with exactly one flow (i.e., IPv6 368 Destination Address equals 2001:2:0:1::2) 370 o Wait for either the timer to expire or the packets-received 371 counter associated with the flow to increment 373 o If the timer expires, stop the test stream and end the test 375 o If the packets-received counter increments, pause the traffic 376 stream, clear the timer, log the counters associated with the 377 flow, clear the counters associated with the flow, reset the timer 378 to expire in 1800 seconds and restart the traffic stream 380 o When the timer expires, stop the test stream, log all counters and 381 end the test 383 3.1.2. Results 385 The two counters associated with the flow (packets-sent and packets- 386 received) must have equal values. If they do not, an error has 387 occurred. Because this error is likely to affect Scaling Test 388 results, the error must be corrected before the Scaling Test is 389 executed. 391 The log contains two counters (packets-sent and packets-received) for 392 the flow. If these values are identical, none of the initial packets 393 belonging to the flow were lost. However, if packets-sent is greater 394 than packets received, initial packets were lost. This loss of 395 initial packets is acceptable. 397 3.2. Scaling Test 399 The purpose of the Scaling Test is to discover the number of 400 neighbors to which an IPv6 node can send traffic during periods of 401 high NDP activity. We call this number NDP-MAX-NEIGHBORS. 403 3.2.1. Procedure 405 Execute the following procedure: 407 o Clear all counters on the Tester 409 o Clear the NC on the DUT 411 o Set a timer to expire in 60 seconds 413 o Start the test stream with exactly one flow (i.e., IPv6 414 Destination Address equals 2001:2:0:1::2) 416 o Wait for either the timer to expire or the packets-received 417 counter associated with the flow to increment 419 o If the timer expires, stop the test stream and end the test 421 o If the packets-received counter increments, proceed as described 422 below: 424 Execute the following procedure N times, starting at 2 and ending at 425 the number of expected value of NDP-MAX-NEIGHBORS time 1.1. 427 o Pause the test stream 429 o Clear the timer 430 o Log the time, the value of N minus one, and the packets-sent and 431 packets-received counters associated with the previous flow (i.e., 432 N minus one) 434 o Clear the packets-sent and packets-received counters associated 435 with the previous flow (i.e., N minus one) 437 o Reset the timer to expire in 60 seconds 439 o Add the next flow to the test stream (i.e.,IPv6 Destination 440 Address is a function of N) 442 o Restart the test stream 444 o Wait for either the timer to expire or the packets-received 445 counter associated with the new flow to increment 447 After the above described procedure had been executed N times, clear 448 the timer and reset it to expire in 1800 seconds. When the timer 449 expires, stop the stream, log all counters and end the test. 451 3.2.2. Results 453 The test report includes the following: 455 o A description of the DUT (make, model, processor, memory, 456 interfaces) 458 o Rate at which the Tester offers test traffic to the DUT (measured 459 in packets per second) 461 o A log that records the time at which each flow was introduced to 462 the test stream 464 o All counter values 466 NDP-MAX-NEIGHBORS is equal to the number of counter pairs where 467 packets-sent is equal to packets-recieved. Two counters are members 468 of a pair if they are both associated with the same IPv6 address. If 469 packets-sent is greater than zero and equal to packets-recieved for 470 every counter pair, the test should be repeated with a larger 471 expected value of NDP-MAX-NEIGHBORS. 473 If an implementation abides by the recommendation of RFC 6583, for 474 any given counter pair, packets-received will either be equal to zero 475 or packets-received. 477 The log documents the time at which each flow was introduced to the 478 test stream. This log reveals the effect of NC size to the time 479 required to discover a new IPv6 neighbor. 481 The log contains two counters (packets-sent and packets-received) for 482 each flow. If these values are identical, none of the initial 483 packets belonging to the flow were lost. However, if packets-sent is 484 greater than packets received, initial packets were lost. This loss 485 of initial packets is acceptable. 487 4. Measurements Explicitly Excluded 489 These are measurements which aren't recommended because of the 490 itemized reasons below: 492 4.1. DUT CPU Utilization 494 This measurement relies on the DUT to provide utilization 495 information, which is subjective. 497 4.2. Malformed Packets 499 This benchmarking test is not intended to test DUT behavior in the 500 presence of malformed packets. 502 5. IANA Considerations 504 This document makes no request of IANA. 506 Note to RFC Editor: this section may be removed on publication as an 507 RFC. 509 6. Security Considerations 511 Benchmarking activities as described in this memo are limited to 512 technology characterization using controlled stimuli in a laboratory 513 environment, with dedicated address space and the constraints 514 specified in the sections above. 516 The benchmarking network topology will be an independent test setup 517 and MUST NOT be connected to devices that may forward the test 518 traffic into a production network, or misroute traffic to the test 519 management network. 521 Further, benchmarking is performed on a "black-box" basis, relying 522 solely on measurements observable external to the DUT/SUT. Special 523 capabilities SHOULD NOT exist in the DUT/SUT specifically for 524 benchmarking purposes. 526 Any implications for network security arising from the DUT/SUT SHOULD 527 be identical in the lab and in production networks. 529 7. Acknowledgements 531 Helpful comments and suggestions were offered by Al Morton, Joel 532 Jaeggli, Nalini Elkins, Scott Bradner, and Ram Krishnan, on the BMWG 533 e-mail list and at BMWG meetings. Precise grammatical corrections 534 and suggestions were offered by Ann Cerveny. 536 8. Normative References 538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", BCP 14, RFC 2119, 540 DOI 10.17487/RFC2119, March 1997, 541 . 543 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 544 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 545 DOI 10.17487/RFC4861, September 2007, 546 . 548 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 549 Neighbor Discovery Problems", RFC 6583, 550 DOI 10.17487/RFC6583, March 2012, 551 . 553 Authors' Addresses 555 Bill Cerveny 556 Arbor Networks 557 2727 South State Street 558 Ann Arbor, MI 48104 559 USA 561 Email: wcerveny@arbor.net 563 Ron Bonica 564 Juniper Networks 565 2251 Corporate Park Drive 566 Herndon, VA 20170 567 USA 569 Email: rbonica@juniper.net 570 Reji Thomas 571 Juniper Networks 572 Elnath-Exora Business Park Survey 573 Bangalore, KA 560103 574 India 576 Email: rejithomas@juniper.net