idnits 2.17.1 draft-ietf-ospf-demand-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([2], [3], [4], [8], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (November 1994) is 10754 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 1324 looks like a reference -- Missing reference section? '3' on line 1329 looks like a reference -- Missing reference section? '4' on line 1332 looks like a reference -- Missing reference section? '8' on line 1344 looks like a reference -- Missing reference section? '2' on line 1326 looks like a reference -- Missing reference section? '6' on line 1338 looks like a reference -- Missing reference section? '7' on line 1341 looks like a reference -- Missing reference section? '9' on line 1347 looks like a reference -- Missing reference section? '10' on line 1350 looks like a reference -- Missing reference section? '5' on line 1335 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Moy 2 Internet Draft Cascade 3 Expiration Date: May 1995 November 1994 4 File name: draft-ietf-ospf-demand-01.txt 6 Extending OSPF to support demand circuits 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet- Drafts as 18 reference material or to cite them other than as "work in progress". 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 24 Rim). 26 Abstract 28 This memo defines enhancements to the OSPF protocol that allow 29 efficient operation over "demand circuits". Demand circuits are 30 network segments whose costs vary with usage; charges can be based 31 both on connect time and on bytes/packets transmitted. Examples of 32 demand circuits include ISDN circuits, X.25 SVCs, and dial-up lines. 33 The periodic nature of OSPF routing traffic has until now required a 34 demand circuit's underlying data-link connection to be constantly 35 open, resulting in unwanted usage charges. With the modifications 36 described herein, OSPF Hellos and the refresh of OSPF routing 37 information are suppressed on demand circuits, allowing the 38 underlying data-link connections to be closed when not carrying 39 application traffic. 41 Demand circuits and regular network segments (e.g., leased lines) 42 are allowed to be combined in any manner. In other words, there are 43 no topological restrictions on the demand circuit support. However, 44 while any OSPF network segment can be defined as a demand circuit, 45 only point-to-point networks receive the full benefit. When 46 broadcast and NBMA networks are declared demand circuits, routing 47 update traffic is reduced but the periodic sending of Hellos is not, 48 which in effect still requires that the data-link connections be 49 constantly open. 51 While mainly intended for use with cost-conscious network links such 52 as ISDN, X.25 and dial-up, the modifications in this memo may also 53 prove useful over bandwidth-limited network links such as slow-speed 54 leased lines and packet radio. 56 The enhancements defined in this memo are backward-compatible with 57 the OSPF specification defined in [1], and with the OSPF extensions 58 defined in [3] (OSPF NSSA areas), [4] (MOSPF) and [8] (OSPF Point- 59 to-MultiPoint Interface). 61 This memo provides functionality comparable to that specified for 62 RIP in [2]. However, because OSPF employs link-state routing 63 technology as opposed to RIP's Distance Vector base, the mechanisms 64 used to achieve the functionality are quite different. 66 Please send comments to ospf@gated.cornell.edu. 68 Acknowledgments 70 The author would like to acknowledge the helpful comments of Fred 71 Baker, Rob Coltun, Dawn Li, Gerry Meyer, Tom Pusateri and Zhaohui 72 Zhang. This memo is a product of the OSPF Working Group. 74 Table of Contents 76 1 Model for demand circuits .............................. 4 77 2 Modifications to all OSPF routers ...................... 5 78 2.1 The OSPF Options field ................................. 5 79 2.2 The LS age field ....................................... 5 80 2.3 Removing stale DoNotAge LSAs ........................... 6 81 2.4 A change to the flooding algorithm ..................... 7 82 2.5 Interoperability with unmodified OSPF routers .......... 8 83 2.5.1 Indicating across area boundaries ...................... 9 84 2.5.1.1 Limiting indication-LSA origination ................... 10 85 3 Modifications to demand circuit endpoints ............. 11 86 3.1 Interface State machine modifications ................. 11 87 3.2 Sending and Receiving OSPF Hellos ..................... 11 88 3.2.1 Negotiating Hello suppression ......................... 12 89 3.2.2 Neighbor state machine modifications .................. 12 90 3.3 Flooding over demand circuits ......................... 13 91 3.4 Virtual link support .................................. 14 92 3.5 Point-to-MultiPoint Interface support ................. 15 93 4 Examples .............................................. 16 94 4.1 Example 1: Sole connectivity through demand circuits .. 16 95 4.2 Example 2: Demand and non-demand circuits in parallel . 20 96 4.3 Example 3: Operation when oversubscribed .............. 24 97 5 Topology recommendations .............................. 25 98 6 Lost functionality .................................... 26 99 7 Future work: Oversubscription ......................... 26 100 A Format of the OSPF Options field ...................... 29 101 B Configurable Parameters ............................... 30 102 C Architectural Constants ............................... 30 103 References ............................................ 31 104 Security Considerations ............................... 31 105 Author's Address ...................................... 31 107 1. Model for demand circuits 109 In this memo, demand circuits refer to those network segments whose 110 cost depends on either connect time and/or usage (expressed in terms 111 of bytes or packets). Examples include ISDN circuits and X.25 SVCs. 112 On these circuits, it is desirable for a routing protocol to send as 113 little routing traffic as possible. In fact, when there is no change 114 in network topology it is desirable for a routing protocol to send 115 no routing traffic at all; this allows the underlying data-link 116 connection to be closed when not needed for application data 117 traffic. 119 The model used within this memo for the maintenance of demand 120 circuits is as follows. If there is no data to send (either routing 121 protocol traffic or application data), the data-link connection 122 remains closed. As soon as there is data to be sent, an attempt to 123 open the data-link connection is made (e.g., an ISDN or X.25 call is 124 placed). When/if the data-link connection is established, the data 125 is sent, and the connection stays open until some period of time 126 elapses without more data to send. At this point the data-link 127 connection is again closed, in order to conserve cost and resources 128 (see Section 1 of [2]). 130 The "Presumption of Reachability" described in [2] is also used. 131 Even though a circuit's data-link connection may be closed at any 132 particular time, it is assumed by the routing layer (i.e., OSPF) 133 that the circuit is available unless other information, such as a 134 discouraging diagnostic code resulting from an attempted data-link 135 connection, is present. 137 It may be possible that a data-link connection cannot be established 138 due to resource shortages. For example, a router with a single basic 139 rate ISDN interface cannot open more than two simultaneous ISDN 140 data-link connections (one for each B channel), and limitations in 141 interface firmware and/or switch capacity may limit the number of 142 X.25 SVCs simultaneously supported. When a router cannot 143 simultaneously open all of its circuits' underlying data-link 144 connections due to resource limitations, we say that the router is 145 oversubscribed. In these cases, datagrams to be forwarded out the 146 (temporarily unopenable) data-link connections are discarded, 147 instead of being queued. Note also that this temporary inability to 148 open data-link connections due to oversubscription is NOT reported 149 by the OSPF routing system as unreachability; see Section 4.3 for 150 more information. 152 This memo assumes that either end of a demand circuit can open the 153 underlying data-link connection. Note that this assumption is not 154 true for certain dial-up modems. Also, for some dial network 155 technologies, call collisions can result when both ends of a circuit 156 simultaneously attempt to establish the data-link connection. This 157 memo does not address how such collisions are handled, assuming 158 instead that they are resolved at the data-link level. 160 2. Modifications to all OSPF routers 162 While most of the modifications to support demand circuits are 163 isolated to the demand circuit endpoints (see Section 3), there are 164 changes required of all OSPF routers. These changes are described in 165 the subsections below. 167 2.1. The OSPF Options field 169 A new bit is added to the OSPF Options field to support the 170 demand circuit extensions. This bit is called the "DC-bit". The 171 resulting format of the Options field is described in Appendix 172 A. 174 A router implementing the functionality described in Section 2 175 of this memo sets the DC-bit in the Options field of all LSAs 176 that it originates. This is regardless of the LSAs' LS type, and 177 also regardless of whether the router implements the more 178 substantial modifications required of demand circuit endpoints 179 (see Section 3). Setting the DC-bit in self-originated LSAs 180 tells the rest of the routing domain that the router can 181 correctly process DoNotAge LSAs (see Sections 2.2, 2.3 and 2.5). 183 There is a single exception to the above rule. A router 184 implementing Section 2 of this memo may sometimes originate an 185 "indication-LSA"; these LSAs always have the DC-bit clear. 186 Indication-LSAs are used to convey across area boundaries the 187 existence of routers incapable of DoNotAge processing; see 188 Section 2.5.1 for details. 190 2.2. The LS age field 192 The semantics of the LSA's LS age field are changed, allowing 193 the high bit to be set. This bit is called "DoNotAge"; see 194 Appendix C for its formal definition. LSAs whose LS age field 195 have the DoNotAge bit set are not aged while they are held in 196 the link state database, which means that they do not have to be 197 refreshed every LSRefreshInterval as is done with all other OSPF 198 LSAs. 200 By convention, in the rest of this memo we will express LS age 201 fields having the DoNotAge set as "DoNotAge+x", while an LS age 202 expressed as just "x" is assumed to not have the DoNotAge bit 203 set. LSAs having DoNotAge set are also sometimes referred to as 204 "DoNotAge LSAs". 206 When comparing two LSA instances to see which one is most 207 recent, the two LSAs' LS age fields are compared whenever the LS 208 sequence numbers and LS checksums are found identical (see 209 Section 13.1 of [1]). Before comparing, the LS age fields must 210 have their DoNotAge bits masked off. For example, in 211 determining which LSA is more recent, LS ages of 1 and 212 DoNotAge+1 are considered equivalent; an LSA flooded with LS age 213 of 1 may be acknowledged with a Link State Acknowledgement 214 listing an LS age of DoNotAge+1, or vice versa. In particular, 215 DoNotAge+MaxAge is equivalent to MaxAge; however for backward- 216 compatibility the MaxAge form should always be used when 217 flushing LSAs from the routing domain (see Section 14.1 of [1]). 219 Thus, the set of allowable values for the LS age field fall into 220 the two ranges: 0 through MaxAge and DoNotAge through 221 DoNotAge+MaxAge. (Previously the LS age field could not exceed 222 the value of MaxAge.) Any LS age field not falling into these 223 two ranges should be considered to be equal to MaxAge. 225 When an LSA is flooded out an interface, the constant 226 InfTransDelay is added to the LSA's LS age field. This happens 227 even if the DoNotAge bit is set; in this case the LS age field 228 is not allowed to exceed DoNotAge+MaxAge. If the LS age field 229 reaches DoNotAge+MaxAge during flooding, the LSA is flushed from 230 the routing domain. This preserves the protection in [1] 231 afforded against flooding loops. 233 The LS age field is not checksum protected. Errors in a router's 234 memory may mistakenly set an LSA's DoNotAge bit, stopping the 235 aging of the LSA. However, a router should note that its own 236 self-originated LSAs should never have the DoNotAge bit set in 237 its own database. This means that in any case the router's 238 self-originated LSAs will be refreshed every LSRefreshInterval. 239 As this refresh is flooded throughout the OSPF routing domain, 240 it will replace any LSA copies in other routers' databases whose 241 DoNotAge bits were mistakenly set. 243 2.3. Removing stale DoNotAge LSAs 245 Because LSAs with the DoNotAge bit set are never aged, they can 246 stay in the link state database even when the originator of the 247 LSA no longer exists. To ensure that these LSAs are eventually 248 flushed from the routing domain, and that the size of the link 249 state database doesn't grow without bound, routers are required 250 to flush a DoNotAge LSA if both of the following conditions are 251 met: 253 (1) The LSA has been in the router's database for at least 254 MaxAge seconds. 256 (2) The originator of the LSA has been unreachable (according to 257 the routing calculations specified by Section 16 of [1]) for 258 at least MaxAge seconds. 260 For an example, see Time T8 in the example of Section 4.1. Note 261 that the above functionality is an exception to the general OSPF 262 rule that a router can only flush (i.e., prematurely age; see 263 Section 14.1 of [1]) its own self-originated LSAs. The above 264 functionality pertains only to DoNotAge LSAs. An LSA having 265 DoNotAge clear still can be prematurely aged only by its 266 originator; otherwise, the LSA must age naturally to MaxAge 267 before being removed from the routing domain. 269 An interval as long as MaxAge has been chosen to avoid any 270 possibility of thrashing (i.e., flushing an LSA only to have it 271 reoriginated soon afterwards). Note that by the above rules, a 272 DoNotAge LSA will be removed from the routing domain no faster 273 than if it were being aged naturally (i.e., if DoNotAge were not 274 set). 276 2.4. A change to the flooding algorithm 278 The following change is made to the OSPF flooding algorithm. 279 When a Link State Update Packet is received that contains an LSA 280 instance which is actually less recent than the the router's 281 current database copy, the router must now respond by sending 282 its database copy (encapsulated in a Link State Update Packet) 283 back to the sending neighbor. When doing so, the LSA is NOT 284 added to the neighbor's link state retransmission list. The 285 previous behavior was to ignore the flood of the less recent LSA 286 instance; see Step 8 of Section 13 in [1]. 288 This change is necessary to support flooding over demand 289 circuits. For example, see Time T4 in the example of Section 290 4.2. 292 However, this change is beneficial when flooding over non-demand 293 interfaces as well. For this reason, the flooding change 294 pertains to all interfaces, not just interfaces to demand 295 circuits. The main example involves MaxAge LSAs. There are times 296 when MaxAge LSAs stay in a router's database for extended 297 intervals: 1) when they are stuck in a retransmission queue on a 298 slow link or 2) when a router is not properly flushing them from 299 its database, due to software bugs. The prolonged existence of 300 these MaxAge LSAs can inhibit the flooding of new instances of 301 the LSA. New instances typically start with the initial LS 302 sequence number, and are treated as less recent (and hence 303 discarded) by routers still holding MaxAge instances. However, 304 with the above change to flooding, a router with a MaxAge 305 instance will respond back with the MaxAge instance. This will 306 get back to the LSA's originator, which will then pick the next 307 highest LS sequence number and reflood, overwriting the MaxAge 308 instance. 310 This change will be included in future revisions of the base 311 OSPF specification [1]. 313 2.5. Interoperability with unmodified OSPF routers 315 Unmodified OSPF routers will probably treat DoNotAge LSAs as if 316 they had LS age of MaxAge. At the very worst, this will cause 317 continual retransmissions of the DoNotAge LSAs. (An example 318 scenario follows. Suppose Routers A and B are connected by a 319 point-to-point link. Router A implements the demand circuit 320 extensions, Router B does not. Neither one treats their 321 connecting link as a demand circuit. At some point in time, 322 Router A receives from another neighbor via flooding a DoNotAge 323 LSA. The DoNotAge LSA is then flooded by Router A to Router B. 324 Router B, not understanding DoNotAge LSAs, treats it as a MaxAge 325 LSA and acknowledges it as such to Router A. Router A receives 326 the acknowledgment, but notices that the acknowledgment is for a 327 different instance, and so starts retransmitting the LSA.) 329 However, to avoid this confusion, DoNotAge LSAs will be allowed 330 in an OSPF area if and only if, in the area's link state 331 database, all LSAs have the DC-bit set in their Options field 332 (see Section 2.1). Note that it is not required that the LSAs' 333 Advertising Router be reachable; if any LSA is found not having 334 its DC-bit set (regardless of reachability), then the router 335 should flush (i.e., prematurely age; see Section 14.1 of [1]) 336 from the area all DoNotAge LSAs. These LSAs will then be 337 reoriginated at their sources, this time with DoNotAge clear. 338 Like the change in Section 2.3, this change is an exception to 339 the general OSPF rule that a router can only flush its own 340 self-originated LSAs. Both changes pertain only to DoNotAge 341 LSAs, and in both cases a flushed LSA's LS age field should be 342 set to MaxAge and not DoNotAge+MaxAge. 344 2.5.1. Indicating across area boundaries 346 AS-external-LSAs are flooded throughout the entire OSPF 347 routing domain, excepting only OSPF stub areas and NSSAs. 348 For that reason, if an OSPF router that is incapable of 349 DoNotAge processing exists in any "regular" area (i.e., an 350 area that is not a stub nor an NSSA), no AS-external-LSA can 351 have DoNotAge set. This memo simplifies that requirement by 352 broadening it to the following rule: LSAs in regular OSPF 353 areas are allowed to have DoNotAge set if and only if every 354 router in the OSPF domain (excepting those in stub areas and 355 NSSAs) is capable of DoNotAge processing. The rest of this 356 section describes how the rule is implemented. 358 As described above in Sections 2.1 and 2.5, a router 359 indicates that it is capable of DoNotAge processing by 360 setting the DC-bit in the LSAs that it originates. However, 361 there is a problem. It is possible that, in all areas to 362 which Router X directly attaches, all the routers are 363 capable of DoNotAge processing, yet there is some router in 364 a remote "regular" area that cannot process DoNotAge LSAs. 365 This information must then be conveyed to Router X, so that 366 it does not mistakenly flood/create DoNotAge LSAs. 368 The solution is as follows. Area border routers transmit the 369 existence of DoNotAge-incapable routers across area 370 boundaries, using "indication-LSAs". Indication-LSAs are 371 type-4-summary LSAs (also called ASBR-summary-LSAs), listing 372 the area border router itself as the described ASBR, with 373 the LSA's cost set to LSInfinity and the DC-bit clear. Note 374 that indication-LSAs convey no additional information; in 375 particular, they are used even if the area border router is 376 not really an AS boundary router (ASBR). 378 Taking indication-LSAs into account, the rule as to whether 379 DoNotAge LSAs are allowed in any particular area is EXACTLY 380 the same as given previously in Section 2.5, namely: 381 DoNotAge LSAs will be allowed in an OSPF area if and only 382 if, in the area's link state database, all LSAs have the 383 DC-bit set in their Options field. 385 Through origination of indication-LSAs, the existence of 386 DoNotAge-incapable routers can be viewed as going from non- 387 backbone regular areas, to the backbone area and from there 388 to all other regular areas. The following two cases 389 summarize the requirements for an area border router to 390 originate indication-LSAs: 392 (1) Suppose an area border router (Router X) is connected to 393 a regular non-backbone OSPF area (Area A). Furthermore, 394 assume that Area A has LSAs with the DC-bit clear, other 395 than indication-LSAs. Then Router X should originate 396 indication-LSAs into all other directly-connected 397 "regular" areas, including the backbone area, keeping 398 the guidelines of Section 2.5.1.1 in mind. 400 (2) Suppose an area border router (Router X) is connected to 401 the backbone OSPF area (Area 0.0.0.0). Furthermore, 402 assume that the backbone has LSAs with the DC-bit clear 403 that are either a) not indication-LSAs or b) 404 indication-LSAs that have been originated by routers 405 other than Router X itself. Then Router X should 406 originate indication-LSAs into all other directly- 407 connected "regular" non-backbone areas, keeping the 408 guidelines of Section 2.5.1.1 in mind. 410 2.5.1.1. Limiting indication-LSA origination 412 To limit the number of indication-LSAs originated, the 413 following guidelines should be observed by an area 414 border router (Router X) when originating indication- 415 LSAs. First, indication-LSAs are not originated into an 416 Area A when A already has LSAs with DC-bit clear other 417 than indication-LSAs. Second, if another area border 418 router has originated a indication-LSA into Area A, and 419 that area border router has a higher OSPF Router ID than 420 Router X (same tie-breaker as for forwarding address 421 origination; see Section 12.4.5 of [1]), then Router X 422 should not originate an indication-LSA into Area A. 424 As an example, suppose that three regular OSPF areas 425 (Areas A, B and C) are connected by routers X, Y and Z 426 (respectively) to the backbone area. Furthermore, 427 suppose that all routers are capable of DoNotAge 428 processing, except for routers in Areas A and B. 429 Finally, suppose that Router Z has a higher Router ID 430 than Y, which in turn has a higher Router ID than X. In 431 this case, two indication-LSAs will be generated (if the 432 rules of Section 2.5.1 and the guidelines of the 433 preceding paragraph are followed): Router Y will 434 originate an indication-LSA into the backbone, and 435 Router Z will originate an indication-LSA into Area C. 437 3. Modifications to demand circuit endpoints 439 The following subsections detail the modifications required of the 440 routers at the endpoints of demand circuits. These consist of 441 modifications to two main pieces of OSPF: 1) sending and receiving 442 Hello Packets over demand circuits and 2) flooding LSAs over demand 443 circuits. 445 An additional OSPF interface configuration parameter, 446 DemandInterface, is defined to indicate whether an OSPF interface 447 connects to a demand circuit (see Appendix B). Two routers 448 connecting to a common network segment need not agree on that 449 segment's demand circuit status. However, to get full benefit of the 450 demand circuit extensions, the two ends of a point-to-point link 451 must both agree to treat the link as a demand circuit (see Section 452 3.2). 454 3.1. Interface State machine modifications 456 An OSPF point-to-point interface connecting to a demand circuit 457 is considered to be in state "Point-to-point" if and only if its 458 associated neighbor is in state "1-Way" or greater; otherwise 459 the interface is considered to be in state "Down". Hellos are 460 sent out such an interface when it is in "Down" state, at the 461 reduced interval of PollInterval. If the negotiation in Section 462 3.2.1 succeeds, Hellos will cease to be sent out the interface 463 whenever the associated neighbor reaches state "Full". 465 Note that as a result, an "LLDown" event for the point-to-point 466 demand circuit's neighbor forces both the neighbor and the 467 interface into state "Down" (see Section 3.2.2). 469 For OSPF broadcast and NBMA networks that have been configured 470 as demand circuits, there are no changes to the Interface State 471 Machine. 473 3.2. Sending and Receiving OSPF Hellos 475 The following sections describe the required modifications to 476 OSPF Hello Packet processing on point-to-point demand circuits. 478 For OSPF broadcast and NBMA networks that have been configured 479 as demand circuits, there is no change to the sending and 480 receiving of Hellos, nor are there any changes to the Neighbor 481 State Machine. This is because the proper operation of the 482 Designated Router election algorithm requires periodic exchange 483 of Hello Packets. 485 3.2.1. Negotiating Hello suppression 487 On point-to-point demand circuits, both endpoints must agree 488 to suppress the sending of Hello Packets. To ensure this 489 agreement, a router sets the DC-bit in OSPF Hellos and 490 Database Description Packets sent out the demand interface. 491 Receiving an Hello or a Database Description Packet with the 492 DC-bit set indicates agreement. Receiving an Hello with the 493 DC-bit clear and also listing the router's Router ID in the 494 body of the Hello message, or a Database Description Packet 495 with the DC-bit clear (either one indicating bidirectional 496 connectivity) indicates that the other end refuses to 497 suppress Hellos. In these latter cases, the router reverts 498 to the normal periodic sending of Hello Packets out the 499 interface (see Section 9.5 of [1]). 501 A demand point-to-point circuit need be configured in only 502 one of the two endpoints (see Section 4.1). If a router 503 implementing Sections 2 and 3 of this memo receives an Hello 504 Packet with the DC-bit set, it should treat the point-to- 505 point link as a demand circuit, making the appropriate 506 changes to its Hello Processing (see Section 3.2.2) and 507 flooding (see Section 3.3). 509 Even if the above negotiation fails, the router should 510 continue setting the DC-bit in its Hellos and Database 511 Descriptions (the neighbor will just ignore the bit). The 512 router will then automatically attempt to renegotiate Hello 513 suppression whenever the link goes down and comes back up. 514 For example, if the neighboring router is rebooted with 515 software that is capable of operating over demand circuits 516 (i.e., implements Sections 2 and 3 of this memo), a future 517 negotiation will succeed. 519 Also, even if the negotiation to suppress Hellos fails, the 520 flooding modifications described in Section 3.3 are still 521 performed over the link. 523 3.2.2. Neighbor state machine modifications 525 When the above negotiation succeeds, Hello Packets are sent 526 over point-to-point demand circuits only until initial 527 link-state database synchronization is achieved with the 528 neighbor (i.e., the state of the neighbor connection reaches 529 "Full", as defined in Section 10.1 of [1]). After this, 530 Hellos are suppressed and the data-link connection to the 531 neighbor is assumed available until evidence is received to 532 the contrary. When the router finds that the neighbor is no 533 longer available, presumably from something like a 534 diagnostic code contained in a response to a failed call 535 request, the neighbor connection transitions back to "Down" 536 and Hellos are sent periodically (at Intervals of 537 PollInterval) in an attempt to restart synchronization with 538 the neighbor. 540 This requires changes to the OSPF Neighbor State Machine 541 (see Section 10.3 of [1]). The receipt of Hellos from demand 542 circuit neighbors in state "Loading" or "Full" can no longer 543 be required. In other words, the InactivityTimer event 544 defined in Section 10.2 of [1] has no effect on demand 545 circuit neighbors in state "Loading" or "Full". An 546 additional clarification is needed in the Neighbor State 547 Machine's LLDown event. For demand circuits, this event 548 should be mapped into the "discouraging diagnostic code" 549 discussed previously in Section 1, and should not be 550 generated when the data-link connection has been closed 551 simply to save resources. Nor should LLDown be generated if 552 a data-link connection fails due to temporary lack of 553 resources. 555 3.3. Flooding over demand circuits 557 Flooding over demand circuits (point-to-point or otherwise) is 558 modified if and only if all routers have indicated that they can 559 process LSAs having DoNotAge set. This is determined by 560 examining the link state database of the OSPF area containing 561 the demand circuit. All LSAs in the database must have the DC- 562 bit set. If one or more LSAs have the DC-bit clear, flooding 563 over demand circuits is unchanged from [1]. Otherwise, flooding 564 is changed as follows. 566 (1) Only truly changed LSAs are flooded over demand circuits. 567 When a router receives a new LSA instance, it checks first 568 to see whether the contents have changed. If not, the new 569 LSA is simply a periodic refresh and it is not flooded out 570 attached demand circuits (it is still flooded out other 571 interfaces however). This check should be performed in Step 572 5b of Section 13 in [1]. When comparing an LSA to its 573 previous instance, the following are all considered to be 574 changes in contents: 576 o The LSA's Options field has changed. 578 o One or both of the LSA instances has LS age set to 579 MaxAge (or DoNotAge+MaxAge). 581 o The length field in the LSA header has changed. 583 o The contents of the LSA, excluding the 20-byte link 584 state header, have changed. Note that this excludes 585 changes in LS Sequence Number and LS Checksum. 587 (2) When it has been decided to flood an LSA over a demand 588 circuit, DoNotAge should be set in the copy of the LSA that 589 is flooded out the demand interface. (There is one 590 exception: DoNotAge should not be set if the LSA's LS age is 591 equal to MaxAge.) Setting DoNotAge will cause the routers on 592 the other side of the demand circuit to hold the LSA in 593 their databases indefinitely, removing the need for periodic 594 refresh. Note that it is perfectly possible that DoNotAge 595 will already be set. This simply indicates that the LSA has 596 already been flooded over demand circuits. In any case, the 597 flooded copy's LS age field must also be incremented by 598 InfTransDelay (see Step 5 of Section 13.3 in [1], and 599 Section 2.2 of this memo), as protection against flooding 600 loops. 602 The previous paragraph also pertains to LSAs flooded over 603 demand circuits in response to Link State Requests. It also 604 pertains to LSAs that are retransmitted over demand 605 circuits. 607 3.4. Virtual link support 609 OSPF virtual links are essentially unnumbered point-to-point 610 links (see Section 15 of [1]). Accordingly, demand circuit 611 support for virtual links resembles that described for point- 612 to-point links in the previous sections. The main difference is 613 that a router implementing Sections 2 and 3 of this memo, and 614 supporting virtual links, always treats virtual links as if they 615 were demand circuits. Otherwise, when a virtual link's 616 underlying physical path contains one or more demand circuits, 617 periodic OSPF protocol exchanges over the virtual link would 618 unnecessarily keep the underlying demand circuits open. 620 Demand circuit support on virtual links can be summarized as 621 follows: 623 o Instead of modifying the Interface state machine for virtual 624 links as was done for point-to-point links in Section 3.1, 625 the Interface state machine for virtual links remains 626 unchanged. A virtual link is considered to be in state 627 "Point-to-point" if an intra-area path (through the virtual 628 link's transit area) exists to the other endpoint. Otherwise 629 it is considered to be in state "Down". See Section 15 of 630 [1] for more details. 632 o Virtual links are always treated as demand circuits. In 633 particular, over virtual links a router always negotiates to 634 suppress the sending of Hellos. See Sections 3.2.1 and 3.2.2 635 for details. 637 o In the demand circuit support over virtual links, there is 638 no "discouraging diagnostic code" as described in Section 1. 639 Instead, the connection is considered to exist if and only 640 if an intra-area path (through the virtual link's transit 641 area) exists to the other endpoint. See Section 15 of [1] 642 for more details. 644 o Since virtual links are always treated as demand circuits, 645 flooding over virtual links always proceeds as in Section 646 3.3. 648 3.5. Point-to-MultiPoint Interface support 650 The OSPF Point-to-MultiPoint interface has recently been 651 developed for use with non-mesh-connected network segments. A 652 common example is a Frame Relay subnet where PVCs are 653 provisioned between some pairs of routers, but not all pairs. In 654 this case the Point-to-Multipoint interface represents the 655 single physical interface to the Frame relay network, over which 656 multiple point-to-point OSPF conversations (one on each PVC) are 657 taking place. For more information on the Point-to-MultiPoint 658 interface, see [8]. 660 Since an OSPF Point-to-MultiPoint interface essentially consists 661 of multiple point-to-point connections, demand circuit support 662 on the Point-to-Multipoint interface strongly resembles demand 663 circuit support for point-to-point links. However, since the 664 Point-to-MultiPoint interface requires commonality of its 665 component point-to-point links' configurations, there are some 666 differences. 668 Demand circuit support on Point-to-Multipoint interfaces can be 669 summarized as follows: 671 o Instead of modifying the Interface state machine for Point- 672 to-Multipoint interfaces as was done for point-to-point 673 links in Section 3.1, the Interface state machine for 674 Point-to-Multipoint interfaces remains unchanged. 676 o When a Point-to-MultiPoint interface is configured as a 677 DemandInterface, it tries to negotiate Hello suppression 678 separately on each of its component point-to-point links. 679 This negotiation proceeds as in Section 3.2.1. Negotiation 680 may fail on some component point-to-point links, and succeed 681 on others. This is acceptable. On those component links 682 where the negotiation fails, Hellos will always be sent; 683 otherwise, Hellos will cease to be sent when the Database 684 Description process completes on the component link (see 685 Section 3.2.2). 687 o Section 3.3 defines the demand circuit flooding behavior for 688 all OSPF interface types. This includes Point-to-Multipoint 689 interfaces. 691 4. Examples 693 This section gives three examples of the operation over demand 694 circuits. The first example is probably the most common and 695 certainly the most basic. It shows a single point-to-point demand 696 circuit connecting two routers. The second illustrates what happens 697 when demand circuits and leased lines are used in parallel. The 698 third explains what happens when a router has multiple demand 699 circuits and cannot keep them all open (for resource reasons) at the 700 same time. 702 4.1. Example 1: Sole connectivity through demand circuits 704 Figure 1 shows a sample internetwork with a single demand 705 circuit providing connectivity to the LAN containing Host H2. 706 Assume that all three routers (RTA, RTB and RTC) have 707 implemented the functionality in Section 2 of this memo, and 708 thus will be setting the DC-bit in their LSAs. Furthermore 709 assume that Router RTB has been configured to treat the link to 710 Router RTC as a demand circuit, but Router RTC has not been so 711 configured. Finally assume that the LAN interface connecting 712 Router RTA to Host H1 is initially down. 714 The following sequence of events may then transpire, starting 715 with Router RTB booting and bringing up its link to Router RTC: 717 Time T0: RTB negotiates Hello suppression 719 Router RTB will start sending Hellos over the demand circuit 720 with the DC-bit set in the Hello's Options field. Because 721 RTC is not configured to treat the link as a demand circuit, 722 the first Hello received from RTC will not have the DC-bit 723 set. However, subsequent Hellos and Database Description 724 + + + 725 | +---+ | | 726 +--+ |---|RTA|---| | +--+ 727 |H1|---| +---+ | |---|H2| 728 +--+ | | +---+ ODL +---+ | +--+ 729 |LAN Y |---|RTB|-------------|RTC|---| 730 + | +---+ +---+ | 731 + + 733 Figure 1: In the example of Section 4.1, 734 a single demand circuit (labeled 735 ODL) bisects an internetwork. 737 Packets received from RTC will have the DC-bit set, 738 indicating that the two routers have agreed that the link 739 will be treated as a demand circuit. The entire negotiation 740 is pictured in Figure 2. Note that if RTC were unable or 741 unwilling to suppress Hellos on the link, the initial 742 Database Description sent from Router RTC to RTB would have 743 the DC-bit clear, forcing Router RTB to revert to the 744 periodic sending of Hellos specified in Section 9.5 of [1]. 746 Time T1: Database exchange over demand circuit 748 The initial synchronization of link state databases (the 749 Database Exchange Process) over the demand circuit then 750 occurs as over any point-to-point link, with one exception. 752 +---+ +---+ 753 |RTB| |RTC| 754 +---+ +---+ 755 Hello (DC-bit set) 756 -------------------------------------> 757 Hello (DC-bit clear) 758 <------------------------------------- 759 Hello (DC-bit set, RTC seen) 760 -------------------------------------> 761 Database Description (DC-bit set) 762 <------------------------------------- 764 Figure 2: Successful negotiation of Hello 765 suppression. 767 LSAs included in Link State Updates Packets sent over the 768 demand circuit (in response to Link State Request Packets), 769 will have the DoNotAge bit set in their LS age field. So, 770 after the Database Exchange Process is finished, all routers 771 will have 3 LSAs in their link state databases (router-LSAs 772 for Routers RTA, RTB and RTC), but the LS age fields 773 belonging to the LSAs will vary depending on which side of 774 the demand circuit they were originated from (see Table 1). 775 For example, all routers other than Router RTC have the 776 DoNotAge bit set in Router RTC's router-LSA; this removes 777 the need for Router RTC to refresh its router-LSA over the 778 demand circuit. 780 Time T2: Hello traffic ceases 782 After the Database Exchange Process has completed, no Hellos 783 are sent over the demand circuit. If there is no application 784 data to be sent over the demand circuit, the circuit will be 785 idle. 787 Time T3: Underlying data-link connection torn down 789 After some period of inactivity, the underlying data-link 790 connection will be torn down (e.g., an ISDN call would be 791 cleared) in order to save connect charges. This will be 792 transparent to the OSPF routing; no LSAs or routing table 793 entries will change as a result. 795 LS age 796 LSA in RTB in RTC 797 ______________________________________________ 798 RTA's Router-LSA 1000 DoNotAge+1001 799 RTB's Router-LSA 10 DoNotAge+11 800 RTC's Router-LSA DoNotAge+11 10 802 Table 1: After Time T1 in Section 4.1, 803 possible LS age fields on either 804 side of the demand circuit 806 Time T4: Router RTA's LSA is refreshed 808 At some point Router RTA will refresh its own router-LSA 809 (i.e., when the LSA's LS age hits LSRefreshInterval). This 810 refresh will be flooded to Router RTB, who will look at it 811 and decide NOT to flood it over the demand circuit to Router 812 RTC, because the LSA's contents have not really changed 813 (only the LS Sequence Number). At this point, the LS 814 sequence numbers that the routers have for RTA's router-LSA 815 differ depending on which side of the demand circuit the 816 routers lie. Because there is still no application traffic, 817 the underlying data-link connection remains disconnected. 819 Time T5: Router RTA's LAN interface comes up 821 When Router RTA's LAN interface (connecting to Host H1) 822 comes up, RTA will originate a new router-LSA. This router- 823 LSA WILL be flooded over the demand circuit because its 824 contents have now changed. The underlying data-link 825 connection will have to be brought up to flood the LSA. 826 After flooding, routers on both sides of the demand circuit 827 will again agree on the LS Sequence Number for RTA's 828 router-LSA. 830 Time T6: Underlying data-link connection is torn down again 832 Assuming that there is still no application traffic 833 transiting the demand circuit, the underlying data-link 834 connection will again be torn down after some period of 835 inactivity. 837 Time T7: File transfer started between Hosts H1 and H2 839 As soon as application data needs to be sent across the 840 demand circuit the underlying data-link connection is 841 brought back up. 843 Time T8: Physical link becomes inoperative 845 If an indication is received from the data-link or physical 846 layers indicating that the demand circuit can no longer be 847 established, Routers RTB and RTC declare their point-to- 848 point interfaces down, and originate new router-LSAs. Both 849 routers will attempt to bring the connection back up by 850 sending Hellos at the reduced rate of PollInterval. Note 851 that while the connection is inoperative, Routers RTA and 852 RTB will continue to have an old router-LSA for RTC in their 853 link state database, and this LSA will not age out because 854 it has the DoNotAge bit set. However, according to Section 855 2.3 they will flush Router RTC's router-LSA if the demand 856 circuit remains inoperative for longer than MaxAge. 858 4.2. Example 2: Demand and non-demand circuits in parallel 860 This example demonstrates the demand circuit functionality when 861 both demand circuits and non-demand circuits (e.g., leased 862 lines) are used to interconnect regions of an internetwork. Such 863 an internetwork is shown in Figure 3. Host H1 can communicate 864 with Host H2 either over the demand link between Routers RTB and 865 RTC, or over the leased line between Routers RTB and RTD. 867 Because the basic properties of the demand circuit functionality 868 were presented in the previous example, this example will only 869 address the unique issues involved when using both demand and 870 non-demand circuits in parallel. 872 Assume that Routers RTB and RTY are powered off, but that all 873 other routers and their attached links are both operational and 874 implement the demand circuit modifications to OSPF. Throughout 875 the example, a TCP connection between Hosts H1 and H2 is 876 transmitting data. Furthermore, assume that the cost of the 877 demand circuit from RTB to RTC has been set considerably higher 878 than the cost of the leased line between RTB and RTD; for this 879 reason traffic between Hosts H1 and H2 will always be sent over 880 the leased line when it is operational. 882 The following events may then transpire: 884 Time T0: Router RTB comes up. 886 Assume RTB supports the demand circuit OSPF modifications. 887 When Router RTB comes up and establishes links to Routers 888 RTC and RTD, it will flood the same information over both. 889 However, LSAs sent over the demand circuit (to Router RTC) 890 will have the DoNotAge bit set, while those sent over the 891 leased line to Router RTD will not. Because the DoNotAge bit 892 is not taken into account when comparing LSA instances, the 893 routers on the right side of RTB (RTC, RTE and RTD) may or 894 may not have the DoNotAge bit set in their database copies 895 of RTA's and RTB's router-LSAs. This depends on whether the 896 LSAs sent over the demand link reach the routers before 897 those sent over the leased line. One possibility is pictured 898 in Table 2. 900 + 901 +---+ | 902 |RTC|--| + 903 +---+ | +---+ | 904 + / |--|RTE|--| +--+ 905 +--+ | /ODL | +---+ |--|H2| 906 |H1|----| +---+ +---+/ | + +--+ 907 +--+ |--|RTA|-------|RTB| | 908 | +---+ +---+\ | + 909 + \ | +---+ | 910 \ |--|RTY|--| 911 +---+ | +---+ | 912 |RTD|--| + 913 +---+ | 914 + 916 Figure 3: Example 2's internetwork. 918 Vertical lines are LAN segments. Six routers 919 are pictured, Routers RTA-RTE and RTY. 920 RTB has three serial line interfaces, two of 921 which are leased lines and the third (connecting to 922 RTC) a demand circuit. Two hosts, H1 and 923 H2, are pictured to illustrate the effect of 924 application traffic. 926 LS age 927 LSA in RTC in RTD in RTE 928 ________________________________________________ 929 RTA's Router-LSA DoNotAge+20 21 21 930 RTB's Router-LSA DoNotAge+5 6 6 932 Table 2: After Time T0 in Example 2, LS age 933 fields on the right side of Router RTB. 935 LS age 936 LSA in RTC in RTD in RTE 937 _______________________________________________ 938 RTA's Router-LSA 5 6 6 939 RTB's Router-LSA DoNotAge+5 1785 1785 941 Table 3: After Time T2 in Example 2, LS age 942 fields on the right side of Router RTB. 944 LS age 945 LSA in RTC in RTD in RTE 946 _______________________________________________________ 947 RTA's Router-LSA 325 326 326 948 RTB's Router-LSA DoNotAge+5 DoNotAge+6 DoNotAge+6 950 Table 4: After Time T3 in Example 2, LS age 951 fields on the right side of Router RTB. 953 LS age 954 LSA in RTC in RTD in RTE 955 _______________________________________________________ 956 RTA's Router-LSA DoNotAge+7 DoNotAge+8 DoNotAge+8 957 RTB's Router-LSA DoNotAge+5 DoNotAge+6 DoNotAge+6 959 Table 5: After Time T4 in Example 2, LS age 960 fields on the right side of Router RTB. 962 Time T1: Underlying data-link connection is torn down. 964 All application traffic is flowing over the leased line 965 connecting Routers RTB and RTD instead of the demand 966 circuit, due to the leased line's lesser OSPF cost. After 967 some period of inactivity, the data-link connection 968 underlying the demand circuit will be torn down. This does 969 not affect the OSPF database or the routers' routing tables. 971 Time T2: Router RTA refreshes its router-LSA. 973 When Router RTA refreshes its router-LSA (as all routers do 974 every LSRefreshInterval), Router RTB floods the refreshed 975 LSA over the leased line but not over the demand circuit, 976 because the contents of the LSA have not changed. This new 977 LSA will not have the DoNotAge bit set, and will replace the 978 old instances (whether or not they have the DoNotAge bit 979 set) by virtue of its higher LS Sequence number. This is 980 pictured in Table 3. 982 Time T3: Leased line becomes inoperational. 984 When the leased line becomes inoperational, the data-link 985 connection underlying the demand circuit will be reopened, 986 in order to flood a new (and changed) router-LSA for RTB and 987 also to carry the application traffic between Hosts H1 and 988 H2. After flooding the new LSA, all routers on the right 989 side of the demand circuit will have DoNotAge set in their 990 copy of RTB's router-LSA and DoNotAge clear in their copy of 991 RTA's router-LSA (see Table 4). 993 Time T4: In Router RTE, Router RTA's router-LSA times out. 995 Refreshes of Router RTA's router-LSA are not being flooded 996 over the demand circuit. However, RTA's router-LSA is aging 997 in all of the routers to the right of the demand circuit. 998 For this reason, the router-LSA will eventually be aged out 999 and reflooded (by router RTE in our example). Because this 1000 aged out LSA constitutes a real change (see Section 3.3), it 1001 is flooded over the demand circuit from Router RTC to RTB. 1002 There are then two possible scenarios. First, the LS 1003 Sequence number for RTA's router-LSA may be larger on RTB's 1004 side of the demand link. In this case, when router RTB 1005 receives the flushed LSA it will respond by flooding back 1006 the more recent instance (see Section 2.4). If instead the 1007 LS sequence numbers are the same, the flushed LSA will be 1008 flooded all the way back to Router RTA, which will then be 1009 forced to reoriginate the LSA. 1011 In any case, after a small period all the routers on the 1012 right side of the demand link will have the DoNotAge bit set 1013 in their copy of RTA's router-LSA (see Table 5). In the 1014 small interval between the flushing and waiting for a new 1015 instance of the LSA, there will be a temporary loss of 1016 connectivity between Hosts H1 and H2. 1018 Time T5: A non-supporting router joins. 1020 Suppose Router RTY now becomes operational, and does not 1021 support the demand circuit OSPF extensions. Router RTY's 1022 router-LSA then will not have the DC-bit set in its Options 1023 field, and as the router-LSA is flooded throughout the 1024 internetwork it flushes all LSAs having the DoNotAge bit set 1025 and causes the flooding behavior over the demand circuit to 1026 revert back to the normal flooding behavior defined in [1]. 1027 However, although all LSAs will now be flooded over the 1028 demand circuit, regardless of whether their contents have 1029 really changed, Hellos will still continue to be suppressed 1030 on the demand circuit (see Section 3.2.2). 1032 4.3. Example 3: Operation when oversubscribed 1034 Figure 4 shows a single Router (RT1) connected via demand 1035 circuits to three other routers (RT2-RT4). Assume that RT1 can 1036 only have two out of three underlying data-link connections open 1037 at once. This may be due to one of the following reasons: 1038 Router RT1 may be using a single Basic Rate ISDN interface (2 B 1039 channels) to support all three demand circuits, or, RT1 may be 1040 connected a data-link switch (e.g., X.25 or Frame relay) that is 1041 only capable of so many simultaneous data-link connections. 1043 The following events may transpire, starting with Router RT1 1044 coming up. 1046 Time T0: Router RT1 comes up. 1048 Router RT1 attempts to establish neighbor connections and 1049 synchronize OSPF databases with routers RT2-RT4. But, 1050 because it cannot have data-link connections open to all 1051 three at once, it will synchronize with RT2 and RT3, while 1052 Hellos sent to RT4 will be discarded (see Section 1). 1054 Time T1: Data-link connection to RT2 closed due to inactivity. 1056 Assuming that no application traffic is being sent to/from 1057 Host H3, the underlying data-link connection to RT2 will 1058 eventually close due to inactivity. Then, the next Hello 1059 + +--+ 1060 +---+ |--|H3| 1061 +---------|RT2|--| +--+ 1062 / +---+ | 1063 / ODL + 1064 +--+ + / 1065 |H1|--| / + 1066 +--+ | +---+ ODL +---+ | +--+ 1067 |--|RT1|------------|RT3|--|--|H4| 1068 | +---+ +---+ | +--+ 1069 | \ + 1070 + \ODL 1071 \ + +--+ 1072 \ +---+ |--|H2| 1073 +--------|RT4|--| +--+ 1074 +---+ | 1075 + 1077 Figure 4: Example 3's internetwork. 1079 that RT1 attempts to send to RT4 will cause that data-link 1080 connection to open and synchronization with RT4 will ensue. 1081 Note that, until this time, H2 will be considered 1082 unreachable by OSPF routing. However, data traffic would not 1083 have been deliverable to H2 until now in any case. 1085 Time T2: RT2's LAN interface becomes inoperational 1087 This causes RT2 to reissue its router-LSA. However, it may 1088 be unable to flood it to RT1 if RT1 already has data-link 1089 connections open to RT3 and RT4. While the data-link 1090 connection from RT2 to RT1 cannot be opened due to resource 1091 shortages, the new router-LSA will be continually 1092 retransmitted (and dropped by RT2's ISDN interface; see 1093 Section 1). This means that the routers RT1, RT3 and RT4 1094 will not detect the unreachability of Host H3 until a data- 1095 link connection on RT1 becomes available. 1097 5. Topology recommendations 1099 Because LSAs indicating topology changes are still flooded over 1100 demand circuits, it is still advantageous to design networks so that 1101 the demand circuits are isolated from as many topology changes as 1102 possible. In OSPF, this is done by encasing the demand circuits 1103 within OSPF stub areas or within NSSAs (see [3]). In both cases, 1104 this isolates the demand circuits from AS external routing changes, 1105 which in many networks are the most frequent (see [6]). Stub areas 1106 can even isolate the demand circuits from changes in other OSPF 1107 areas. 1109 Also, considering the interoperation of OSPF routers supporting 1110 demand circuits and those that do not (see Section 2.5), isolated 1111 stub areas or NSSAs can be converted independently to support demand 1112 circuits. In contrast, regular OSPF areas must all be converted 1113 before the functionality can take effect in any particular regular 1114 OSPF area. 1116 6. Lost functionality 1118 The enhancements defined in this memo to support demand circuits 1119 come at some cost. Although we gain an efficient use of demand 1120 circuits, holding them open only when there is actual application 1121 data to send, we lose the following: 1123 Robustness 1124 In regular OSPF [1], all LSAs are refreshed every 1125 LSRefreshInterval. This provides protection against routers 1126 losing LSAs from (or LSAs getting corrupted in) their link state 1127 databases due to software errors, etc. Over demand circuits 1128 this periodic refresh is removed, and we depend on routers 1129 correctly holding LSAs marked with DoNotAge in their databases 1130 indefinitely. 1132 Database Checksum 1133 OSPF supplies network management variables, namely 1134 ospfExternLSACksumSum and ospfAreaLSACksumSum in [7], allowing a 1135 network management station to verify OSPF database 1136 synchronization among routers. However, these variables are sums 1137 of the individual LSAs' LS checksum fields, which are no longer 1138 guaranteed to be identical across demand circuits (because the 1139 LS checksum covers the LS Sequence Number, which will in general 1140 differ across demand circuits). This means that these variables 1141 can no longer be used to verify database synchronization in OSPF 1142 networks containing demand circuits. 1144 7. Future work: Oversubscription 1146 An internetwork is oversubscribed when not all of its demand 1147 circuits' underlying connections can be open at once, due to 1148 resource limitations. These internetworks were addressed in Section 1149 4.3. However, when all possible sources in the internetwork are 1150 +--+ + + +--+ 1151 |H1|--| +---+ ODL +---+ |--|H2| 1152 +--+ |--|RT1|-------|RT2|--| +--+ 1153 | +---+ +---+ | 1154 + | \ / | + 1155 | \ / | 1156 | \ / | 1157 |ODL / |ODL 1158 | / \ODL | 1159 | / \ | 1160 + | /ODL \ | + 1161 +--+ | +---+ +---+ | +--+ 1162 |H4|--|--|RT4|-------|RT3|--|--|H3| 1163 +--+ | +---+ ODL +---+ | +--+ 1164 + + 1166 Figure 5: Example of an oversubscribed 1167 internetwork 1169 +---+ +---+ +---+ +---+ 1170 |RT1|-------|RT2| |RT1| |RT2| 1171 +---+ +---+ +---+ +---+ 1172 | | | \ 1173 | | | \ 1174 | | | \ 1175 | | | \ 1176 | | | \ 1177 | | | \ 1178 | | | \ 1179 +---+ +---+ +---+ +---+ 1180 |RT4|-------|RT3| |RT4|-------|RT3| 1181 +---+ +---+ +---+ +---+ 1183 Figure 5a: One possible Figure 5b: Another possible 1184 pattern of data-link pattern of data-link 1185 connections connections 1187 active at once, problems can occur which are not addressed in this 1188 memo: 1190 (1) There is a network design problem. Does a subset of demand 1191 circuits exist such that a) their data-link connections can be 1192 open simultaneously and b) they can provide connectivity for all 1193 possible sources? This requires that (at least) a spanning tree 1194 be formed out of established connections. Figure 4 shows an 1195 example where this is not possible; Hosts H1 through H4 cannot 1196 simultaneously talk, since Router RT1 is limited to two 1197 simultaneously open demand circuits. 1199 (2) Even if it is possible that a spanning tree can form, will one? 1200 Given the model in Section 1, demand circuits are brought up 1201 when needed for data traffic, and stay established as long as 1202 data traffic is present. One example is shown in Figure 5. Four 1203 routers are interconnected via demand circuits, with each router 1204 being able to establish a circuit to any other. However, we 1205 assume that each router can only have two circuits open at once 1206 (e.g., the routers could be using Basic Rate ISDN). In this 1207 case, one would hope that the data-link connections in Figure 5a 1208 would form. But the connections in Figure 5b are equally 1209 likely, which leave Host H2 unable to communicate. 1211 One possible approach to this problem would be for a) the OSPF 1212 database to indicate which demand circuits have actually been 1213 established and b) implement a distributed spanning tree 1214 construction (see for example Chapter 5.2.2 of [9]) when 1215 necessary. 1217 (3) Even when a spanning tree has been built, will it be used? 1218 Routers implementing the functionality described in this memo do 1219 not necessarily know which data-link connections are established 1220 at any one time. In fact, they view all demand circuits as being 1221 equally available, whether or not they are established. So for 1222 example, even when the established connections form the pattern 1223 in Figure 5a, Router RT1 may still believe that the best path to 1224 Router RT3 is through the direct demand circuit. However, this 1225 circuit cannot be established due to resource shortages. 1227 On possible approach to this problem is to increase the OSPF 1228 cost of demand circuits that are currently discarding 1229 application packets (i.e., can't be established) due to resource 1230 shortages. This may help the routing find paths that can 1231 actually deliver the packets. On the downside, it would create 1232 more routing traffic. Also, unwanted routing oscillations may 1233 result when you start varying routing metrics to reflect dynamic 1234 network conditions; see [10]. 1236 A. Format of the OSPF Options field 1238 The OSPF Options field is present in OSPF Hello packets, Database 1239 Description packets and all LSAs. The Options field enables OSPF 1240 routers to support (or not support) optional capabilities, and to 1241 communicate their capability level to other OSPF routers. Through 1242 this mechanism routers of differing capabilities can be mixed within 1243 an OSPF routing domain. 1245 The memo defines one of the Option bits: the DC-bit (for Demand 1246 Circuit capability). The DC-bit is set in a router's self-originated 1247 LSAs if and only if it supports the functionality defined in Section 1248 2 of this memo. Note that this does not necessarily mean that the 1249 router can be the endpoint of a demand circuit, but only that it can 1250 properly process LSAs having the DoNotAge bit set. In contrast, the 1251 DC-bit is set in Hello Packets and Database Description Packets sent 1252 out an interface if and only if the router wants to treat the 1253 attached point-to-point network as a demand circuit (see Section 1254 3.2.1). 1256 The addition of the DC-bit makes the current assignment of the OSPF 1257 Options field as follows: 1259 +------------------------------------+ 1260 | * | * | DC | EA | N/P | MC | E | T | 1261 +------------------------------------+ 1263 Figure 5: The OSPF Options field 1265 T-bit 1266 This bit describes TOS-based routing capability, as specified in 1267 [1]. 1269 E-bit 1270 This bit describes the way AS-external-LSAs are flooded, as 1271 described in [1]. 1273 MC-bit 1274 This bit describes whether IP multicast datagrams are forwarded 1275 according to the specifications in [4]. 1277 N/P-bit 1278 This bit describes the handling of Type-7 LSAs, as specified in 1279 [3]. 1281 EA-bit 1282 This bit describes the router's willingness to receive and 1283 forward External Attributes LSAs, as specified in [5]. 1285 DC-bit 1286 This bit describes the handling of demand circuits, as specified 1287 in this memo. Its setting in Hellos and Database Description 1288 Packets is described in Sections 3.2.1 and 3.2.2. Its setting in 1289 LSAs is described in Sections 2.1 and 2.5. 1291 B. Configurable Parameters 1293 This memo defines a single additional configuration parameter for 1294 OSPF interfaces. In addition, the OSPF Interface configuration 1295 parameter PollInterval, previously used only on NBMA networks, is 1296 now also used on point-to-point networks (see Sections 3.1 and 1297 3.2.2). 1299 DemandInterface 1300 Indicates whether the interface connects to a demand circuit. 1301 When set to TRUE, the procedures described in Section 3 of this 1302 memo are followed, in order to send a minimum of routing traffic 1303 over the demand circuit. On point-to-point networks, this allows 1304 the circuit to be closed when not carrying application traffic. 1305 When a broadcast or NBMA network is configured to be a demand 1306 interface (see Section 1.2 of [1]), the circuit will be kept 1307 open constantly due to OSPF Hello traffic, but the amount of 1308 flooding traffic will still be greatly reduced. 1310 C. Architectural Constants 1312 This memo defines a single additional OSPF architectural constant. 1314 DoNotAge 1315 Equal to the hexadecimal value 0x8000, which is the high bit of 1316 the 16-bit LS Age field in OSPF LSAs. When this bit is set in 1317 the LS age field, the LSA is not aged as it is held in the 1318 router's link state database. This allows the elimination of the 1319 periodic LSA refresh over demand circuits. See Section 2.2 for 1320 more information on processing the DoNotAge bit. 1322 References 1324 [1] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994. 1326 [2] Meyer, G., "Extensions to RIP to Support Demand Circuits", RFC 1327 1582, Spider Systems, February 1994. 1329 [3] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, 1330 RainbowBridge Communications, Stanford University, March 1994. 1332 [4] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, 1333 Inc., March 1994. 1335 [5] Ferguson, D., "The OSPF External Attributes LSA", work in 1336 progress. 1338 [6] Moy, J., editor, "OSPF protocol analysis", RFC 1245, Proteon, 1339 Inc., July 1991. 1341 [7] Baker F. and R. Coltun, "OSPF Version 2 Management Information 1342 Base", RFC 1253, ACC, University of Maryland, August 1991. 1344 [8] Baker F., "OSPF Point-to-MultiPoint Interface", work in 1345 progress. 1347 [9] Bertsekas, D. and Gallager R., "Data Networks", Prentice Hall, 1348 Inc., 1992. 1350 [10] Khanna, A., "Short-Term Modifications to Routing and Congestion 1351 Control", BBN Report 6714, BBN, February 1988. 1353 Security Considerations 1355 Security issues are not discussed in this memo. 1357 Author's Address 1359 John Moy 1360 Cascade Communications Corp. 1361 5 Carlisle Road 1362 Westford, MA 01886 1364 Phone: 508-692-2600 Ext. 394 1365 Fax: 508-692-9214 1366 Email: jmoy@casc.com 1368 This document expires in May 1995.