idnits 2.17.00 (12 Aug 2021) /tmp/idnits63782/draft-ietf-ospf-hitless-restart-08.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 401: '...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 (July 2003) is 6878 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 675, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 524, 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: December 2003 Acee Lindem, Editor (Redback Networks) 5 File name: draft-ietf-ospf-hitless-restart-08.txt July 2003 7 Graceful OSPF Restart 8 draft-ietf-ospf-hitless-restart-08.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 "graceful 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 43 graceful restart makes assumptions upon the operating environment 44 of the 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 graceful restart .............................. 4 52 2.2 When to exit graceful restart .......................... 5 53 2.3 Actions on exiting graceful 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 8 Intellectual Property ................................. 10 62 References ............................................ 11 63 A Grace-LSA format ...................................... 12 64 B Configurable Parameters ............................... 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 "graceful restart" or "non-stop forwarding". 78 The problem that the OSPF protocol presents to graceful 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 graceful 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 graceful restart are as 95 follows. The router attempting a graceful restart originates 96 link-local Opaque-LSAs, herein called Grace-LSAs, announcing the 97 intention to perform a graceful 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 graceful 106 restart. First there is the router that is being restarted. The 107 operation of this router during graceful restart, including how the 108 router enters and leaves graceful 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 graceful. During graceful 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, Kent Wong, 118 and Don Goodspeed for their helpful comments. We also wish 119 to thank Alex Zinin and Bill Fenner for their thorough review. 121 2. Operation of restarting router 123 After the router restarts/reloads, it must change its OSPF 124 processing somewhat until it re-establishes full adjacencies with 125 all its previously fully-adjacent neighbors. This time period, 126 between the restart/reload and the reestablishment of adjacencies, 127 is called "graceful restart". During graceful restart: 129 (1) The restarting router does not originate LSAs with LS types 130 1-5,7. Instead, the restarting router wants the other routers 131 in the OSPF domain to calculate routes using the LSAs that it 132 had originated prior to its restart. During this time, the 133 restarting router does not modify or flush received self- 134 originated LSAs, (see Section 13.4 of [1]) but instead 135 accepts them as valid. In particular, the grace-LSAs that the 136 restarting router had originated before the restart are left 137 in place. Received self-originated LSAs will be dealt with 138 when the router exits graceful restart (see Section 2.3). 140 (2) The restarting router runs its OSPF routing calculations, as 141 specified in Section 16 of [1]. This is necessary to 142 return any OSPF virtual links to operation. However, the 143 restarting router does *not* install OSPF routes into the 144 system's forwarding table(s), instead relying on the 145 forwarding entries that it had installed prior to the 146 restart. 148 (3) If the restarting router determines that it was Designated 149 Router on a given segment immediately prior to the restart, 150 it elects itself as Designated Router again. The restarting 151 router knows that it was Designated Router if, while the 152 associated interface is in Waiting state, an Hello packet is 153 received from a neighbor listing the router as Designated 154 Router. 156 Otherwise, the restarting router operates the same as any other OSPF 157 router. It discovers neighbors using OSPF's Hello protocol, elects 158 Designated and Backup Designated Routers, performs the Database 159 Exchange procedure to initially synchronize link-state databases 160 with its neighbors, and maintains this synchronization through 161 flooding. 163 The processes of entering graceful restart, and of exiting graceful 164 restart (either successfully or not) are covered in the following 165 sections. 167 2.1. Entering graceful restart 169 The router (call it Router X) is informed of the desire for its 170 graceful restart when an appropriate command is issued by the 171 network operator. The network operator may also specify the 172 length of the grace period, or the necessary grace period may be 173 calculated by the router's OSPF software. In order to avoid 174 the restarting router's LSAs from aging out, the grace period 175 should not exceed LSRefreshTime (1800 second) [1]. 177 In preparation for the graceful restart, Router X must perform 178 the following actions before its software is restarted/reloaded. 179 Note that common OSPF shutdown procedures are *not* performed, 180 since we want the other OSPF routers to act as if Router X 181 remains in continuous service. For example, Router X does not 182 flush its locally originated LSAs, since we want them to remain 183 in other routers' link-state databases throughout the restart 184 period. 186 (1) Router X must ensure that its forwarding table(s) is/are 187 up-to-date and will remain in place across the restart. 189 (2) The router may need to preserve the cryptographic 190 sequence numbers being used on each interface in 191 non-volatile storage. An alternative is to use the 192 router's clock for cryptographic sequence number 193 generation and ensure the clock is preserved across 194 restarts (either on the same or redundant route 195 processors). If neither of these can be guarenteed, it 196 can take up to RouterDeadInterval seconds after the 197 restart before adjacencies can be reestablished and this 198 would force the grace period to be lengthened greatly. 200 Router X then originates the grace-LSAs. These are link-local 201 Opaque-LSAs (see Appendix A). Their LS Age field is set to 0, 202 and the requested grace period (in seconds) is inserted into the 203 body of the grace-LSA. The precise contents of the grace-LSA are 204 described in Appendix A. 206 A grace-LSA is originated for each of the router's OSPF 207 interfaces. If Router X wants to ensure that its neighbors 208 receive the grace-LSAs, it should retransmit the grace-LSAs 209 until they are acknowledged (i.e, perform standard OSPF reliable 210 flooding of the grace-LSAs). If one or more fully adjacent 211 neighbors do not receive grace-LSAs, they will more than likely 212 cause premature termination of the graceful restart procedure 213 (see Section 4). 215 After the grace-LSAs have been sent, the router should store the 216 fact that it is performing graceful restart along with the 217 length of the requested grace period in non-volatile storage. 218 (Note to implementors: It may be easiest to simply store the 219 absolute time of the end of the grace period). The OSPF 220 software should then be restarted/reloaded, and when the 221 reloaded software starts executing the graceful restart 222 modifications in Section 2 above are followed. (Note that prior 223 to the restart, the router does not know whether its neighbors 224 are going to cooperate as "helpers"; the mere reception of 225 grace-LSAs does not imply acceptance of helper 226 responsibilities. This memo assumes that the router would want 227 to restart anyway, even if the restart is not going to be 228 graceful). 230 2.2. When to exit graceful restart 232 A Router X exits graceful restart when any of the following 233 occurs: 235 (1) Router X has reestablished all its adjacencies. Router X 236 can determine this by examining the router-LSAs that it 237 had last originated before the restart (called the "pre- 238 restart router-LSA"), and, on those segments where the 239 router is Designated Router, the pre-restart network- 240 LSAs. These LSAs will have been received from the helping 241 neighbors, and need not have been stored in non-volatile 242 storage across the restart. All previous adjacencies will 243 be listed as type-1 and type 2 links in the router-LSA, 244 and as neighbors in the body of the network-LSA. 246 (2) Router X receives an LSA that is inconsistent with its 247 pre-restart router-LSA. For example, X receives a router- 248 LSA originated by router Y that does not contain a link 249 to X, even though X's pre-start router-LSA did contain a 250 link to Y. This indicates that either a) Y does not 251 support graceful restart, b) Y never received the grace- 252 LSA or c) Y has terminated its helper mode for some 253 reason (Section 3.2). A special case of LSA inconsistency 254 is when Router X establishes an adjacency with router Y 255 and doesn't receive an instance of its own pre-restart 256 router LSA. 258 (3) The grace period expires. 260 2.3. Actions on exiting graceful restart 262 On exiting "graceful restart", the reloaded router reverts back 263 to completely normal OSPF operation, reoriginating LSAs based on 264 the router's current state and updating its forwarding table(s) 265 based on the current contents of the link-state database. In 266 particular, the following actions should be performed when 267 exiting, either successfully or unsuccessfully, graceful 268 restart. 270 (1) The router should reoriginate its router-LSAs for all 271 attached areas, to make sure they have the correct 272 contents. 274 (2) The router should reoriginate network-LSAs on all 275 segments where it is Designated Router. 277 (3) The router reruns its OSPF routing calculations (Section 278 16 of [1]), this time installing the results into the 279 system forwarding table, and originating summary-LSAs, 280 Type-7 LSAs and AS-external-LSAs as necessary. 282 (4) Any remnant entries in the system forwarding table that 283 were installed before the restart, but that are no longer 284 valid, should be removed. 286 (5) Any received self-originated LSAs that are no longer 287 valid should be flushed. 289 (6) Any grace-LSAs that the router had originated should be 290 flushed. 292 3. Operation of helper neighbor 294 The helper relationship is per network segment. As a "helper 295 neighbor" on a segment S for a restarting router X, router Y has 296 several duties. It monitors the network for topology changes, and as 297 long as there are none, continues to its advertise its LSAs as if X 298 had remained in continuous OSPF operation. This means that Y's LSAs 299 continue to list an adjacency to X over network segment S, 300 regardless of the adjacency's current synchronization state. This 301 logic affects the contents of both router-LSAs and network-LSAs, and 302 also depends on the type of network segment S (see Sections 12.4.1.1 303 through 12.4.1.5 and Section 12.4.2 of [1]). When helping over a 304 virtual link, the helper must also continue to set bit V in its 305 router-LSA for the virtual link's transit area (Section 12.4.1 of 306 [1]). 308 Also, if X was the Designated Router on network segment S when the 309 helping relationship began, Y maintains X as Designated router until 310 the helping relationship is terminated. 312 3.1. Entering helper mode 314 When a router Y receives a grace-LSA from router X, it enters 315 helper mode for X, on the associated network segment, as long as 316 all the following checks pass: 318 (1) Y currently has a full adjacency with X (neighbor state 319 Full) over the associated network segment. On broadcast, 320 NBMA and Point-to-MultiPoint segments, the neighbor 321 relationship with X is identified by the IP interface 322 address in the body of the grace-LSA (see Appendix A). On 323 all other segment types X is identified by the grace- 324 LSA's Advertising Router field. 326 (2) There have been no changes in content to the link-state 327 database (LS types 1-5,7) since router X restarted. This 328 is determined as follows. Router Y examines the link- 329 state retransmission list for X over the associated 330 network segment. If there are any LSAs with LS types 331 1-5,7 on the list, then they all must be periodic 332 refreshes. If there are instead LSAs on the list whose 333 contents have changed (see Section 3.3 of [7]), Y must 334 refuse to enter helper mode. Router Y may optionally 335 disallow graceful restart with Router X on other network 336 segments. Determining whether changed LSAs have been 337 successfully flooded to router Y on other network 338 segments is feasible but beyond the scope of this 339 document. 341 (3) The grace period has not yet expired. This means that the 342 LS age of the grace-LSA is less than the grace period 343 specified in the body of the grace-LSA (Appendix A). 345 (4) Local policy allows Y to act as the helper for X. 346 Examples of configured policies might be a) never act as 347 helper, b) never allow the grace period to exceed a Time 348 T, c) only help on software reloads/upgrades, or d) never 349 act as a helper for certain specific routers (specified 350 by OSPF Router ID). 352 (5) Router Y is not in the process of graceful restart. 354 There is one exception to the above requirements. If Y was 355 already helping X on the associated network segment, the new 356 grace-LSA should be accepted and the grace period should be 357 updated accordingly. 359 Note that Router Y may be helping X on some network segments, 360 and not on others. However, that circumstance will probably lead 361 to the premature termination of X's graceful restart, as Y will 362 not continue to advertise adjacencies on the segments where it 363 is not helping (see Section 2.2). 365 Alternately, Router Y may choose to enter enter helper mode 366 when a grace LSA is received and the above checks pass for all 367 adjacencies with Router X. This implemenation alternative 368 of aggregating the adjacencies with respect to helper mode is 369 compatible with implementations considering each adjacency 370 independently. 372 A single router is allowed to simultaneously serve as a helper 373 for multiple restarting neighbors. 375 3.2. Exiting helper mode 377 Router Y ceases to perform the helper function for its neighbor 378 Router X on a given segment when one of the following events 379 occurs. 381 (1) The grace-LSA originated by X on the segment is flushed. 382 This is the successful termination of graceful restart. 384 (2) The grace-LSA's grace period expires. 386 (3) A change in link-state database contents indicates a 387 network topology change, which forces termination of a 388 graceful restart. Specifically, if router Y installs a 389 new LSA in its database with LS types 1-5,7 and having 390 the following two properties, it should cease helping X. 391 The two properties of the LSA are a) the contents of the 392 LSA have changed; this includes LSAs with no previous 393 link-state database instance and the flushing of LSAs 394 from the database, but excludes periodic LSA refreshes 395 (see Section 3.3 of [7]), and b) the LSA would have 396 been flooded to X, had Y and X been fully adjacent. As an 397 example of the second property, if Y installs a changed 398 AS-external-LSA, it should not terminate a helping 399 relationship with a neighbor belonging to a stub area, as 400 that neighbor would not see the AS-external-LSA in any 401 case. An implementation MAY provide a configuration 402 option to disable link-state database options from 403 terminating graceful restart. Such an option will, 404 however, increase the risk of routing loops and 405 black holes. 407 When Router Y exits helper mode for X on a given network 408 segment, it reoriginates its LSAs based on the current state of 409 its adjacency to Router X over the segment. In detail, Y takes 410 the following actions: (a) Y recalculates the Designated Router 411 for the segment, (b) Y reoriginates its router-LSA for the 412 segment's OSPF area, (c) if Y is Designated Router for the 413 segment, it reoriginates the network-LSA for the segment and (d) 414 if the segment was a virtual link, Y reoriginates its router-LSA 415 for the virtual link's transit area. 417 If Router Y aggregated adjacencies with Router X when 418 entering helper mode (as described in section 3.1), it must also 419 exit helper mode for all adjacencies with Router X when any one 420 of the exit events occurs for of adjacency with Router X. 422 4. Backward compatibility 424 Backward-compatibility with unmodified OSPF routers is an automatic 425 consequence of the functionality documented above. If one or more 426 neighbors of a router requesting graceful restart are unmodified, or 427 if they do not received the grace-LSA, the graceful restart converts 428 to a normal OSPF restart. 430 The unmodified routers will start routing around the restarted 431 router X as it performs initial database synchronization, by 432 reissuing their LSAs with links to X omitted. These LSAs will be 433 interpreted by helper neighbors as a topology change, and by X as an 434 LSA inconsistency, in either case reverting to normal OSPF 435 operation. 437 5. Unplanned outages 439 The graceful restart mechanisms in this memo can be used for 440 unplanned outages. (Examples of unplanned outages include the crash 441 of a router's control software, an unexpected switchover to a 442 redundant control processor, etc). However, implementors and network 443 operators should note that attempting graceful restart from an 444 unplanned outage may not be a good idea, owing to the router's 445 inability to properly prepare for the restart (see Section 2.1). In 446 particular, it seems unlikely that a router could guarantee the 447 sanity of its forwarding table(s) across an unplanned restart. In 448 any event, implementors providing the option to recover gracefully 449 from unplanned outages must allow a network operator to turn the 450 option off. 452 In contrast to the procedure for planned restart/reloads that was 453 described in Section 2.1, a router attempting graceful restart after 454 an unplanned outage must originate grace-LSAs *after* its control 455 software resumes operation. The following points must be observed 456 during this grace-LSA origination. 458 o The grace-LSAs must be originated and sent *before* the 459 restarted router sends any OSPF Hello Packets. On broadcast 460 networks, this LSA must be flooded to the AllSPFRouters 461 multicast address (224.0.0.5) since the restarting router is 462 not aware of its previous DR state. 464 o The grace-LSAs are encapsulated in Link State Update Packets and 465 sent out all interfaces, even though the restarted router has no 466 adjacencies and no knowledge of previous adjacencies. 468 o To improve the probability that grace-LSAs be delivered, an 469 implementation may send them a number of times (see for example 470 the Robustness Variable in [8]). 472 o The restart reason in the grace-LSAs must be set to unknown(0). 473 This enables the neighbors to decide whether they want to help 474 the router through an unplanned restart. 476 6. Interaction with Traffic Engineering 478 The operation of the Traffic Engineering Extensions to OSPF [4] 479 during OSPF Graceful Restart is specified in [6]. 481 7. Possible Future Work 483 Devise a less conservative algorithm for graceful restart 484 helper termination that provides a comparable level of 485 black hole and routing loop avoidance. 487 8. Intellectual Property 489 The IETF takes no position regarding the validity or scope of any 490 intellectual property or other rights that might be claimed to 491 pertain to the implementation or use of the technology described in 492 this document or the extent to which any license under such rights 493 might or might not be available; neither does it represent that it 494 has made any effort to identify any such rights. Information on the 495 IETF's procedures with respect to rights in standards-track and 496 standards-related documentation can be found in BCP-11. Copies of 497 claims of rights made available for publication and any assurances of 498 licenses to be made available, or the result of an attempt made to 499 obtain a general license or permission for the use of such 500 proprietary rights by implementors or users of this specification can 501 be obtained from the IETF Secretariat. 503 The IETF invites any interested party to bring to its attention any 504 copyrights, patents or patent applications, or other proprietary 505 rights which may cover technology that may be required to practice 506 this standard. Please address the information to the IETF Executive 507 Director. 509 Normative References 511 [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 513 [2] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 514 1998. 516 Informative References 518 [3] Murphy, S., M. Badger and B. Wellington, "OSPF with Digital 519 Signatures", RFC 2154, June 1997. 521 [4] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering 522 Extensions to OSPF", work in progress. 524 [5] Murphy, P., "The OSPF NSSA Option", RFC 3101, January 2003. 526 [6] Kompella, K., et. al., "Routing Extensions in Support of 527 Generalized MPLS", work in progress. 529 [7] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 530 1793, April 1995. 532 [8] Fenner, W., "Internet Group Membership Protocol, Version 2", 533 RFC 2236, November 1997. 535 A. Grace-LSA format 537 The grace-LSA is a link-local scoped Opaque-LSA [2] having Opaque 538 Type of 3 and Opaque ID equal to 0. Grace-LSAs are originated by a 539 router that wishes to execute a graceful restart of its OSPF 540 software. A grace-LSA requests that the router's neighbors aid it in 541 its graceful restart by continuing to advertise the router as fully 542 adjacent during a specified grace period. 544 Each grace-LSA has LS age field set to 0 when the LSA is first 545 originated; the current value of LS age then indicates how long ago 546 the restarting router made its request. The body of the LSA is TLV- 547 encoded. The TLV-encoded information includes the length of the 548 grace period, the reason for the graceful restart and, when the 549 grace-LSA is associated with a broadcast, NBMA or Point-to- 550 MultiPoint network segment, the IP interface address of the 551 restarting router. 553 0 1 2 3 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | LS age | Options | 9 | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | 3 | 0 | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Advertising Router | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | LS sequence number | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | LS checksum | length | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | | 567 +- TLVs -+ 568 | ... | 570 The format of the TLVs within the body of a grace-LSA is the same as 571 the format used by the Traffic Engineering Extensions to OSPF [4]. 572 The LSA payload consists of one or more nested Type/Length/Value 573 (TLV) triplets for extensibility. The format of each TLV is: 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Type | Length | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Value... | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 The Length field defines the length of the value portion in octets 584 (thus a TLV with no value portion would have a length of zero). The 585 TLV is padded to four-octet alignment; padding is not included in 586 the length field (so a three octet value would have a length of 587 three, but the total size of the TLV would be eight octets). Nested 588 TLVs are also 32-bit aligned. For example, a one byte value 589 would have the length field set to 1, and three bytes of padding 590 would be added to the end of the value portion of the TLV. 591 Unrecognized types are ignored. 593 The following is the list of TLVs that can appear in the body of a 594 grace-LSA. 596 o Grace Period (Type=1, length=4). The number of seconds that the 597 router's neighbors should continue to advertise the router as 598 fully adjacent, regardless of the the state of database 599 synchronization between the router and its neighbors. Since this 600 time period began when grace-LSA's LS age was equal to 0, the 601 grace period terminates when either a) the LS age of the grace- 602 LSA exceeds the value of Grace Period or b) the grace-LSA is 603 flushed. See Section 3.2 for other conditions which terminate 604 the grace period. This TLV must always appear in a grace-LSA. 606 o Graceful restart reason (Type=2, length=1). Encodes the reason 607 for the router restart, as one of the following: 0 (unknown), 1 608 (software restart), 2 (software reload/upgrade) or 3 (switch to 609 redundant control processor). This TLV must always appear in a 610 grace-LSA. 612 o IP interface address (Type=3, length=4). The router's IP 613 interface address on the subnet associated with the grace-LSA. 614 Required on broadcast, NBMA and Point-to-MultiPoint segments, 615 where the helper uses the IP interface address to identify the 616 restarting router (see Section 3.1). 618 DoNotAge is never set in a grace-LSA, even if the grace-LSA is 619 flooded over a demand circuit [7]. This is because the grace-LSA's 620 LS age field is used to calculate the extent of the grace period. 622 Grace-LSAs have link-local scope because they only need to be seen 623 by the router's direct neighbors. 625 Additional Grace-LSA TLVs must be described in an Internet Draft 626 and will be subject to the expert review of the OSPF Working Group. 628 B. Configurable Parameters 630 OSPF graceful restart parameters are suggested below. Section 631 B.1 contains a minimum subset of parameters that should be 632 supported. B.2 includes some additional configuration parameters 633 an implementation may choose to support. 635 B.1 Global Parameters (Minimum subset) 637 RestartSupport 639 The router's level of support for OSPF graceful restart. 640 Allowable values are none, planned restart only, and 641 planned/unplanned. 643 RestartInterval 645 The graceful restart interval in seconds. The range is from 646 1 to 1800 seconds with a suggested default of 120 seconds. 648 B.2 Global Parameters (Optional) 650 RestartHelperSupport 652 The router's support for acting as an OSPF restart helper. 653 Allowable values are none, planned restart only, and 654 planned/unplanned. 656 RestartHelperStrictLSAChecking 658 Indicates whether or not an OSPF restart helper should 659 terminate graceful restart when there is a change to an LSA 660 that would be flooded to the restarting router or when there 661 is a changed LSA on the restarting router's retransmission list 662 when graceful restart is initiated. The suggested default is 663 enabled. 665 Security Considerations 667 One of the ways to attack a link-state protocol such as OSPF is to 668 inject false LSAs into, or corrupt existing LSAs in, the link-state 669 database. Injecting a false grace-LSA would allow an attacker to 670 spoof a router that, in reality, has been withdrawn from service. 671 The standard way to prevent such corruption of the link-state 672 database is to secure OSPF protocol exchanges using the 673 cryptographic authentication specified in [1]. An even stronger 674 way of securing link-state database contents has been proposed in 675 [3]. 677 When crytographic authentication [1] is used on the restarting 678 router the preservation of receive sequence numbers in 679 non-volatile storage is not mandatory. There is a risk that a 680 replayed Hello packet could cause neighbor state for a deceased 681 neighbor to be created. However, the risk is no greater than 682 during normal operation. 684 Authors' Addresses 686 J. Moy 687 Sycamore Networks, Inc. 688 150 Apollo Drive 689 Chelmsford, MA 01824 690 Phone: (978) 367-2505 691 Fax: (978) 256-4203 692 email: jmoy@sycamorenet.com 694 Padma Pillay-Esnault 695 Juniper Networks 696 1194 N, Mathilda Avenue 697 Sunnyvale, CA 94089-1206 698 Email: padma@juniper.net 700 Acee Lindem 701 Redback Networks 702 102 Carric Bend Court 703 Cary, NC 27519 704 Email: acee@redback.com