idnits 2.17.1 draft-manral-ospconv-intraarea-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2001) is 8168 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 527 looks like a reference -- Missing reference section? '2' on line 530 looks like a reference -- Missing reference section? '3' on line 532 looks like a reference -- Missing reference section? '6' on line 540 looks like a reference -- Missing reference section? '4' on line 535 looks like a reference -- Missing reference section? '5' on line 538 looks like a reference -- Missing reference section? 'RFC2328' on line 205 looks like a reference -- Missing reference section? '7' on line 544 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Vishwas Manral 3 Internet Draft Netplane Networks 4 Russ White 5 Expiration Date: June 2002 Cisco Systems 6 File Name: draft-manral-ospconv-intraarea-00.txt December 2001 8 Benchmarking Methodology for Basic OSPF Convergence 9 draft-manral-ospconv-intraarea-00.txt 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its Areas, and its Working Groups. Note that other 18 groups may also distribute working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a "working 24 draft" or "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 2. Abstract 34 This draft establishes standards for measuring OSPF convergence 35 performance. Its initial emphasis is on the control plane of single 36 OSPF routers. We do not address forwarding plane performance. 38 3. Conventions used in this document 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in [1]. 44 4. Motivation 46 There is a growing interest in routing protocol convergence testing, 47 with many people looking at various tests to determine how long it 48 takes for a network to converge after various conditions occur. The 49 major problem with this sort of testing is that the framework of the 50 tests has a major impact on the results; for instance, determining 51 when a network is converged, what parts of the router's operation are 52 considered within the testing, and other such things will have a 53 major impact on what apparent performance routing protocols provide. 55 This document attempts to provide a framework within which Open 56 Shortest Path First (OSPF) [2] performance testing can be placed, and 57 provide some tests with which some aspects of OSPF performance can be 58 measured. The motivation of the draft is to provide a set of tests 59 that can provide the user comparable data from various vendors with 60 which to evaluate the OSPF protocol performance on the devices. 62 5. Overview & Scope 64 While this document describes a specific set of tests aimed at 65 characterizing the convergence performance of OSPF processes in 66 routers or other boxes that incorporate OSPF functionality, a key 67 objective is to propose methodology that will standardize the 68 conducting and reporting of convergence-related measurements. 70 Things which are outside the scope of this document include: 72 o The interactions of convergence and forwarding; testing is 73 restricted to events occuring within the control plane. For- 74 warding performance is the primary focus in [3] and it is 75 expected to be dealt with in work that ensues from [6]. 77 o Inter area routing, AS-external routing, and simultaneous 78 traffic on the control and data paths within the DUT. 80 Other drafts in the future may cover some of the items noted as not 81 covered in the scope of this draft. For a discussion of the terminol- 82 ogy used in this draft (in relation to the tests themselves), refer 83 to [4]. 85 6. Test Conditions 87 In all tests, the following test conditions will be assumed: 89 o The link speed should be high enough so that does not become 90 a bottleneck. Link speeds of 10MBps or higher are recom- 91 mended. The link speed between routers should be specified in 92 the test report. 94 o For all point-to-point links, it is assumed that a link 95 failure results in an immediate notification to the operating 96 system, and thus to the OSPF process; this is explained 97 thoroughly in [5]. 99 o No data traffic will be running between the routers during 100 these tests. 102 o Optional capabilities which can reduce performance, such as 103 authentication, should be noted in the test results if they 104 are enabled. 106 o Optional changes in the default timer values, such as the 107 SPF, hello, dead, and other intervals, should be noted in the 108 test results. 110 o All places where injecting a set of LSAs is referenced, the 111 set can include varying numbers of LSAs of varying types 112 representing a varying number of reachable destinations. See 113 [4] for further information about issues with LSA sets and 114 network topologies. 116 Tests should be run more than once, since a single test run 117 cannot be relied on to produce stistically sound results. The 118 number of test runs and any variations between the tests 119 should be recorded in the test results (see [4] for more 120 information on what items should be recorded in the test 121 results). 123 7. Reference Topologies 125 Several reference topologies will be used throughout the tests 126 described in the remainder of this document. Rather than repeating 127 these topologies, we've gathered them all in one section. 129 o Reference Topology 1 131 ( ) 132 DUT----Generator----( emulated topology ) 133 ( ) 135 A simple back-to-back configuration. It's assumed that the 136 link between the generator and the DUT is a point-to-point 137 link, while the connections withing the generator respresent 138 some emulated topology. 140 o Reference Topology 2 142 ( ) 143 Collector-----DUT-----Generator--( emulated topology ) 144 \ / ( ) 145 \------------/ 147 All routers are connected through point-to-point links. The 148 cost of all links is assumed to be the same unless otherwise 149 noted. 151 o Reference Topology 3 153 DUT R1 R2 154 | | | 155 -+------+------+-----..... 157 Any number of routers could be included on the common broad- 158 cast network. 160 o Reference Topology 4 162 /--(link 1)----- ( ) 163 DUT Generator--( emulated topology ) 164 --(link 2)-----/ ( ) 166 In all cases the tests and topologies are designed to allow perfor- 167 mance measurements to be taken all on a single device, whether the 168 DUT or some other device in the network. This eliminates the need for 169 syncronized clocks within the test networks. 171 8. Basic Process Performance Tests 173 These tests will measure aspects of the OSPF implementation as a pro- 174 cess on the device under test, including: 176 o Time required to process an LSA 178 o Flooding time 180 o Shortest Path First computation 182 8.1. Time required to process an LSA 184 o Using reference topology 1, begin with all links up and a 185 full adjacency established between the DUT and the generator. 187 o Send an LSA that is already there in the DUT (a duplicate 188 LSA), note the time difference between when the LSA is sent 189 to when the ack is received. This measures the time to pro- 190 pagate the LSA and the ack, as well as processing time of the 191 duplicate LSA. This is dupLSAprocTime. 193 o Send a new LSA from the generator to the DUT, followed 194 immediately by a duplicate LSA (LSA that already resides in 195 the database of DUT, but not the same as the one just sent). 197 o The DUT will acknowledge this second LSA immediately; note 198 the time of this acknolwedgement. This is newLSAprocTime. 200 The amount of time required for an OSPF implementation to 201 process the new LSA can be computed by subtracting 202 dupLSAprocTime from newLSAprocTime. 204 Note: The dulpicate LSA cannot be the same as the one just 205 sent because of the MinLSInterval restriction.[RFC2328] This 206 test is taken from [7]. 208 8.2. Flooding Time 210 o Using reference topology 2, enable OSPF on all links and 211 allow the devices to build full adjacencies. Configure the 212 collector so it will block all flooding towards the DUT, 213 although it continues receiving advertisements from the 214 DUT. 216 o Inject a new set of LSAs from the generator towards the 217 generator and the DUT. 219 o On the collector, note the time the flooding is complete 220 across the link to the generator. Also note the time the 221 flooding is complete across the link from the DUT. 223 Two measurements can be taken from this test: 225 o The time between the first LSA is received on the collec- 226 tor from the generator and the time the first LSA is 227 received on the collector from the DUT. 229 o The time between the last LSA is received on the collector 230 from the generator and the time the last LSA is received 231 on the collector from the DUT. 233 Depending on the number of LSAs flooded, the sizes of the 234 LSAs, and the rate of flooding, these numbers could vary by 235 some amount. The settings and variances of these numbers 236 should be reported with the test results. 238 This time is important in link state protocols, since the 239 loop free nature of the network is reliant on the speed at 240 which revised topology information is flooded. 242 8.3. Shortest Path First Computation Time (Internal Test) 244 o Using reference topology 1, establish a full adjacency 245 between the generator and the DUT. 247 o Inject a set of LSAs from the generator towards the DUT. 248 Allow the DUT to stabilize and install all best paths in 249 the routing table, etc. 251 o Change the link cost between the DUT and the generator (or 252 the link between the generator and the emulated network it 253 is advertising), such that a full SPF is required to run, 254 although only one piece of information is changed. 256 o Measure the amount of time required for the DUT to compute 257 new shortest path tree as a result of the topology changes 258 injected by the generator. These measurements should be 259 taken using available show and debug information on the 260 DUT. 262 The test results should note what available commands were 263 used to determine the length of the shortest path first run, 264 and should note any performance implications of monitoring 265 the SPF calculations using information available from the DUT 266 itself. 268 8.4. Shortest Path First Computation Time (External Test) 270 o Use reference topology 1, beginning with the DUT and the 271 generator fully adjacent. 273 o The default SPF timer on the DUT should be set to 0, so 274 that any new LSA that arrives, immediately results in the 275 SPF calculation [7]. 277 o The generator should inject a set of LSAs towards the DUT; 278 the DUT should be allowed to converge and install all best 279 paths in the local routing table, etc.. 281 o Send an LSA that is already there in the DUT (a duplicate 282 LSA), note the time difference between when the LSA is 283 sent to when the ack is received. This measures the time 284 to propagate the LSA and the ack, as well as processing 285 time of the duplicate LSA. This is dupLSAprocTime. 287 o Change the link cost between the generator and the emu- 288 lated network it is advertising. 290 o Immediately inject another LSA which is a duplicate of 291 some other LSA the generator has previously injected 292 (preferrably a stub network someplace within the emulated 293 network). 295 o Measure the time between transmitting the second (dupli- 296 cate) LSA and the acknowledgement for that LSA; this is 297 the totalSPFtime. The total time required to run SPF can 298 be computed by subtracting dupLSAprocTime from totalSPF- 299 time. 301 The accuracy of this test is crucially dependant on the 302 amount of time between the transmission of the first and 303 second LSAs. If there is too much time between them, the test 304 is meaningless because the SPF run will complete before the 305 second (duplicate) LSA is received. If there is too little 306 time between the LSAs being generated, then they will both be 307 handled before the SPF run is scheduled and started, and thus 308 the measurement would only be for the handling of the dupli- 309 cate LSA. 311 This test is taken from [7]. 313 9. Basic Intra-Area OSPF tests 315 These tests measure the performance of an OSPF implementation for 316 basic intra-area tasks, including: 318 o Forming Adjacencies on Point-to-Point Link Initialization 320 o Forming Adjacencies on Point-to-Point Links 322 o Link Up with Information Already in the Database 324 o Initial Convergence Time on a DR electing (broadcast) network 326 o Point-to-point Link Down with Layer 2 Detection 328 o Broadcast Media Link Down with Layer 3 Detection 330 o Designated Router Election Time on A Broadcast Network 332 9.1. Forming Adjacencies on Point-to-Point Link Initialization 334 o Use reference topology 1, beginning with the link between 335 the generator and DUT disabled on the DUT. OSPF should be 336 configured and operating on both devices. 338 o Inject a set of LSAs from the generator towards the DUT. 340 o Bring the link up at the DUT, noting the time that the 341 link carrier is established on the generator. 343 o Note the time the ascknowledgement for the last LSA 344 transmitted from the DUT is received on the generator. 346 The time between the carrier establishement and the ack- 347 nowledgement for the last LSA transmitted by the generator 348 should be taken as the total amount of time required for the 349 OSPF process on the DUT to react to a link up event with the 350 set of LSAs injected, including the time required for the 351 operating system to notify the OSPF process about the link 352 up, etc.. The acknowledgement for the last LSA transmitted is 353 used instead of the last acknowledgement received in order to 354 prevent timing skews due to retransmitted acknowledgements or 355 LSAs. 357 9.2. Forming Adjacencies on Point-to-Point Links 359 o Using reference topology 1, configure the DUT and the gen- 360 erator so traffic can be passed along the link between 361 them. 363 o Configure the generator so OSPF is running on the point- 364 to-point link towards the DUT, and inject a set of LSAs. 366 o Configure the DUT so OSPF is initialized, but not running 367 on the point-to-point link between the DUT and the genera- 368 tor. 370 o Enable OSPF on the interface between the DUT and the gen- 371 erator on the DUT. 373 o Note the time of the first hello received from the DUT on 374 the generator. 376 o Note the time of the acknowledgement from the DUT for the 377 last LSA transmitted on the generator. 379 The time between the first hello received and the ack- 380 nowledgement for the last LSA transmitted by the generator 381 should be taken as the total amount of time required for the 382 OSPF process on the DUT to build a FULL neighbor adjacency 383 with the set of LSAs injected. The acknowledgement for the 384 last LSA transmitted is used instead of the last acknowledge- 385 ment received in order to prevent timing skews due to 386 retransmitted acknowledgements or LSAs. 388 9.3. Link Up with Information Already in the Database 390 o Using reference topology 2, configure all three devices to 391 run OSPF. 393 o Configure the DUT so the link between the DUT and the gen- 394 erator is disabled . 396 o Inject a set of LSAs into the network from the generator; 397 the DUT should receive these LSAs through normal flooding 398 from the collector. 400 o Enable the link between the DUT and the generator. 402 o Note the time of the first hello received from the DUT on 403 the generator. 405 o Note the time of the acknowledgement from the DUT for the 406 last LSA transmitted on the generator. 408 The time between the hello received from the DUT by the gen- 409 erator and the acknowledgement for the last LSA transmitted 410 by the generator should be taken as the total amount of time 411 required for the OSPF process on the DUT to build a FULL 412 neighbor adjacency with the set of LSAs injected. In this 413 test, the DUT is already aware of the entire network topol- 414 ogy, so the time required should only include the processing 415 of each LSA from the generator and transmitting an ack- 416 nowledgement. The acknowledgement for the last LSA transmit- 417 ted is used instead of the last acknowledgement received in 418 order to prevent timing skews due to retransmitted ack- 419 nowledgements or LSAs. 421 9.4. Initial Convergence Time on a DR electing (broadcast) network 423 o Using reference topology 3, begin with the DUT connected 424 to the network wth OSPF enabled. OSPF should be enabled on 425 R1, but the broadcast link should be disabled. 427 o Enable the broadcast link between R1 and the DUT. Note the 428 time of the first hello received by R1. 430 o Note the time the first network LSA is flooded by the DUT 431 at R1. 433 o The differential between the first hello and the first 434 network LSA is the time required by the DUT to converge on 435 this new topology. 437 This test assumes that the DUT will be the designated router 438 on the broadcast link. A similar test could be designed to 439 test the convergence time when the DUT is not the designated 440 router as well. 442 This test may be performed with varying numbers of devices 443 attached to the broadcast network, and varying sets of LSAs 444 being advertised to the DUT from the routers attached to the 445 broadcast network. Variations in the LSA sets and other fac- 446 tors shoul dbe noted in the test results. 448 9.5. Point-to-point Link Down with Layer 2 Detection 450 o Using reference topology 4, begin with OSPF in the full 451 state between the generator and the DUT. Both links should 452 be point-to-point links with the ability to notify the 453 operating system immediately upon link failure. 455 o Disable link 1; this should be done in such a way that the 456 keepalive timers at the data link layer will have no 457 impact on the DUT recognizing the link failure (the 458 operating system in the DUT should recognize this link 459 failure immediately). Disconnecting the cable on the gen- 460 erator end would be one possibility, or shutting the link 461 down. 463 o Note the time of the link failure on the generator. 465 o At the generator, note the time of the receipt of the new 466 router LSA from the DUT notifying the generator of the 467 link 2 failure. 469 The difference in the time between the initial link failure 470 and the receipt of the LSA on the generator across link 2 471 should be taken as the time required for an OSPF implementa- 472 tion to recognize and process a link failure. 474 9.6. Broadcast Media Link Down with Layer 3 Detection 476 o Using reference topology 4, begin with OSPF in the full 477 state between the generator and the DUT. 479 o Disable OSPF processing on link 1 from the generator. This 480 should be done in such a way so it does not affect link 481 status; the DUT must note the failure of the adjacency 482 through the dead interval. 484 o At the generator, note the time of the receipt of the new 485 router LSA from the DUT notifying the generator of the 486 link 2 failure. 488 The difference in the time between the initial link failure 489 and the receipt of the LSA on the generator across link 2 490 should be taken as the time required for an OSPF implementa- 491 tion to recognize and process an adjacency failure. 493 9.7. Designated Router Election Time on A Broadcast Network 495 o Using reference topology 3, configure R1 to be the desig- 496 nated router on the link, and the DUT to be the backup 497 designated router. 499 o Enable OSPF on the common broadcast link on all the 500 routers in the test bed. 502 o Disble the broadcast link on R1. 504 o Note the time of the last hello received from R1 on R2. 506 o Note the time of the first network LSA generated by the 507 DUT as received on R2. 509 The time between the last hello received on R2 and the first 510 network LSA generated by the DUT should be taken as the 511 amount of time required for the DUT to complete a designated 512 router election computation. Note this test includes the dead 513 interval timer at the DUT, so this time can be factored out, 514 or the hello and dead intervals reduced to make these timers 515 impact the overall test times less. All changed timers, the 516 number of routers connected to the link, and other variable 517 factors should be noted in the test results. 519 10. Acknowledgements 521 Thanks to Howard Berkowitz, for his encouragement and support. The 522 authors would also like to thank Aman Shaikh 523 (ashaikh@research.att.com) for his comments and help on this draft. 525 11. References 527 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 528 Levels", RFC2119, March 1997. 530 [2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 532 [3] Bradner, S., McQuaid, J., "Benchmarking Methodology for Network 533 Interconnect Devices", RFC2544, March 1999. 535 [4] Manral, V., "OSPF Convergence Testing Terminiology and Concepts", 536 draft-manral-ospfconv-term-00a. 538 [5] draft-alaettinoglu-isis-convegrence-00. 540 [6] Trotter, G., "Terminology for Forwarding Information Base (FIB) 541 based Router Performance", draft-ietf-bmwg-fib-term-04.txt, 542 October 2001. 544 [7] Shaikh, Aman, Greenberg, Albert, "Experience in Black-Box OSPF 545 measurement" 547 12. Authors' Addresses 549 Vishwas Manral, 550 Netplane Networks, 551 189 Prashasan Nagar, 552 Road number 72, 553 Jubilee Hills, 554 Hyderabad. 556 vmanral@netplane.com 558 Russ White 559 Cisco Systems, Inc. 560 7025 Kit Creek Rd. 561 Research Triangle Park, NC 27709 563 riw@cisco.com