idnits 2.17.1 draft-ietf-ospf-hitless-restart-01.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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (August 2001) is 8289 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: 'Ref5' is defined on line 423, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2370 (ref. 'Ref2') (Obsoleted by RFC 5250) ** Downref: Normative reference to an Experimental RFC: RFC 2154 (ref. 'Ref3') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref4' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref5' ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. 'Ref6') Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Moy 3 Internet Draft Sycamore Networks, Inc. 4 Expiration Date: February 2002 August 2001 5 File name: draft-ietf-ospf-hitless-restart-01.txt 7 Hitless OSPF Restart 8 draft-ietf-ospf-hitless-restart-01.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 terminates when such 40 a topology change is detected. The restart procedure is also 41 backward-compatible, reverting to standard OSPF processing when one 42 or more of the restarting router's neighbors do not support the 43 enhancements in this memo. Proper network operation during a hitless 44 restart makes assumptions upon the operating environment of the 45 restarting router; these assumptions are also documented. 47 Table of Contents 49 1 Overview ............................................... 2 50 2 Operation of restarting router ......................... 3 51 2.1 Entering hitless restart ............................... 4 52 2.2 Exiting hitless restart ................................ 5 53 3 Operation of helper neighbor ........................... 6 54 3.1 Entering helper mode ................................... 7 55 3.2 Exiting helper mode .................................... 7 56 4 Backward compatibility ................................. 8 57 5 Notes .................................................. 8 58 6 Future Work ............................................ 9 59 References ............................................. 9 60 A Grace-LSA format ...................................... 10 61 Security Considerations ............................... 12 62 Authors' Addresses .................................... 12 64 1. Overview 66 Today many Internet routers implement a separation of control and 67 forwarding functions. Certain processors are dedicated to control 68 and management tasks such as OSPF routing, while other processors 69 perform the data forwarding tasks. This separation creates the 70 possibility of maintaining a router's data forwarding capability 71 while the router's control software is restarted/reloaded. We call 72 such a possibility "hitless restart" or "non-stop forwarding". 74 The problem that the OSPF protocol presents to hitless restart is 75 that, under normal operation, OSPF intentionally routes around a 76 restarting router while it rebuilds its link-state database. OSPF 77 avoids the restarting router to minimize the possibility of routing 78 loops and/or black holes caused by lack of database synchronization. 79 Avoidance is accomplished by having the router's neighbors reissue 80 their LSAs, omitting links to the restarting router. 82 However, if (a) the network topology remains stable and (b) the 83 restarting router is able to keep its forwarding table(s) across the 84 restart, it would be safe to keep the restarting router on the 85 forwarding path. This memo documents an enhancement to OSPF that 86 makes such hitless restart possible, and one that automatically 87 reverts back to standard OSPF for safety when network topology 88 changes are detected. 90 In a nutshell, the OSPF enhancements for hitless restart are as 91 follows. The router attempting a hitless restart originates link- 92 local Opaque-LSAs, herein called Grace-LSAs, announcing the 93 intention to perform a hitless restart, and asking for a "grace 94 period". During the grace period its neighbors continue to announce 95 the restarting router in their LSAs as if it were fully adjacent 96 (i.e., OSPF neighbor state Full), but only if the network topology 97 remains static (i.e, the contents of the LSAs in the link-state 98 database having LS types 1-5,7 remain unchanged; simple refreshes 99 are allowed). 101 There are two roles being played by OSPF routers during hitless 102 restart. First there is the router that is being restarted. The 103 operation of this router during hitless restart, including how the 104 router enters and leaves hitless restart, is the subject of Section 105 2. Then there are the router's neighbors, which must cooperate in 106 order for the restart to be hitless. During hitless restart we say 107 that the neighbors are executing in "helper mode". Section 3 covers 108 the responsibilities of a router executing in helper mode, including 109 entering and leaving helper mode. 111 2. Operation of restarting router 113 After the router restarts/reloads, it must change its OSPF 114 processing somewhat until it re-establishes full adjacencies with 115 all its previously fully-adjacent neighbors. This time period, 116 between the restart/reload and the reestablishment of adjacencies, 117 is called "hitless restart". During hitless restart: 119 (1) The restarting router does not originate LSAs with LS types 120 1-5,7. Instead, the restarting router wants the other routers 121 in the OSPF domain to calculate routes using the LSAs that it 122 had originated prior to its restart. During this time, the 123 restarting router does not modify or flush received self- 124 originated LSAs, (see Section 13.4 of [Ref1]) but instead 125 accepts them as valid. In particular, the grace-LSAs that the 126 restarting router had originated before the restart are left 127 in place. Received self-originated LSAs will be dealt with 128 when the router exits hitless restart (see Section 2.2). 130 (2) The restarting router runs its OSPF routing calculations, as 131 specified in Section 16 of [Ref1]. This is necessary to 132 return any OSPF virtual links to operation. However, the 133 restarting router does *not* install OSPF routes into the 134 system's forwarding table(s), instead relying on the 135 forwarding entries that it had installed prior to the 136 restart. 138 (3) If the restarting router determines that it was Designated 139 Router on a given segment immediately prior to the restart, 140 it elects itself as Designated Router again. The restarting 141 router knows that it was Designated Router if, while the 142 associated interface is in Waiting state, an Hello packet is 143 received from a neighbor listing the router as Designated 144 Router. 146 Otherwise, the restarting router operates the same as any other OSPF 147 router. It discovers neighbors using OSPF's Hello protocol, elects 148 Designated and Backup Designated Routers, performs the Database 149 Exchange procedure to initially synchronize link-state databases 150 with its neighbors, and maintains this synchronization through 151 flooding. 153 The processes of entering hitless restart, and of exiting hitless 154 restart (either successfully or not) are covered in the following 155 sections. 157 2.1. Entering hitless restart 159 The router (call it Router X) is informed of the desire for its 160 hitless restart when an appropriate command is issued by the 161 network operator. The network operator may also specify the 162 length of the grace period, or the necessary grace period may be 163 calculated by the router's OSPF software. 165 In preparation for the hitless restart, Router X must perform 166 the following actions before its software is restarted/reloaded. 167 Note that common OSPF shutdown procedures are *not* performed, 168 since we want the other OSPF routers to act as if Router X 169 remains in continuous service. For example, Router X does not 170 flush its locally originated LSAs, since we want them to remain 171 in other routers' link-state databases throughout the restart 172 period. 174 (1) Router X must ensure that its forwarding table(s) is/are 175 up-to-date and will remain in place across the restart. 177 (2) The router must note in non-volatile storage the 178 cryptographic sequence numbers being used for each 179 interface. Otherwise it will take up to 180 RouterDeadInterval seconds after the restart before it 181 can start to reestablish its adjacencies, which would 182 force the grace period to be lengthened severely. 184 Router X then originates the grace-LSAs. These are link-local 185 Opaque-LSAs (see Appendix A). Their LS Age field is set to 0, 186 and the requested grace period (in seconds) is inserted into the 187 body of the grace-LSA. The precise contents of the grace-LSA are 188 described in Appendix A. 190 A grace-LSA is originated for each of the router's OSPF 191 interfaces. If Router X wants to ensure that its neighbors 192 receive the grace-LSAs, it should retransmit the grace-LSAs 193 until they are acknowledged (i.e, perform standard OSPF reliable 194 flooding of the grace-LSAs). If one or more fully adjacent 195 neighbors do not receive grace-LSAs, they will more than likely 196 cause premature termination of the hitless restart procedure 197 (see Section 4). 199 After the grace-LSAs have been sent, the router should store the 200 fact that it is performing hitless restart along with the length 201 of the requested grace period in non-volatile storage. The OSPF 202 software should then be restarted/reloaded, and when the 203 reloaded software starts executing the hitless restart 204 modifications in Section 2 above are followed. 206 2.2. Exiting hitless restart 208 On exiting "hitless restart", the reloaded router reverts back 209 to completely normal OSPF operation, reoriginating LSAs based on 210 the router's current state and updating its forwarding table(s) 211 based on the current contents of the link-state database. In 212 particular, the following actions should be performed when 213 exiting, either successfully or unsuccessfully, hitless restart. 215 (1) The router should reoriginate its router-LSAs for all 216 attached areas, to make sure they have the correct 217 contents. 219 (2) The router should reoriginate network-LSAs on all 220 segments where it is Designated Router. 222 (3) The router reruns its OSPF routing calculations (Section 223 16 of [Ref1]), this time installing the results into the 224 system forwarding table, and originating summary-LSAs and 225 AS-external-LSAs as necessary. 227 (4) Any remnant entries in the system forwarding table that 228 were installed before the restart, but that are no longer 229 valid, should be removed. 231 (5) Any received self-originated LSAs that are no longer 232 valid should be flushed. 234 (6) Any grace-LSAs that the router had originated should be 235 flushed. 237 The router exits hitless restart when any of the following 238 occurs: 240 (1) Router X has reestablished all its adjacencies. Router X 241 can determine this by building (but not installing or 242 flooding) its router-LSAs, based on the current router 243 state, and comparing it to the router-LSAs that it had 244 last originated before the restart (called the "pre- 245 restart router-LSA"). On those segments where the router 246 is Designated Router, network-LSAs should also be built 247 and compared to those received (if any). If the contents 248 of the built and received LSAs are the same, all 249 adjacencies have been reestablished. 251 (2) Router X receives an LSA that is inconsistent with its 252 pre-restart router-LSA. For example, X receives a router- 253 LSA originated by router Y that does not contain a link 254 to X, even though X's pre-start router-LSA did contain a 255 link to Y. This indicates that either a) Y does not 256 support hitless restart, b) Y never received the grace- 257 LSA or c) Y has terminated its helper mode for some 258 reason (Section 3.2). 260 (3) The grace period expires. 262 3. Operation of helper neighbor 264 The helper relationship is per network segment. As a "helper 265 neighbor" on a segment S for a restarting router X, router Y has 266 several duties. It monitors the network for topology changes, and as 267 long as there are none, continues to its advertise its LSAs as if X 268 had remained in continuous OSPF operation. This means that Y's LSAs 269 continue to list an adjacency to X over network segment S, 270 regardless of the adjacency's current synchronization state. This 271 logic affects the contents of both router-LSAs and network-LSAs, and 272 also depends on the type of network segment S (see Sections 12.4.1.1 273 through 12.4.1.5 and Section 12.4.2 of [Ref1]). When helping over a 274 virtual link, the helper must also continue to set bit V in its 275 router-LSA for the virtual link's transit area (Section 12.4.1 of 276 [Ref1]). 278 Also, if X was the Designated Router on network segment S when the 279 helping relationship began, Y maintains X as Designated router until 280 the helping relationship is terminated. 282 3.1. Entering helper mode 284 When a router Y receives a grace-LSA from router X, it enters 285 helper mode for X, on the associated network segment, as long as 286 all the following checks pass: 288 (1) Y currently has a full adjacency with X (neighbor state 289 Full) over the associated network segment. On broadcast 290 and NBMA segments, the neighbor relationship with X is 291 identified by the IP interface address in the body of the 292 grace-LSA (see Appendix A). On all other segment types X 293 is identified by the grace-LSA's Advertising Router 294 field. 296 (2) There have been no changes in content to the link-state 297 database (LS types 1-5,7) since the beginning of the 298 grace period specified by the grace-LSA. The grace period 299 began N seconds ago, where N is the current LS age of the 300 grace-LSA. 302 (3) The grace period has not yet expired. This means that the 303 LS age of the grace-LSA is less than the grace period 304 specified in the body of the grace-LSA (Appendix A). 306 (4) Local policy allows Y to act as the helper for X. 307 Examples of configured policies might be a) never act as 308 helper, b) never allow the grace period to exceed a Time 309 T, c) only help on software reloads/upgrades, or d) never 310 act as a helper for certain specific routers (specified 311 by OSPF Router ID). 313 Note that Router Y may be helping X on some network segments, 314 and not on others. However, that circumstance will probably lead 315 to the premature termination of X's hitless restart, as Y will 316 not continue to advertise adjacencies on the segments where it 317 is not helping (see Section 2.2). 319 A single router is allowed to simultaneously serve as a helper 320 for multiple restarting neighbors. 322 3.2. Exiting helper mode 324 Router Y ceases to perform the helper function for its neighbor 325 Router X on a given segment when one of the following events 326 occurs. 328 (1) The grace-LSA originated by X on the segment is flushed. 329 This is the successful termination of hitless restart. 331 (2) The grace-LSA's grace period expires. 333 (3) Router Y receives an LSA with LS types 1-5,7 and whose 334 contents have changed. This includes LSAs with no 335 previous link-state database instance and the flushing of 336 LSAs from the database, but excludes simple LSA 337 refreshes. A change in LSA contents indicates a network 338 topology change, which forces termination of a hitless 339 restart. 341 When router Y exits helper mode for X on a given network 342 segment, it reoriginates its LSAs based on the current state of 343 its adjacency to Router X over the segment. In detail, Y takes 344 the following actions: (a) Y recalculates the Designated Router 345 for the segment, (b) Y reoriginates its router-LSA for the 346 segment's OSPF area, (c) if Y is Designated Router for the 347 segment, it reoriginates the network-LSA for the segment and (d) 348 if the segment was a virtual link, Y reoriginates its router-LSA 349 for the virtual link's transit area. 351 4. Backward compatibility 353 Backward-compatibility with unmodified OSPF routers is an automatic 354 consequence of the functionality documented above. If one or more 355 neighbors of a router requesting hitless restart are unmodified, or 356 if they do not received the grace-LSA, the hitless restart is 357 prematurely aborted. 359 The unmodified routers will start routing around the restarted 360 router X as it performs initial database synchronization, by 361 reissuing their LSAs with links to X omitted. These LSAs will be 362 interpreted by helper neighbors as a topology change, and by X as an 363 LSA inconsistency, in either case aborting hitless restart and 364 resuming normal OSPF operation. 366 5. Notes 368 Note the following details concerning the hitless OSPF restart 369 mechanism described in this memo. 371 o DoNotAge is never set in a grace-LSA, even if the grace-LSA is 372 flooded over a demand circuit. This is because the grace-LSA's 373 LS age field is used to calculate the extent of the grace period 374 (see Appendix A). 376 o Grace-LSAs have link-local scope because they only need to be 377 seen by the router's direct neighbors. 379 o It may be noted that the hitless restart mechanisms in this memo 380 can also be used for unplanned outages. For example, after a 381 crash of its control software, the router may come up and send 382 grace-LSAs in an attempt to remain on the forwarding path while 383 it regains its control state. This may not be a good idea, as it 384 seems unlikely that such a router could guarantee the sanity of 385 its forwarding table(s). However, if the router does attempt a 386 hitless restart from an unplanned outage, it should at the least 387 (a) allow the network operator to turn this feature off, (b) 388 attempt to determine when its forwarding tables were last 389 updated, setting the beginning of the grace period accordingly 390 (this means originating the grace-LSA with LS age equal to the 391 time that the forwarding tables were last updated), and (c) set 392 the hitless restart reason in its grace-LSAs to unknown (0). 394 o When comparing the LSAs that the router would build and those 395 that the router has received, in order to determine whether 396 hitless restart is complete, it is sufficient to compare the 397 LSA's length, Options field, and the body of the LSA. The LS 398 age, LS checksum and LS sequence number fields need not match. 399 To cover the possibility that the body of the LSA may have been 400 built in a different order, the standard Internet one's 401 complement checksum of the LSA bodies can be calculated and 402 compared, rather than comparing the bodies byte-for-byte. 404 6. Future Work 406 The interactions between OSPF Hitless Restart and the Traffic 407 Engineering Extensions to OSPF [Ref4] and Multicast Extensions to 408 OSPF [Ref6] have not been specified in this memo. 410 References 412 [Ref1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 414 [Ref2] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 415 1998. 417 [Ref3] Murphy, S., M. Badger and B. Wellington, "OSPF with Digital 418 Signatures", RFC 2154, June 1997. 420 [Ref4] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering 421 Extensions to OSPF", work in progress. 423 [Ref5] Coltun, R., V. Fuller and P. Murphy, "The OSPF NSSA Option", 424 work in progress. 426 [Ref6] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 427 1994. 429 A. Grace-LSA format 431 The grace-LSA is a link-local scoped Opaque-LSA [Ref2] having Opaque 432 Type of 3 and Opaque ID equal to 0. Grace-LSAs are originated by a 433 router that wishes to execute a hitless restart of its OSPF 434 software. A grace-LSA requests that the router's neighbors aid it in 435 its hitless restart by continuing to advertise the router as fully 436 adjacent during a specified grace period. 438 It is assumed that each grace-LSA has LS age field set to 0 when the 439 LSA is first originated; the current value of LS age then indicates 440 how long ago the restarting router made its request. The body of the 441 LSA is TLV-encoded. The TLV-encoded information includes the length 442 of the grace period, the reason for the hitless restart and, when 443 the grace-LSA is associated with a broadcast or NBMA network 444 segment, the IP interface address of the restarting router. 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | LS age | Options | 9 | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | 3 | 0 | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Advertising Router | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | LS sequence number | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | LS checksum | length | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | | 460 +- TLVs -+ 461 | ... | 463 The format of the TLVs within the body of a grace-LSA is the same as 464 the TLV format used by the Traffic Engineering Extensions to OSPF 465 [Ref4]. The TLV header consists of a 16-bit Type field and a 16-bit 466 length field, and is followed by zero or more bytes of value. The 467 length field indicates the length of the value portion in bytes. The 468 value portion is padded to four-octet alignment, but the padding is 469 not included in the length field. For example, a one byte value 470 would have the length field set to 1, and three bytes of padding 471 would be added to the end of the value portion of the TLV. 473 The following is the list of TLVs that can appear in the body of a 474 grace-LSA. 476 o Grace Period (Type=1, length=4). The number of seconds that the 477 router's neighbors should continue to advertise the router as 478 fully adjacent, regardless of the the state of database 479 synchronization between the router and its neighbors. Since this 480 time period began when grace-LSA's LS age was equal to 0, the 481 grace period terminates when either a) the LS age of the grace- 482 LSA exceeds the value of Grace Period or b) the grace-LSA is 483 flushed. See Section 3.2 for other conditions which terminate 484 the grace period. This TLV must always appear in a grace-LSA. 486 o Hitless restart reason (Type=2, length=1). Encodes the reason 487 for the router restart, as one of the following: 0 (unknown), 1 488 (software restart), 2 (software reload/upgrade) or 3 (switch to 489 redundant control processor). This TLV must always appear in a 490 grace-LSA. 492 o IP interface address (Type=3, length=4). The router's IP 493 interface address on the subnet associated with the grace-LSA. 494 Required on broadcast and NBMA segments, where the helper uses 495 the IP interface address to identify the restarting router (see 496 Section 3.1). 498 Security Considerations 500 One of the ways to attack a link-state protocol such as OSPF is to 501 inject false LSAs into, or corrupt existing LSAs in, the link-state 502 database. Injecting a false grace-LSA would allow an attacker to 503 spoof a router that, in reality, has been withdrawn from service. 504 The standard way to prevent such corruption of the link-state 505 database is to secure OSPF protocol exchanges using the Crytographic 506 authentication specified in [Ref1]. An even stronger way of securing 507 link-state database contents has been proposed in [Ref3]. 509 Authors' Addresses 511 J. Moy 512 Sycamore Networks, Inc. 513 150 Apollo Drive 514 Chelmsford, MA 01824 515 Phone: (978) 367-2505 516 Fax: (978) 256-4203 517 email: jmoy@sycamorenet.com