idnits 2.17.1 draft-kou-ospf-immediately-replying-hello-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 784. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 768. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 774. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 153: '...the neighbor, it SHOULD send a Hello P...' RFC 2119 keyword, line 159: '... it SHOULD immediately send Hello Pa...' RFC 2119 keyword, line 163: '... SHOULD send Hello Packet immediatel...' RFC 2119 keyword, line 246: '... eligible. It SHOULD also send an He...' RFC 2119 keyword, line 266: '...ce state changes SHOULD send hello pac...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 41 has weird spacing: '...ate and exped...' == Line 109 has weird spacing: '...ecovery tim...' == Line 111 has weird spacing: '...he time to ...' == Line 112 has weird spacing: '...ng time and...' == Line 115 has weird spacing: '...s to be syn...' == (8 more instances...) -- 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 (January 18, 2007) is 6308 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) No issues found here. Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 OSPF Working Group Zengjie Kou 2 Internet Draft Feng Yang 3 Expires: August 2007 Huaiyuan Ma 4 January 18, 2007 6 Update to OSPF Hello procedure 7 draft-kou-ospf-immediately-replying-hello-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "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 This Internet-Draft will expire on August 18, 2007. 34 Abstract 36 This memo documents an extension of the OSPF protocol to reach 37 "ExStart" state more quickly. Currently, the OSPF behavior requires 38 the Hello Packet to be sent between the neighbors every 39 HelloInterval. This document proposes to generalize the use of 40 Immediately Replying Hello which could reduce the time required to 41 reach the OSPF "ExStart" state and expedite the routing table 42 convergence. 44 Table of Contents 46 1. Introduction................................................2 47 2. Motivation..................................................3 48 3. Potential Solution..........................................4 49 4. Proposed Solution: Immediately Replying Hello...............4 50 5. Immediately Replying Hello..................................4 51 6. Interoperation..............................................5 52 6.1. Compatibility with [OSPFV2]............................5 53 6.2. Interoperation within Immediately Replying Hello.......5 54 7. Description of the Revised protocol behavior................5 55 7.1. Modifications to Sending Hello packets.................5 56 7.1.1. Modification to section 9.5 of [OSPFV2]...........6 57 7.1.2. Modification to section 9.5.1 of [OSPFV2].........7 58 7.2. Modifications to Electing the Designated Router........7 59 7.3. Modifications To The Neighbor State Machine............7 60 8. Benefit.....................................................9 61 9. Security Considerations.....................................9 62 10. Acknowledgments............................................9 63 APPENDIX A: Immediately Replying Hello Experiment Report.......10 64 A.1. Broadcast networks.....................................10 65 A.1.1. No BDR on Broadcast networks......................10 66 A.1.1.1. DUT is DR....................................11 67 A.1.1.2. DUT is DROther...............................12 68 A.1.2. BDR Exists on Broadcast...........................13 69 A.1.2.1. DUT is DR....................................14 70 A.1.2.2. DUT is BDR...................................15 71 A.1.2.3. DUT is DROther...............................16 72 A.1.3. N routers (n>=2) Exist on Broadcast Ethernet......18 73 A.2. Point to Point networks................................18 74 11. References.................................................19 75 11.1. Normative References..................................19 76 11.2. Informative References................................19 77 Author's Addresses.............................................20 78 Intellectual Property Statement................................20 79 Disclaimer of Validity.........................................20 80 Copyright Statement............................................21 81 Acknowledgment.................................................21 83 1. Introduction 85 Currently, the time for OSPF routers to reach the "ExStart" state 86 depends on the OSPF HelloInterval. To reach the "ExStart" state as 87 soon as possible, one of approach is to shorten HelloInterval. 88 This document specifies another method that can be applied to 89 significantly reduce the time to reach the "ExStart" state. With 90 this method, a router will immediately reply a Hello Packet to its 91 peer when receiving a neighbor's Hello Packet. The "ExStart" state 92 and mechanism of OSPF Hello is described in [OSPFV2]. 94 2. Motivation 96 According to [Pierre Franc's paper], the IGP convergence can be 97 characterized as D + O + F + SPT + RIB + DD where D is the link 98 failure detection time, O is the time to originate the LSA describing 99 the new topology after the link failure, F is the complete flooding 100 time from the node detecting the failure (i.e. Failure node) to the 101 rerouting nodes that must perform a FIB update to bring the network 102 in a consistent forwarding state, SPT is the shortest-path tree 103 computation time, RIB is the time to update the RIB and the FIB on 104 the main CPU and DD is the time to distribute the FIB updates to the 105 linecards in the case of a distributed router architecture. 107 The F can be considered as the time of neighbor recovery when a 108 failed OSPF link is recovered (e.g. Interface down/up). In OSPF, the 109 recovery time is equal to the sum of the time to reach the 110 "ExStart" state and LSDB synchronization time. on broadcast and 111 NBMA networks, the time to reach the "ExStart" state is 112 approximate equal to the Waiting time and, on P2P, P2MP and 113 Virtual Link networks, the time to reach the "ExStart" state is 114 approximate equal to the time to reach the "2-Way" state. Generally, 115 it takes 1 to 2 seconds for 10,000 LSAs to be synchronized. OSPF 116 default HelloInterval is 10 seconds. On broadcast networks (e.g. 117 Ethernet), the Waiting time is approximate 40 seconds, i.e. 4 times 118 of HelloInterval. On P2P networks (e.g. POS), the time to reach the 119 "2-Way"state is approximate the HelloInterval (10s). Namely, the time 120 to reach the "2-Way" state or the Waiting time accounts for 80%-95% 121 of the total recovery time. 123 Therefore, if a technique could reach the OSPF "ExStart" state (the 124 time to reach the "2-Way" state or Waiting time) more quickly and 125 at the same time it would not increase the traffic and burden of 126 the router CPU, it will reduce the convergence time remarkably. In 127 particular, if a router interface attached to OSPF networks goes 128 down and then up, the recovery time will be much shorter than past. 129 The experiment showing the improvement on the recovery time is 130 described in appendix A. 132 3. Potential Solution 134 Fast Hello is a mechanism that achieves the intention, but it 135 increases OSPF Hello traffic significantly. It is also not fit for 136 all kinds of routers, for example, link bandwidth is constrained or 137 CPU capability is limited. 139 4. Proposed Solution: Immediately Replying Hello 141 Immediately Replying Hello is the mechanism that an OSPF router 142 replies to its peer as soon as it receives the Hello Packet if needed, 143 which can reach the "ExStart" state quickly without increasing the 144 OSPF packet traffic which brings heavy burden to CPU. This technique 145 can make "ExStart" state to be reached quickly, however it does not 146 speed up the neighbor failure detection. 148 5. Immediately Replying Hello 150 Immediately Replying Hello is described as follow: 152 1) After a router whose neighbor state is less than "2-Way" received 153 a Hello Packet from the neighbor, it SHOULD send a Hello Packet 154 immediately to this neighbor rather than waiting for Hello Timer to 155 expire. Hello sending is described in 6.1. 157 2) After a Hello Packet from a neighbor is processed, and if the 158 router neighbor state changes from "2-Way" or greater into "Init", 159 it SHOULD immediately send Hello Packet back to the neighbor. Hello 160 sending is described in 6.1. 162 3) After DR is elected, the router whose interface state changed 163 SHOULD send Hello Packet immediately to notify other routers of the 164 change about BDR and DR on networks. Hello sending is described in 165 6.1. 167 A few additional Hello Packets are brought by Immediately Replying 168 Hello, but will be clear away when the neighbor state reaches the 169 "2-Way" state. On broadcast/NBMA networks, default configuration is 170 set to disable. Immediately Replying Hello automatically boots after 171 DR is elected. Thus, the additional Hello Packets will be avoided. 172 The mechanism has no effect on the size of OSPF LSDB. It only reduces 173 the time of OSPF neighbor state reaching "ExStart". 175 6. Interoperation 177 6.1. Compatibility with [OSPFV2] 179 Immediately Replying Hello process is compliant to [OSPFV2] 180 implementation. It has no effect on [OSPFV2] router. 182 6.2. Interoperation within Immediately Replying Hello 184 In order to achieve the best effort, the requirements of networks 185 with Immediately Replying Hello are following: 187 On p2p, p2mp and virtual link networks, both routers of a link are 188 required to support Immediately Replying Hello. 190 On broadcast/NBMA networks, all routers are required to support the 191 function in an area. 193 7. Description of the Revised protocol behavior 195 Immediately Replying Hello has some changes in current standard. 197 7.1. Modifications to Sending Hello packets 199 The sending Hello Packets as it exists in section 9.5 of [OSPFV2] 200 remains Unchanged except for the action associated with condition of 201 sending Hello Packet. To incorporate the Immediately Replying Hello 202 in [OSPFV2] this action is changed to the following. 204 7.1.1. Modification to section 9.5 of [OSPFV2] 206 The segment 5 to section 9.5 of [OSPFV2] will be replaced by the 207 following. 209 On broadcast networks, 211 o Hello packets are sent every HelloInterval seconds to the IP 212 multicast address AllSPFRouters. 214 o The Hello Packet of the Immediately Replying Hello is replied 215 respectively to each neighbor address in case of 1) or 2) in section 216 5. 218 o The Hello Packets of the Immediately Replying Hello are sent to 219 the IP multicast address AllSPFRouters in order to notify other 220 routers of the change about BDR and DR on networks when a router 221 interface state changed in case of 3) in section 5. 223 On physical point-to-point networks, Hello packets are sent every 224 HelloInterval seconds to the IP multicast address AllSPFRouters. 225 The Hello Packets of the Immediately Replying Hello are sent to the 226 IP multicast address AllSPFRouters in case of 1) or 2) in section 5. 228 On virtual links, Hello packets are sent as unicasts (addressed 229 directly to the other end of the virtual link) every HelloInterval 230 seconds. The Hello Packets of the Immediately Replying Hello are sent 231 as unicasts in case of 1) or 2) in section 5. The behavior of this 232 mechanism on Sham-link, is same to virtual link. 234 On Point-to-MultiPoint networks, separate Hello packets are sent 235 to each attached neighbor every HelloInterval seconds. The Hello 236 Packets of the Immediately Replying Hello are sent to the IP 237 multicast address AllSPFRouters in case of 1) or 2) in section 5. 239 7.1.2. Modification to section 9.5.1 of [OSPFV2] 241 The segment 3 to section 9.5.1 of [OSPFV2] will be replaced by the 242 following. 244 If the router is eligible to become Designated Router, it must 245 periodically send Hello Packets to all neighbors that are also 246 eligible. It SHOULD also send an Hello Packet in reply to an Hello 247 Packet received from any eligible neighbor in case of 1) or 2) in 248 section 5. In addition, if the router is itself the Designated Router 249 or Backup Designated Router, it must also send periodic Hello Packets 250 to all other neighbors. This means that any two eligible routers are 251 always exchanging Hello Packets, which is necessary for the correct 252 operation of the Designated Router election algorithm. To minimize 253 the number of Hello Packets sent, the number of eligible routers on 254 an NBMA network should be kept small. 256 7.2. Modifications to Electing the Designated Router 258 The election of Designated Router as it exists in section 9.4 of 259 [OSPFV2] remains unchanged except for the step (7). To incorporate 260 the Immediately Replying Hello in [OSPFV2] ,step (7) is changed to 261 the following. 263 (7) If the above calculations have caused the identity of either the 264 Designated Router or Backup Designated Router to change, the set of 265 adjacencies associated with this interface will need to be modified. 266 The router whose interface state changes SHOULD send hello packet 267 immediately to notify other routers of the change about BDR or DR on 268 networks (Hello sending is described in 6.1). Some adjacencies may 269 need to be formed, and others may need to be broken. To accomplish 270 this, invoke the event AdjOK? on all neighbors whose state is at 271 least 2-Way. This will cause their eligibility for adjacency to be 272 reexamined. 274 7.3. Modifications To The Neighbor State Machine 276 The state machine as it exists in section 10.3 of [OSPFV2] remains 277 unchanged except for the action associated with State: Init, Event: 279 2-WayReceived and State 2-Way or greater, Event: 1-WayReceived. 280 To incorporate Immediately Replying Hello in [OSPFV2] this action is 281 changed to the following. 283 State(s): Init 285 Event: 2-WayReceived 287 New state: Depends upon action routine. 289 Action: Determine whether an adjacency should be 290 established with the neighbor (see Section 10.4 291 of [OSPFV2]). If not, the new neighbor state is 292 2-Way and it SHOULD send Hello Packet immediately 293 back to the neighbor. 295 Otherwise (an adjacency should be established) 296 the neighbor state transitions to ExStart. Upon 297 entering this state, the router increments the DD 298 sequence number in the neighbor data structure.If 299 this is the first time that an adjacency has been 300 attempted, the DD sequence number should be 301 assigned some unique value (like the time of day 302 clock). It then declares itself master (sets the 303 master/slave bit to master), and starts sending 304 Database Description Packets, with the initialize 305 (I), more (M) and master (MS) bits set. This 306 Database Description Packet should be otherwise 307 empty. This Database Description Packet should be 308 retransmitted at intervals of RxmtInterval until 309 the next state is entered (see Section 10.8 of 310 [OSPFV2]). Hello sending is described in 6.1. 312 State(s): 2-Way or greater 314 Event: 1-WayReceived 316 New state: Init 318 Action: The Link state retransmission list, Database 319 summary list and Link state request list are 320 cleared of LSAs. Hello packets are sent 321 immediately to the neighbor leading to the Event. 322 Hello sending is described in 6.1. 324 8. Benefit 326 On P2P, P2MP, Sham-link and virtual links networks, the time to reach 327 the "ExStart" state is reduced to sub-second by Immediately Replying 328 Hello. On broadcast and NBMA networks, the time to reach the 329 "ExStart" state is reduced to sub-second by Immediately Replying 330 Hello when DR or BDR exists. 332 9. Security Considerations 334 This memo does not create any new security issues for the OSPF 335 protocol. Security considerations for base OSPF protocol are covered 336 in [OSPFV2]. 338 10. Acknowledgments 340 The author would like to thank Renhai Zhang, Xiaoyi Guo, Acee Lindem 341 and Lixia Zhang for their helpful comments on this work. 343 APPENDIX A: Immediately Replying Hello Experiment Report 345 The method of experiment is described as follow: 347 o DUT(device-under-test) interface goes down and up. 349 o The following list is the time to reach the "Full" state since 350 the DUT interface goes up. The experiment is repeated five times for 351 each condition. 353 o The networks delay(from line-card to master-card) is not 354 considered. 356 o The unit is millisecond. 358 o The HelloInterval is 10 seconds. 360 o No routing entry is imported on the experiment. So LSDB 361 synchronization time is 0 on the case and the recovery time is equal 362 to the time to reach the "ExStart" state. 364 A.1. Broadcast networks 366 A.1.1. No BDR on Broadcast networks 368 +---+ +---+ 370 |DUT| |RTA| 372 +---+ +---+ 374 | ETH | 376 +----------------------+ 378 | ETH | 380 +---+ +---+ 382 |RTB| |RTC| 384 +---+ +---+ 386 Figure 1: Topology of broadcast networks 388 A.1.1.1. DUT is DR 390 Topology description: 392 o Networks is Ethernet. 394 o Boxes are connected as Figure 1. 396 o DUT is DR. 398 The time for DUT to reach the"Full" state with others is described 400 as follow: 402 +-----------+---------+------+------+------+------+------+ 404 | without | with RTA|44222 |42483 |44781 |43844 |42078 | 406 | +---------+------+------+------+------+------+ 408 | the | with RTB|44225 |42486 |44787 |43841 |42070 | 410 | +---------+------+------+------+------+------+ 412 | method | with RTC|44221 |42485 |44791 |43840 |42079 | 414 +-----------+---------+------+------+------+------+------+ 416 | with | with RTA|43328 |41406 |40016 |40156 |40922 | 418 | +---------+------+------+------+------+------+ 420 | the | with RTB|43321 |41406 |40020 |40110 |40912 | 422 | +---------+------+------+------+------+------+ 424 | method | with RTC|43323 |41408 |40036 |40159 |40905 | 426 +-----------+---------+------+-------+-------+-------+---+ 428 Table 1. DUT recovery time on broadcast networks 430 Analysis: 432 The recovery time = the time to reach the "ExStart" state + LSDB 434 synchronization time. 436 The time to reach the "ExStart" state = Waiting time(40s). 438 LSDB synchronization time = 0. 440 When DUT interface goes up, DR will be reelected because no BDR 441 exists. The Waiting time can not be avoided, therefore the effect of 442 this technique is not obvious. 444 A.1.1.2. DUT is DROther 446 Topology description: 448 o Networks is Ethernet. 450 o Boxes are connected as Figure 1. 452 o RTA is DR. 454 The time for DUT to reach "Full" state with others is described 456 as follow: 458 +-----------------------------+------+------+------+-----+-----+ 460 |without the method (with RTA)|11951 |11283 |14561 |5803 |6687 | 462 +-----------------------------+------+------+------+-----+-----+ 464 |with the method (with RTA)|156 |140 |141 |156 |157 | 466 +-----------------------------+------+------+------+-----+-----+ 467 Table 2. DUT recovery time on broadcast networks 469 Analysis: 471 The recovery time = the time to reach the "ExStart" state + LSDB 473 synchronization time. 475 LSDB synchronization time = 0. 477 The time to reach "ExStart" state is equal to the time to reach 478 "2-Way" because DR is not changed without the Immediately Replying 479 Hello. 481 If DUT interface goes up, the time to reach "2-Way"state consists 482 mostly of expiration time of Hello Timer. It is approximate 483 HelloInterval (10s). However, the time to reach "2-Way"state is very 484 short with theImmediately Replying Hello. Accordingly, the recovery 485 time is shorter. 487 A.1.2. BDR Exists on Broadcast 489 +---+ +---+ 491 |DUT| |RTA| 493 +---+ +---+ 495 | ETH | 497 +----------------------+ 499 | ETH | 501 +---+ +---+ 503 |RTB| |RTC| 505 +---+ +---+ 507 Figure 2: Topology on Broadcast networks 509 A.1.2.1. DUT is DR 511 Topology description: 513 o Networks is Ethernet. 515 o Boxes are connected as Figure 2. 517 o DUT is DR,RTA is BDR 519 The time for DUT to reach the "Full" state with others is 520 described as follow: 522 +-------------------+--------+-----+-----+-----+-----+-----+ 524 | |with RTA|10032|14453|14125|10656|15922| 526 | +--------+-----+-----+-----+-----+-----+ 528 |without the method |with RTB|6235 |14516|9750 |11031|12500| 530 | +--------+-----+-----+-----+-----+-----+ 532 | |with RTC|10236|14513|9751 |11038|12520| 534 +-------------------+--------+-----+-----+-----+-----+-----+ 536 | |with RTA|500 |328 |469 |235 |515 | 538 | +--------+-----+-----+-----+-----+-----+ 540 |with the method |with RTB|500 |328 |469 |204 |515 | 542 | +--------+-----+-----+-----+-----+-----+ 544 | |with RTC|500 |328 |469 |206 |515 | 546 +-------------------+--------+-----+-----+-----+-----+-----+ 548 Table 3. DUT recovery time on broadcast networks 550 Analysis: 552 The recovery time = the time to reach the "ExStart" state + LSDB 554 synchronization time. 556 LSDB synchronization time = 0. 558 The time to reach the "ExStart" state is equal to BackupSeen time 559 because DR is changed and BDR will become DR. 561 If DUT interface goes up, the time to reach the "2-Way"state consists 562 mostly of expiration time of BackupSeen. It is approximate 563 HelloInterval (10s). However, the time to reach "2-Way"state is very 564 short with the Immediately Replying Hello. Accordingly, the recovery 565 time is shorter. 567 A.1.2.2. DUT is BDR 569 Topology description: 571 o Networks is Ethernet. 573 o Boxes are connected as Figure 2. 575 o DUT is BDR,RTA is DR 577 The time for DUT to reach the"Full" state with others is 578 described as follow: 580 +-------------------+--------+------+------+------+------+------+ 582 | |with RTA|8375 | 14563|16000 |14016 |12610 | 583 | +--------+------+------+------+------+------+ 585 |without the method |with RTB|7969 |14500 |6547 |11032 |7016 | 587 | +--------+------+------+------+------+------+ 588 | |with RTC|7961 |14509 |6547 |11002 |7010 | 590 +-------------------+--------+------+------+------+------+------+ 592 | |with RTA|250 |187 |235 |204 |172 | 594 | +--------+------+------+------+------+------+ 596 |with the method |with RTB|250 |187 |235 |204 |172 | 598 | +--------+------+------+------+------+------+ 600 | |with RTC|250 |187 |235 |204 |172 | 602 +-------------------+--------+------+------+------+------+------+ 604 Table 4. DUT recovery time on broadcast networks 606 Analysis: 608 The recovery time = the time to reach the "ExStart" state + LSDB 610 synchronization time. 612 LSDB synchronization time = 0. 614 The time to reach "ExStart" state is equal to the time to reach 615 "2-Way" state because DR is not changed. 617 If DUT interface goes up, the time to reach "2-Way"state consists 618 mostly of expiration time of BackupSeen. It is approximate 619 HelloInterval (10s). However, the time to reach "2-Way" state is 620 very short with the Immediately Replying Hello. Accordingly, the 621 recovery time is shorter. 623 A.1.2.3. DUT is DROther 625 Topology description: 627 o Networks is Ethernet. 629 o Boxes are connected as Figure 2. 631 o DUT is DROther,RTA is DR,RTB is BDR. 633 The time for DUT to reach the "Full" state with others is 634 described as follow: 636 +------------------+--------+------+------+------+------+------+ 638 | |with RTA|18219 |12625 |9328 |14375 |10235 | 640 |without the method+--------+------+------+------+------+------+ 642 | |with RTB|18219 |12313 |9891 |14781 |10454 | 644 +------------------+--------+------+------+------+------+------+ 646 | |with RTA|141 |156 |172 |172 |156 | 648 |with the method +--------+------+------+------+------+------+ 650 | |with RTB|141 |156 |172 |172 |156 | 652 +------------------+--------+------+------+------+------+------+ 654 Table 5. DUT recovery time on broadcast networks 656 Analysis: 658 The recovery time = the time to reach the "ExStart" state + LSDB 660 synchronization time. 662 LSDB synchronization time = 0. 664 The time to reach the "ExStart" state is equal to the time to reach 665 the "2-Way" state because DR is not changed. 667 if DUT interface goes up, the time to reach "2-Way"state consists 668 mostly of expiration time of Hello Timer. It is approximate 669 HelloInterval (10s). However, the time to reach "2-Way"state is 670 very short with the Immediately Replying Hello. Accordingly, the 671 recovery time is shorter. 673 A.1.3. N routers (n>=2) Exist on Broadcast Ethernet 675 Immediately Replying Hello is used to reduce the time to reach the 676 "ExStart" state. It is independent of the number of OSPF router. 677 So the result of A.1 is generalized to other condition on multi- 678 access networks. 680 A.2. Point to Point networks 682 +---+ +---+ 684 |DUT|--------------------|RTA| 686 +---+ +---+ 688 Figure 3: P2P networks 690 Topology description: 692 o Networks is PoS. 694 o Boxes are connected as Figure 3. 696 The time for DUT to reach "Full" state with others is described 697 as follow: 699 +---------------------+-------+-------+-------+-------+-------+ 701 |without the method |10062 |15797 |10938 |15703 |10547 | 703 +---------------------+-------+-------+-------+-------+-------+ 704 |with the method |94 |109 |93 |141 |109 | 706 +---------------------+-------+-------+-------+-------+-------+ 708 Table 6. DUT recovery time on P2P networks 710 Analysis: 712 The recovery time = the time to reach the "ExStart" state + LSDB 714 synchronization time. 716 The time to reach the"ExStart" state = the time to reach the 717 "2-Way" state. 719 LSDB synchronization time = 0. 721 if DUT interface goes up , the time to reach "2-Way"state consists 722 mostly of expiration time of Hello Timer. The time is approximate 723 HelloInterval (10s). However, the time to reach the "2-way" state 724 is very quick with the Immediately Replying Hello. So, the recovery 725 time is shorter. 727 11. References 729 11.1. Normative References 731 [OSPFV2] Moy ,J. "OSPF Version 2", STD 54, RFC 2328, April 1998. 733 11.2. Informative References 735 [Pierre Franc's paper] July'05 issue of ACM Computer Communication 736 Review "Achieving sub-second IGP convergence in large IP networks". 738 Author's Addresses 740 Zengjie Kou 741 Huawei technology 742 kouzengjie@huawei.com 744 Feng Yang 745 Huawei technology 746 feng.yang@huawei.com 748 Huaiyuan Ma 749 Huawei technology 750 mahuaiyuan@huawei.com 752 Intellectual Property Statement 754 The IETF takes no position regarding the validity or scope of any 755 Intellectual Property Rights or other rights that might be claimed to 756 pertain to the implementation or use of the technology described in 757 this document or the extent to which any license under such rights 758 might or might not be available; nor does it represent that it has 759 made any independent effort to identify any such rights. Information 760 on the procedures with respect to rights in RFC documents can be 761 found in BCP 78 and BCP 79. 763 Copies of IPR disclosures made to the IETF Secretariat and any 764 assurances of licenses to be made available, or the result of an 765 attempt made to obtain a general license or permission for the use of 766 such proprietary rights by implementers or users of this 767 specification can be obtained from the IETF on-line IPR repository at 768 http://www.ietf.org/ipr. 770 The IETF invites any interested party to bring to its attention any 771 copyrights, patents or patent applications, or other proprietary 772 rights that may cover technology that may be required to implement 773 this standard. Please address the information to the IETF at 774 ietf-ipr@ietf.org. 776 Disclaimer of Validity 778 This document and the information contained herein are provided on an 779 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 780 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 781 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 782 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 783 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 784 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 786 Copyright Statement 788 Copyright (C) The Internet Society (2007). 790 This document is subject to the rights, licenses and restrictions 791 contained in BCP 78, and except as set forth therein, the authors 792 retain all their rights. 794 Acknowledgment 796 Funding for the RFC Editor function is currently provided by the 797 Internet Society.