idnits 2.17.1 draft-ietf-ospf-hitless-restart-05.txt: 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 388: '...n implementation MAY provide a configu...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 2003) is 7769 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) == Unused Reference: '3' is defined on line 659, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 489, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2370 (ref. '2') (Obsoleted by RFC 5250) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Moy (Sycamore Networks) 3 Internet Draft Padma Pillay-Esnault (Juniper Networks) 4 Expiration Date: August 2003 Acee Lindem, Editor (Redback Networks) 5 File name: draft-ietf-ospf-hitless-restart-05.txt January 2003 7 Hitless OSPF Restart 8 draft-ietf-ospf-hitless-restart-05.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet- Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This memo documents an enhancement to the OSPF routing protocol, 34 whereby an OSPF router can stay on the forwarding path even as its 35 OSPF software is restarted. This is called "hitless restart" or 36 "non-stop forwarding". A restarting router may not be capable of 37 adjusting its forwarding in a timely manner when the network 38 topology changes. In order to avoid the possible resulting routing 39 loops the procedure in this memo automatically reverts to a normal 40 OSPF restart when such a topology change is detected, or when one or 41 more of the restarting router's neighbors do not support the 42 enhancements in this memo. Proper network operation during a hitless 43 restart makes assumptions upon the operating environment of the 44 restarting router; these assumptions are also documented. 46 Table of Contents 48 1 Overview ............................................... 2 49 1.1 Acknowledgments ........................................ 3 50 2 Operation of restarting router ......................... 3 51 2.1 Entering hitless restart ............................... 4 52 2.2 When to exit hitless restart ........................... 5 53 2.3 Actions on exiting hitless restart ..................... 6 54 3 Operation of helper neighbor ........................... 6 55 3.1 Entering helper mode ................................... 7 56 3.2 Exiting helper mode .................................... 8 57 4 Backward compatibility ................................. 9 58 5 Unplanned outages ...................................... 9 59 6 Interaction with Traffic Engineering .................. 10 60 7 Possible Future Work .................................. 10 61 References ............................................ 10 62 A Grace-LSA format ...................................... 11 63 B Configurable Parameters ............................... 13 64 C Change log ............................................ 14 65 Security Considerations ............................... 15 66 Authors' Addresses .................................... 15 68 1. Overview 70 Today many Internet routers implement a separation of control and 71 forwarding functions. Certain processors are dedicated to control 72 and management tasks such as OSPF routing, while other processors 73 perform the data forwarding tasks. This separation creates the 74 possibility of maintaining a router's data forwarding capability 75 while the router's control software is restarted/reloaded. We call 76 such a possibility "hitless restart" or "non-stop forwarding". 78 The problem that the OSPF protocol presents to hitless restart is 79 that, under normal operation, OSPF intentionally routes around a 80 restarting router while it rebuilds its link-state database. OSPF 81 avoids the restarting router to minimize the possibility of routing 82 loops and/or black holes caused by lack of database synchronization. 83 Avoidance is accomplished by having the router's neighbors reissue 84 their LSAs, omitting links to the restarting router. 86 However, if (a) the network topology remains stable and (b) the 87 restarting router is able to keep its forwarding table(s) across the 88 restart, it would be safe to keep the restarting router on the 89 forwarding path. This memo documents an enhancement to OSPF that 90 makes such hitless restart possible, and one that automatically 91 reverts back to a standard OSPF restart for safety when network 92 topology changes are detected. 94 In a nutshell, the OSPF enhancements for hitless restart are as 95 follows. The router attempting a hitless restart originates link- 96 local Opaque-LSAs, herein called Grace-LSAs, announcing the 97 intention to perform a hitless restart, and asking for a "grace 98 period". During the grace period its neighbors continue to announce 99 the restarting router in their LSAs as if it were fully adjacent 100 (i.e., OSPF neighbor state Full), but only if the network topology 101 remains static (i.e, the contents of the LSAs in the link-state 102 database having LS types 1-5,7 remain unchanged; periodic refreshes 103 are allowed). 105 There are two roles being played by OSPF routers during hitless 106 restart. First there is the router that is being restarted. The 107 operation of this router during hitless restart, including how the 108 router enters and leaves hitless restart, is the subject of Section 109 2. Then there are the router's neighbors, which must cooperate in 110 order for the restart to be hitless. During hitless restart we say 111 that the neighbors are executing in "helper mode". Section 3 covers 112 the responsibilities of a router executing in helper mode, including 113 entering and leaving helper mode. 115 1.1. Acknowledgments 117 The authors wish to thank John Drake, Vishwas Manral, 118 Kent Wong and Don Goodspeed for their helpful comments. 120 2. Operation of restarting router 122 After the router restarts/reloads, it must change its OSPF 123 processing somewhat until it re-establishes full adjacencies with 124 all its previously fully-adjacent neighbors. This time period, 125 between the restart/reload and the reestablishment of adjacencies, 126 is called "hitless restart". During hitless restart: 128 (1) The restarting router does not originate LSAs with LS types 129 1-5,7. Instead, the restarting router wants the other routers 130 in the OSPF domain to calculate routes using the LSAs that it 131 had originated prior to its restart. During this time, the 132 restarting router does not modify or flush received self- 133 originated LSAs, (see Section 13.4 of [1]) but instead 134 accepts them as valid. In particular, the grace-LSAs that the 135 restarting router had originated before the restart are left 136 in place. Received self-originated LSAs will be dealt with 137 when the router exits hitless restart (see Section 2.3). 139 (2) The restarting router runs its OSPF routing calculations, as 140 specified in Section 16 of [1]. This is necessary to 141 return any OSPF virtual links to operation. However, the 142 restarting router does *not* install OSPF routes into the 143 system's forwarding table(s), instead relying on the 144 forwarding entries that it had installed prior to the 145 restart. 147 (3) If the restarting router determines that it was Designated 148 Router on a given segment immediately prior to the restart, 149 it elects itself as Designated Router again. The restarting 150 router knows that it was Designated Router if, while the 151 associated interface is in Waiting state, an Hello packet is 152 received from a neighbor listing the router as Designated 153 Router. 155 Otherwise, the restarting router operates the same as any other OSPF 156 router. It discovers neighbors using OSPF's Hello protocol, elects 157 Designated and Backup Designated Routers, performs the Database 158 Exchange procedure to initially synchronize link-state databases 159 with its neighbors, and maintains this synchronization through 160 flooding. 162 The processes of entering hitless restart, and of exiting hitless 163 restart (either successfully or not) are covered in the following 164 sections. 166 2.1. Entering hitless restart 168 The router (call it Router X) is informed of the desire for its 169 hitless restart when an appropriate command is issued by the 170 network operator. The network operator may also specify the 171 length of the grace period, or the necessary grace period may be 172 calculated by the router's OSPF software. In order to avoid 173 the restarting router's LSAs from aging out, the grace period 174 should not exceed LSRefreshTime (1800 second) [1]. 176 In preparation for the hitless restart, Router X must perform 177 the following actions before its software is restarted/reloaded. 178 Note that common OSPF shutdown procedures are *not* performed, 179 since we want the other OSPF routers to act as if Router X 180 remains in continuous service. For example, Router X does not 181 flush its locally originated LSAs, since we want them to remain 182 in other routers' link-state databases throughout the restart 183 period. 185 (1) Router X must ensure that its forwarding table(s) is/are 186 up-to-date and will remain in place across the restart. 188 (2) The router may need to preserve the cryptographic 189 sequence numbers being used on each interface in 190 non-volatile storage. An alternative is to use the 191 router's clock for cryptographic sequence number 192 generation and ensure the clock is preserved across 193 restarts (either on the same or redundant route 194 processors). If neither of these can be guarenteed, it 195 can take up to RouterDeadInterval seconds after the 196 restart before adjacencies can be reestablished and this 197 would force the grace period to be lengthened greatly. 199 Router X then originates the grace-LSAs. These are link-local 200 Opaque-LSAs (see Appendix A). Their LS Age field is set to 0, 201 and the requested grace period (in seconds) is inserted into the 202 body of the grace-LSA. The precise contents of the grace-LSA are 203 described in Appendix A. 205 A grace-LSA is originated for each of the router's OSPF 206 interfaces. If Router X wants to ensure that its neighbors 207 receive the grace-LSAs, it should retransmit the grace-LSAs 208 until they are acknowledged (i.e, perform standard OSPF reliable 209 flooding of the grace-LSAs). If one or more fully adjacent 210 neighbors do not receive grace-LSAs, they will more than likely 211 cause premature termination of the hitless restart procedure 212 (see Section 4). 214 After the grace-LSAs have been sent, the router should store the 215 fact that it is performing hitless restart along with the length 216 of the requested grace period in non-volatile storage. (Note to 217 implementors: It may be easiest to simply store the absolute 218 time of the end of the grace period). The OSPF software should 219 then be restarted/reloaded, and when the reloaded software 220 starts executing the hitless restart modifications in Section 2 221 above are followed. (Note that prior to the restart, the router 222 does not know whether its neighbors are going to cooperate as 223 "helpers"; the mere reception of grace-LSAs does not imply 224 acceptance of helper responsibilities. This memo assumes that 225 the router would want to restart anyway, even if the restart is 226 not going to be hitless). 228 2.2. When to exit hitless restart 230 A Router X exits hitless restart when any of the following 231 occurs: 233 (1) Router X has reestablished all its adjacencies. Router X 234 can determine this by examining the router-LSAs that it 235 had last originated before the restart (called the "pre- 236 restart router-LSA"), and, on those segments where the 237 router is Designated Router, the pre-restart network- 238 LSAs. These LSAs will have been received from the helping 239 neighbors, and need not have been stored in non-volatile 240 storage across the restart. All previous adjacencies will 241 be listed as type-1 and type 2 links in the router-LSA, 242 and as neighbors in the body of the network-LSA. 244 (2) Router X receives an LSA that is inconsistent with its 245 pre-restart router-LSA. For example, X receives a router- 246 LSA originated by router Y that does not contain a link 247 to X, even though X's pre-start router-LSA did contain a 248 link to Y. This indicates that either a) Y does not 249 support hitless restart, b) Y never received the grace- 250 LSA or c) Y has terminated its helper mode for some 251 reason (Section 3.2). 253 (3) The grace period expires. 255 2.3. Actions on exiting hitless restart 257 On exiting "hitless restart", the reloaded router reverts back 258 to completely normal OSPF operation, reoriginating LSAs based on 259 the router's current state and updating its forwarding table(s) 260 based on the current contents of the link-state database. In 261 particular, the following actions should be performed when 262 exiting, either successfully or unsuccessfully, hitless restart. 264 (1) The router should reoriginate its router-LSAs for all 265 attached areas, to make sure they have the correct 266 contents. 268 (2) The router should reoriginate network-LSAs on all 269 segments where it is Designated Router. 271 (3) The router reruns its OSPF routing calculations (Section 272 16 of [1]), this time installing the results into the 273 system forwarding table, and originating summary-LSAs, 274 Type-7 LSAs and AS-external-LSAs as necessary. 276 (4) Any remnant entries in the system forwarding table that 277 were installed before the restart, but that are no longer 278 valid, should be removed. 280 (5) Any received self-originated LSAs that are no longer 281 valid should be flushed. 283 (6) Any grace-LSAs that the router had originated should be 284 flushed. 286 3. Operation of helper neighbor 288 The helper relationship is per network segment. As a "helper 289 neighbor" on a segment S for a restarting router X, router Y has 290 several duties. It monitors the network for topology changes, and as 291 long as there are none, continues to its advertise its LSAs as if X 292 had remained in continuous OSPF operation. This means that Y's LSAs 293 continue to list an adjacency to X over network segment S, 294 regardless of the adjacency's current synchronization state. This 295 logic affects the contents of both router-LSAs and network-LSAs, and 296 also depends on the type of network segment S (see Sections 12.4.1.1 297 through 12.4.1.5 and Section 12.4.2 of [1]). When helping over a 298 virtual link, the helper must also continue to set bit V in its 299 router-LSA for the virtual link's transit area (Section 12.4.1 of 300 [1]). 302 Also, if X was the Designated Router on network segment S when the 303 helping relationship began, Y maintains X as Designated router until 304 the helping relationship is terminated. 306 3.1. Entering helper mode 308 When a router Y receives a grace-LSA from router X, it enters 309 helper mode for X, on the associated network segment, as long as 310 all the following checks pass: 312 (1) Y currently has a full adjacency with X (neighbor state 313 Full) over the associated network segment. On broadcast, 314 NBMA and Point-to-MultiPoint segments, the neighbor 315 relationship with X is identified by the IP interface 316 address in the body of the grace-LSA (see Appendix A). On 317 all other segment types X is identified by the grace- 318 LSA's Advertising Router field. 320 (2) There have been no changes in content to the link-state 321 database (LS types 1-5,7) since router X restarted. This 322 is determined as follows. Router Y examines the link- 323 state retransmission list for X over the associated 324 network segment. If there are any LSAs with LS types 325 1-5,7 on the list, then they all must be periodic 326 refreshes. If there are instead LSAs on the list whose 327 contents have changed (see Section 3.3 of [8]), Y must 328 refuse to enter helper mode. 330 (3) The grace period has not yet expired. This means that the 331 LS age of the grace-LSA is less than the grace period 332 specified in the body of the grace-LSA (Appendix A). 334 (4) Local policy allows Y to act as the helper for X. 335 Examples of configured policies might be a) never act as 336 helper, b) never allow the grace period to exceed a Time 337 T, c) only help on software reloads/upgrades, or d) never 338 act as a helper for certain specific routers (specified 339 by OSPF Router ID). 341 There is one exception to the above requirements. If Y was 342 already helping X on the associated network segment, the new 343 grace-LSA should be accepted and the grace period should be 344 updated accordingly. 346 Note that Router Y may be helping X on some network segments, 347 and not on others. However, that circumstance will probably lead 348 to the premature termination of X's hitless restart, as Y will 349 not continue to advertise adjacencies on the segments where it 350 is not helping (see Section 2.2). 352 Alternately, Router Y may choose to enter enter helper mode 353 when a grace LSA is received and the above checks pass for all 354 adjacencies with Router X. This implemenation alternative 355 of aggregating the adjacencies with respect to helper mode is 356 compatible with implementations considering each adjacency 357 independently. 359 A single router is allowed to simultaneously serve as a helper 360 for multiple restarting neighbors. 362 3.2. Exiting helper mode 364 Router Y ceases to perform the helper function for its neighbor 365 Router X on a given segment when one of the following events 366 occurs. 368 (1) The grace-LSA originated by X on the segment is flushed. 369 This is the successful termination of hitless restart. 371 (2) The grace-LSA's grace period expires. 373 (3) A change in link-state database contents indicates a 374 network topology change, which forces termination of a 375 hitless restart. Specifically, if router Y installs a 376 new LSA in its database with LS types 1-5,7 and having 377 the following two properties, it should cease helping X. 378 The two properties of the LSA are a) the contents of the 379 LSA have changed; this includes LSAs with no previous 380 link-state database instance and the flushing of LSAs 381 from the database, but excludes periodic LSA refreshes 382 (see Section 3.3 of [8]), and b) the LSA would have 383 been flooded to X, had Y and X been fully adjacent. As an 384 example of the second property, if Y installs a changed 385 AS-external-LSA, it should not terminate a helping 386 relationship with a neighbor belonging to a stub area, as 387 that neighbor would not see the AS-external-LSA in any 388 case. An implementation MAY provide a configuration 389 option to disable link-state database options from 390 terminating hitless restart. Such an option will, 391 however, increase the risk of routing loops and 392 black holes. 394 When Router Y exits helper mode for X on a given network 395 segment, it reoriginates its LSAs based on the current state of 396 its adjacency to Router X over the segment. In detail, Y takes 397 the following actions: (a) Y recalculates the Designated Router 398 for the segment, (b) Y reoriginates its router-LSA for the 399 segment's OSPF area, (c) if Y is Designated Router for the 400 segment, it reoriginates the network-LSA for the segment and (d) 401 if the segment was a virtual link, Y reoriginates its router-LSA 402 for the virtual link's transit area. 404 If Router Y aggregated adjacencies with Router X when 405 entering helper mode (as described in section 3.1), it must also 406 exit helper mode for all adjacencies with Router X when any one 407 of the exit events occurs for of adjacency with Router X. 409 4. Backward compatibility 411 Backward-compatibility with unmodified OSPF routers is an automatic 412 consequence of the functionality documented above. If one or more 413 neighbors of a router requesting hitless restart are unmodified, or 414 if they do not received the grace-LSA, the hitless restart converts 415 to a normal OSPF restart. 417 The unmodified routers will start routing around the restarted 418 router X as it performs initial database synchronization, by 419 reissuing their LSAs with links to X omitted. These LSAs will be 420 interpreted by helper neighbors as a topology change, and by X as an 421 LSA inconsistency, in either case reverting to normal OSPF 422 operation. 424 5. Unplanned outages 426 The hitless restart mechanisms in this memo can be used for 427 unplanned outages. (Examples of unplanned outages include the crash 428 of a router's control software, an unexpected switchover to a 429 redundant control processor, etc). However, implementors and network 430 operators should note that attempting hitless restart from an 431 unplanned outage may not be a good idea, owing to the router's 432 inability to properly prepare for the restart (see Section 2.1). In 433 particular, it seems unlikely that a router could guarantee the 434 sanity of its forwarding table(s) across an unplanned restart. In 435 any event, implementors providing the option to recover hitlessly 436 from unplanned outages must allow a network operator to turn the 437 option off. 439 In contrast to the procedure for planned restart/reloads that was 440 described in Section 2.1, a router attempting hitless restart after 441 an unplanned outage must originate grace-LSAs *after* its control 442 software resumes operation. The following points must be observed 443 during this grace-LSA origination. 445 o The grace-LSAs must be originated and sent *before* the 446 restarted router sends any OSPF Hello Packets. On broadcast 447 networks, this LSA must be flooded to the AllSPFRouters 448 multicast address (224.0.0.5) since the restarting router is 449 not aware of its previous DR state. 451 o The grace-LSAs are encapsulated in Link State Update Packets and 452 sent out all interfaces, even though the restarted router has no 453 adjacencies and no knowledge of previous adjacencies. 455 o To improve the probability that grace-LSAs be delivered, an 456 implementation may send them a number of times (see for example 457 the Robustness Variable in [8]). 459 o The restart reason in the grace-LSAs must be set to unknown(0). 460 This enables the neighbors to decide whether they want to help 461 the router through an unplanned restart. 463 6. Interaction with Traffic Engineering 465 The operation of the Traffic Engineering Extensions to OSPF [4] 466 during OSPF Hitless Restart is specified in [6]. 468 7. Possible Future Work 470 Devise a less conservative algorithm for graceful restart 471 helper termination that provides a comparable level of 472 black hole and routing loop avoidance. 474 Normative References 476 [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 478 [2] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 479 1998. 481 Informative References 483 [3] Murphy, S., M. Badger and B. Wellington, "OSPF with Digital 484 Signatures", RFC 2154, June 1997. 486 [4] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering 487 Extensions to OSPF", work in progress. 489 [5] Coltun, R., V. Fuller and P. Murphy, "The OSPF NSSA Option", 490 work in progress. 492 [6] Kompella, K., et. al., "Routing Extensions in Support of 493 Generalized MPLS", work in progress. 495 [7] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 496 1793, April 1995. 498 [8] Fenner, W., "Internet Group Membership Protocol, Version 2", 499 RFC 2236, November 1997. 501 A. Grace-LSA format 503 The grace-LSA is a link-local scoped Opaque-LSA [2] having Opaque 504 Type of 3 and Opaque ID equal to 0. Grace-LSAs are originated by a 505 router that wishes to execute a hitless restart of its OSPF 506 software. A grace-LSA requests that the router's neighbors aid it in 507 its hitless restart by continuing to advertise the router as fully 508 adjacent during a specified grace period. 510 Each grace-LSA has LS age field set to 0 when the LSA is first 511 originated; the current value of LS age then indicates how long ago 512 the restarting router made its request. The body of the LSA is TLV- 513 encoded. The TLV-encoded information includes the length of the 514 grace period, the reason for the hitless restart and, when the 515 grace-LSA is associated with a broadcast, NBMA or Point-to- 516 MultiPoint network segment, the IP interface address of the 517 restarting router. 519 0 1 2 3 520 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | LS age | Options | 9 | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | 3 | 0 | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Advertising Router | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | LS sequence number | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | LS checksum | length | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | | 533 +- TLVs -+ 534 | ... | 536 The format of the TLVs within the body of a grace-LSA is the same as 537 the TLV format used by the Traffic Engineering Extensions to OSPF 538 [4]. The TLV header consists of a 16-bit Type field and a 16-bit 539 length field, and is followed by zero or more bytes of value. The 540 length field indicates the length of the value portion in bytes. The 541 value portion is padded to four-octet alignment, but the padding is 542 not included in the length field. For example, a one byte value 543 would have the length field set to 1, and three bytes of padding 544 would be added to the end of the value portion of the TLV. 546 The following is the list of TLVs that can appear in the body of a 547 grace-LSA. 549 o Grace Period (Type=1, length=4). The number of seconds that the 550 router's neighbors should continue to advertise the router as 551 fully adjacent, regardless of the the state of database 552 synchronization between the router and its neighbors. Since this 553 time period began when grace-LSA's LS age was equal to 0, the 554 grace period terminates when either a) the LS age of the grace- 555 LSA exceeds the value of Grace Period or b) the grace-LSA is 556 flushed. See Section 3.2 for other conditions which terminate 557 the grace period. This TLV must always appear in a grace-LSA. 559 o Hitless restart reason (Type=2, length=1). Encodes the reason 560 for the router restart, as one of the following: 0 (unknown), 1 561 (software restart), 2 (software reload/upgrade) or 3 (switch to 562 redundant control processor). This TLV must always appear in a 563 grace-LSA. 565 o IP interface address (Type=3, length=4). The router's IP 566 interface address on the subnet associated with the grace-LSA. 567 Required on broadcast, NBMA and Point-to-MultiPoint segments, 568 where the helper uses the IP interface address to identify the 569 restarting router (see Section 3.1). 571 DoNotAge is never set in a grace-LSA, even if the grace-LSA is 572 flooded over a demand circuit [7]. This is because the grace-LSA's 573 LS age field is used to calculate the extent of the grace period. 575 Grace-LSAs have link-local scope because they only need to be seen 576 by the router's direct neighbors. 578 B. Configurable Parameters 580 OSPF hitless restart parameters are suggested below. Section 581 B.1 contains a minimum subset of parameters that should be 582 supported. B.2 includes some additional configuration parameters 583 an implementation may choose to support. 585 B.1 Global Parameters (Minimum subset) 587 RestartSupport 589 The router's level of support for OSPF hitless restart. 590 Allowable values are none, planned restart only, and 591 planned/unplanned. 593 RestartInterval 595 The hitless restart interval in seconds. The range is from 596 1 to 1800 seconds with a suggested default of 120 seconds. 598 B.2 Global Parameters (Optional) 600 RestartHelperSupport 602 The router's support for acting as an OSPF restart helper. 603 Allowable values are none, planned restart only, and 604 planned/unplanned. 606 RestartHelperStrictLSAChecking 608 Indicates whether or not an OSPF restart helper should 609 terminate hitless restart when there is a change to an LSA that 610 would be flooded to the restarting router or when there is a 611 changed LSA on the restarting router's retransmission list 612 when hitless restart is initiated. The suggested default is 613 enabled. 615 C. Change Log (To be removed prior to publication) 617 Changes from 02 to 03 version: 619 1. Add Padma Pillay-Esnault and Acee Lindem as authors to help 620 finish up the draft. 622 Changes from 03 to 04 version: 624 1. Add change log (Appendix B). 625 2. Document that the grace period is restricted to 626 LSRefreshTime (Section 2.1). 627 3. Document an alternative to saving cryptographic sequence 628 numbers in non-volatile storage (Section 2.1). 629 4. Document that an implementation may aggregate multiple 630 adjacencies with a restarting router when entering or exiting 631 helper mode (Section 3.1 and 3.2). 632 5. Document that an implementation may disable graceful 633 restart helper termination when the link-state database 634 changes (Section 3.2). 635 6. In the case of an unplanned restart, document that 636 grace LSAs should be flooded to AllSPFRouters on 637 broadcast networks (Section 5). 638 7. Remove MOSPF from future work. Add Vishwas's suggested 639 technique for less conservative helper mode termination as 640 possible future work (Section 7). 641 8. Change references and citations to meet prevailing IETF 642 standards. 644 Changes from 04 to 05 version: 646 1. Add Appendix B (Configurable Parameters) and make the Change 647 Log Appendix C. 649 Security Considerations 651 One of the ways to attack a link-state protocol such as OSPF is to 652 inject false LSAs into, or corrupt existing LSAs in, the link-state 653 database. Injecting a false grace-LSA would allow an attacker to 654 spoof a router that, in reality, has been withdrawn from service. 655 The standard way to prevent such corruption of the link-state 656 database is to secure OSPF protocol exchanges using the 657 Cryptographic authentication specified in [1]. An even stronger 658 way of securing link-state database contents has been proposed in 659 [3]. 661 Authors' Addresses 663 J. Moy 664 Sycamore Networks, Inc. 665 150 Apollo Drive 666 Chelmsford, MA 01824 667 Phone: (978) 367-2505 668 Fax: (978) 256-4203 669 email: jmoy@sycamorenet.com 671 Padma Pillay-Esnault 672 Juniper Networks 673 1194 N, Mathilda Avenue 674 Sunnyvale, CA 94089-1206 675 Email: padma@juniper.net 677 Acee Lindem 678 Redback Networks 679 102 Carric Bend Court 680 Cary, NC 27519 681 Email: acee@redback.com