Network Working Group J. Moy Internet Draft Proteon, Inc. Expiration Date: November 1994 May 1994 File name: draft-ietf-ospf-demand-00.txt Extending OSPF to support demand circuits Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Abstract This memo defines enhancements to the OSPF protocol that allow efficient operation over "demand circuits". Demand circuits are those whose costs vary with usage; charges can be based both on connect time and on bytes/packets transmitted. Examples of such circuits include ISDN circuits, X.25 SVCs, and dial-up lines. The periodic nature of OSPF routing traffic (as defined in [1]) requires such circuits to be open constantly, resulting in unwanted usage charges. With the modifications described herein, OSPF Hellos and the refresh of OSPF routing information are suppressed, allowing demand circuits to be closed when not carrying application traffic. Demand circuits and regular network segments (e.g., leased lines) are allowed to be combined in any manner. In other words, there are no topological restrictions on the demand circuit support. However, while any OSPF network segment can be defined as a demand circuit, only point-to-point networks receive the full benefit. When broadcast and NBMA networks are declared demand circuits, routing update traffic is reduced but the periodic sending of Hellos is not, Moy [Page 1] Internet Draft OSPF over Demand Circuits May 1994 which in effect still requires that the data-link circuits be constantly open. While mainly intended for use with cost-conscious network links such as ISDN, X.25 and dial-up, the modifications in this memo may also prove useful over bandwidth-limited network links such as slow-speed leased lines and packet radio. The enhancements defined in this memo are backward-compatible with the OSPF specification defined in [1], and with the OSPF extensions defined in [3] (OSPF NSSA areas), [4] (MOSPF) and [8] (OSPF Point- to-MultiPoint Interface). This memo provides functionality comparable to that specified for RIP in [2]. However, because OSPF is a link-state routing protocol rather than a Distance Vector protocol, the mechanisms used to achieve that functionality are quite different. Please send comments to ospf@gated.cornell.edu. Acknowledgments The author would like to acknowledge the helpful comments of Fred Baker, Rob Coltun, Gerry Meyer, and Tom Pusateri. This memo is a product of the OSPF Working Group. Moy [Page 2] Internet Draft OSPF over Demand Circuits May 1994 Table of Contents 1 Model for demand circuits .............................. 4 2 Modifications to all OSPF routers ...................... 4 2.1 The LS age field ....................................... 5 2.2 Removing old, non-aging LSAs ........................... 6 2.3 Interoperability with unmodified OSPF routers .......... 6 3 Modifications to demand circuit endpoints .............. 7 3.1 Configuring demand circuits ............................ 7 3.2 Sending and Receiving OSPF Hellos ...................... 8 3.3 Interface State machine modifications .................. 8 3.4 Flooding over demand circuits .......................... 9 4 Examples .............................................. 10 4.1 Example 1: Sole connectivity through demand circuits .. 10 4.2 Example 2: Demand and non-demand circuits in parallel . 14 4.3 Example 3: Operation when suffering SVC shortage ...... 18 5 Topology recommendations .............................. 20 6 Lost functionality .................................... 20 A The Options field ..................................... 22 B Configurable Parameters ............................... 23 C Architectural Constants ............................... 23 References ............................................ 24 Security Considerations ............................... 24 Author's Address ...................................... 24 Moy [Page 3] Internet Draft OSPF over Demand Circuits May 1994 1. Model for demand circuits In this memo, demand circuits refer to those network segments whose cost depends on either connect time or on usage (expressed in terms of bytes or packets). Examples include ISDN circuits and X.25 SVCs. On these circuits, it is desirable for a routing protocol to send as little routing traffic as possible. In fact, when there is no change in network topology it is desirable for a routing protocol to send no routing traffic at all; this allows the underlying data-link connection to be closed when not needed for application data traffic. The model used within this memo for the maintenance of demand circuits is as follows. If there is no data to send (either routing protocol traffic or application data), the data-link connection remains closed. As soon as there is data to be sent, an attempt to open the data-link connection is made (e.g., an ISDN or X.25 call is placed). If the connection is successful, the data is sent, and the circuit stays open until some period of time elapses without more data to send. At this point the data-link connection is again closed, in order to conserve cost and resources (see Section 1 of [2]). The "Presumption of Reachability" described in [2] is also used. Even though a data-link connection may be closed at any particular time, it is assumed by the routing layer that it is available unless other information, such as a discouraging diagnostic code resulting from an attempted data-link connection, is present. It may be possible that a data-link connection cannot be opened due to resource shortages. For example, a router with a single basic rate ISDN interface cannot open more than two simultaneous ISDN data-link connections (one for each B channel), and limitations in interface firmware and/or switch capacity may limit the number of X.25 SVCs simultaneously supported. In these cases, datagrams to be forwarded out these (temporarily unopenable) data-link connections are discarded, instead of queued. Note also that this temporary inability to open data-link connections is NOT reported by the OSPF routing system as unreachability; see Section 4.3 for more information. 2. Modifications to all OSPF routers While most of the modifications to support demand circuits are isolated to the demand circuit endpoints, there are changes required of all OSPF routers. These changes are described in the subsections below. Routers implementing these changes set the DC-bit in the options field of their router-LSA (see Section 2.3 and Appendix A), Moy [Page 4] Internet Draft OSPF over Demand Circuits May 1994 even if they do not implement the more substantial modifications required of demand circuit endpoints that are described in Section 3. 2.1. The LS age field The semantics of the LSA's LS age field are changed, allowing the high bit (DoNotAge; see Appendix C) to be set. Previously the LS age field could not exceed the value of MaxAge. LSAs whose LS age field have the DoNotAge bit set are not aged while they are held in the link state database, which means that they do not have to be refreshed every LSRefreshInterval as is done with all other OSPF LSAs. By convention, in the rest of this memo we will express LS age fields having the DoNotAge set as "DoNotAge+x", while an LS age expressed as just "x" is assumed not to have the DoNotAge bit set. When comparing two LSA instances to see which one is most recent, the two LSAs' LS age fields are compared whenever the LS sequence numbers and LS checksums are found identical (see Section 13.1 of [1]). Before comparing, the LS age fields should have their DoNotAge bits masked off. For example, in determining which LSA is more recent, LS ages of 1 and DoNotAge+1 should be considered equivalent; an LSA flooded with LS age of 1 may be acknowledged with a Link State Acknowledgement listing an LS age of DoNotAge+1, or vice versa. As a special case, DoNotAge+MaxAge is equivalent to MaxAge, and either form can be used to flush LSAs from the routing domain (see Section 14.1 of [1]). When an LSA is flooded out a non-demand interface, the constant InfTransDelay is added to the LSA's LS age field. This happens even if the DoNotAge bit is set; in this case the LS age field is not allowed to exceed DoNotAge+MaxAge, at which time the LSA is flushed from the routing domain. This preserves the protection in [1] afforded against flooding loops. Flooding out demand interfaces is covered in Section 3.4. Thus, the set of allowable values for the LS age field fall into the two ranges: 0 through MaxAge and DoNotAge through DoNotAge+MaxAge. Any LS age field not falling into these two ranges should be considered to be equal to MaxAge. The LS age field is not checksum protected. Errors in a router's memory may mistakenly set an LSA's DoNotAge bit, stopping the aging of the LSA. However, a router should note that its own Moy [Page 5] Internet Draft OSPF over Demand Circuits May 1994 self-originated LSAs should never have the DoNotAge bit set in its own database. This means that in any case the router's self-originated LSAs will be refreshed every LSRefreshInterval. As this refresh is flooded throughout the OSPF routing domain, it will replace any LSA copies whose DoNotAge bits were mistakenly set. 2.2. Removing old, non-aging LSAs Because LSAs with the DoNotAge bit set are never aged, they can stay in the link state database even when the originator of the LSA no longer exists. To ensure that these LSAs are eventually flushed from the routing domain, and that the size of the link state database doesn't grow without bound, routers are required to flush an LSA if the originator of the LSA has been unreachable (according to the routing calculations specified by Section 16 of [1]) for the time MaxAge. For an example, see Time T8 in Section 4.1. This is an exception to the general OSPF rule that a router can only flush its own self-originated LSAs. An interval as long as MaxAge has been chosen to avoid any possibility of thrashing (i.e., flushing an advertisement only to have it reoriginated soon afterwards). 2.3. Interoperability with unmodified OSPF routers Unmodified OSPF routers will probably treat LSAs with the DoNotAge bit set as if they had LS age of MaxAge. At the very worst, this will cause continual retransmissions of LSAs with the DoNotAge bit set. However, to avoid this confusion, advertisements with DoNotAge set will be allowed in an OSPF area only if, in the area's link state database, all router-LSAs and type-4-summary-LSAs (location of ASBRs) have their DC-bit set (indicating their ability to process DoNotAge). Note that it is not required that the LSAs' Advertising Router is reachable; if any LSA is found not having its DC-bit set (regardless of reachability), then the router should flush from the area all advertisements having DoNotAge set; this is an exception to the general OSPF rule that a router can only flush its own self-originated LSAs. When flushing, the LSAs' LS age field should be set to MaxAge and not DoNotAge+MaxAge. (As an implementation suggestion, a new variable "DCBitLessLSAs" could be added to the OSPF area data structure in Section 6 of [1]. This variable would count the number of the area's router- LSAs and type-4-summary-LSAs that do not have the DC-bit set. Moy [Page 6] Internet Draft OSPF over Demand Circuits May 1994 This variable would potentially increment/decrement any time a new LSA was received or an old LSA was replaced or flushed.) In particular, AS-external-LSAs with the DoNotAge bit set cannot exist in the routing domain unless all routers in all "regular OSPF areas" (all areas that are neither stub areas nor NSSAs) are capable of processing DoNotAge. In order to convey this information across area boundaries, area border routers must set the DC-bit in a type-4-summary-LSA that they originate if and only if the described ASBR has the DC-bit set in its original router-LSA. Additionally, sometimes in may be necessary to convey across areas the the existence of a non-ASBR that cannot process DoNotAge. In this case, a type-4-summary-LSA should be originated with cost of LSInfinity and DC-bit clear. 3. Modifications to demand circuit endpoints The following subsections detail the modifications required of the routers at the endpoints of demand circuits. This consists of modifications to two main pieces of OSPF: 1) sending and receiving hellos over demand circuits and 2) flooding LSAs over demand circuits. 3.1. Configuring demand circuits An additional OSPF interface configuration parameter, DemandInterface, is defined to indicate whether an OSPF interface connects to a demand circuit (see Appendix B). On point-to-point demand circuits, the neighboring router must agree that the point-to-point link is a demand circuit. To ensure this agreement, the router sets the DC-bit in OSPF Hellos (and Database Description Packets) sent out the demand interface. Receiving an Hello or a Database Description Packet with the DC-bit set indicates agreement. Receiving an Hello with the DC-bit clear and also listing the router's Router ID in the body of the Hello message, or a Database Description Packet with the DC-bit clear (either one indicating bidirectional connectivity) indicates that the other end refuses to treat the link as a demand circuit. In these cases, the router reverts to treating the link as a leased line. The above procedure indicates that a demand point-to-point circuit need be configured in only one of the two endpoints (see Section 4.1). If the negotiation fails, and the router is forced to treat the line as a leased line, the router can always renegotiate the link's demand status whenever the link goes down. For example, Moy [Page 7] Internet Draft OSPF over Demand Circuits May 1994 if the neighboring router is rebooted with software that is capable of operating over demand circuits, a future negotiation will succeed. For more information on sending OSPF Hellos over demand circuits, see Section 3.2. 3.2. Sending and Receiving OSPF Hellos Over point-to-point demand circuits OSPF Hello packets are sent only until initial link-state database synchronization is achieved with the neighbor (i.e., the state of the neighbor connection reaches "Full", as defined in Section 10.1 of [1]). After this, Hellos are suppressed and the data-link connection to the neighbor is assumed available until evidence is received to the contrary. When the router finds that the neighbor is no longer available, presumably from something like a diagnostic code contained in a response to a failed call request, the neighbor connection transitions back to "Down" and Hellos are sent periodically (at Intervals of PollInterval) in an attempt to restart synchronization with the neighbor. This requires changes to the OSPF Neighbor State Machine (see Section 10.3 of [1]). The receipt of Hellos from neighbors in state "Loading" or higher cannot be required. In other words, the InactivityTimer event defined in Section 10.2 of [1] has no effect on neighbors in state "Loading" or higher. An additional clarification is needed in the Neighbor State Machine's LLDown event. This event should be mapped into the "discouraging diagnostic code" discussed above in Section 1, and should not be generated when the data-link connection has been closed simply to save resources. For OSPF broadcast and NBMA networks that have been configured as demand circuits, there is no change to the sending and receiving of Hellos, nor are there any changes to the Neighbor State Machine. This is because the proper operation of the Designated Router election algorithm requires periodic exchange of Hello Packets. 3.3. Interface State machine modifications OSPF interfaces to point-to-point demand circuits are considered to be in "Point-to-point" state if and only if they have a neighbor in state "1-Way" or greater, otherwise they are considered to be in state "Down". However, as discussed above in Section 3.2, Hellos are sent out interfaces in "Down" state, at the reduced interval of PollInterval. Hellos cease to be sent Moy [Page 8] Internet Draft OSPF over Demand Circuits May 1994 out the interface whenever the associated neighbor reaches state "Full". Note that as a result, an "LLDown" event for the point-to-point demand circuit's neighbor forces both the neighbor and the interface into state "Down". For OSPF broadcast and NBMA networks that have been configured as demand circuits, there are no changes to the Interface State Machine. 3.4. Flooding over demand circuits Flooding over demand circuits (point-to-point or otherwise) is modified if and only if all routers have indicated that they can process LSAs having DoNotAge set. This is determined by examining the link state database of the OSPF area containing the demand circuit. All the router-LSAs and type-4-summary-LSAs must have the DC-bit set. If one or more LSAs have the DC-bit clear, flooding over demand circuits is unchanged from [1]. (In particular, router-LSAs or type-4-summary-LSAs that do not have the DC-bit set are flooded unchanged from [1], because their reception inhibits the flooding behavior defined below). Otherwise, flooding is changed as follows. First, only truly changed LSAs are flooded over demand circuits. When a router receives a new LSA instance, it checks first to see whether the contents have changed. If not, the new LSA is simply a periodic refresh and it is not flooded out attached demand circuits (it is still flooded out other interfaces however). This check should be performed in Step 5b of Section 13 in [1]. When comparing an LSA to its previous instance, the following are all considered to be changes in contents: o The LSA's Options field has changed. o One of the LSA instances has LS age set to MaxAge (or DoNotAge+MaxAge). o The length field in the LSA header has changed. o The contents of the LSA, excluding the 20-byte link state header, have changed. Note that this excludes changes in LS Sequence Number and LS Checksum. Second, when it has been decided to flood an LSA over a demand circuit, DoNotAge should be set in the LSA's LS age field before flooding. This will cause the routers on the other side of the Moy [Page 9] Internet Draft OSPF over Demand Circuits May 1994 demand circuit to hold the LSA in their database indefinitely, removing the need for periodic refresh. Note that it is perfectly possible that DoNotAge will already be set. This simply indicates that the LSA has already been flooded over demand circuits. In any case, the LS age field must also be incremented by InfTransDelay before flooding (see Step 5 of Section 13.3 in [1]), as protection against flooding loops. The above paragraph also pertains to LSAs flooded over demand circuits in response to Link State Requests. Third, when receiving a Link State Update from a demand circuit neighbor that contains an LSA instance that is actually older than the the router's current copy, the router must respond by flooding its current LSA copy directly to the neighbor (without putting the LSA on the neighbor's Link State retransmission list). This is instead of the behavior specified in Step 8 of Section 13 in [1], which would effectively ignore the flood of the older advertisement. To see the necessity of responding to old LSAs, see Time T4 in Section 4.2. 4. Examples This section gives three examples of the operation over demand circuits. The first example is probably the most common and certainly the most basic. It shows a single point-to-point demand circuit connecting two routers. The second illustrates what happens when demand circuits and leased lines are used in parallel. The third explains what happens when a router has multiple demand circuits and cannot keep them all open (for resource reasons) at the same time. 4.1. Example 1: Sole connectivity through demand circuits Figure 1 shows a sample internetwork with a single demand circuit providing connectivity to the LAN containing Host H2. Assume that all three routers (RTA, RTB and RTC) have implemented the functionality in Section 2 of this memo, and thus will be setting the DC-bit in their router-LSAs. Furthermore assume that Router RTB has been configured to treat the link to Router RTC as a demand circuit, but Router RTC has not been so configured. Finally assume that the LAN interface connecting Router RTA to Host H1 is initially down. The following sequence of events may then transpire, starting with Router RTB booting and bringing up its link to Router RTC: Moy [Page 10] Internet Draft OSPF over Demand Circuits May 1994 + + + | +---+ | | +--+ |---|RTA|---| | +--+ |H1|---| +---+ | |---|H2| +--+ | | +---+ ODL +---+ | +--+ |LAN Y |---|RTB|-------------|RTC|---| + | +---+ +---+ | + + Figure 1: A single demand circuit (labeled ODL) bisecting an internetwork. Time T0: RTB negotiates demand circuit status Router RTB will start sending Hellos over the demand circuit with the DC-bit set in the Hello's Options field. Because RTC is not configured to treat the link as a demand circuit, the first Hello received from RTC may not have the DC-bit set. However, subsequent Hellos and Database Description Packets received from RTC will have the DC-bit set, indicating that the two routers have agreed that the link will be treated as a demand circuit. The entire negotiation is pictured in Figure 2. Note that if RTC were unable or unwilling to treat the link as a demand circuit, the initial Database Description sent from Router RTC to RTB would have the DC-bit clear, forcing treatment of the link as a leased line. +---+ +---+ |RTB| |RTC| +---+ +---+ Hello (DC-bit set) -------------------------------------> Hello (DC-bit clear) <------------------------------------- Hello (DC-bit set, RTC seen) -------------------------------------> Database Description (DC-bit set) <------------------------------------- Figure 2: Successful negotiation of a link's demand circuit status. Moy [Page 11] Internet Draft OSPF over Demand Circuits May 1994 Time T1: Database exchange over demand circuit The initial synchronization of link state databases (the Database Exchange Process) over the demand circuit then occurs as over any point-to-point link, with one exception. LSAs included in Link state updates sent over the demand circuit (in response to Link State Request Packets), will have the DoNotAge bit set in their LS age field. So, after the Database Exchange Process is finished, all routers will have 3 LSAs in their link state databases (router-LSAs for Routers RTA, RTB and RTC), but the LS age fields belonging to the LSAs will vary depending on which side of the demand circuit they were originated from (see Table 1). For example, all routers other than Router RTC have the DoNotAge bit set in Router RTC's router-LSA; this removes the need for Router RTC to refresh its router-LSA over the demand circuit. Time T2: Hello traffic ceases After the Database Exchange Process has completed, no Hellos are sent over the demand circuit. If there is no application data to be sent over the demand circuit, the circuit will be idle. Time T3: Underlying data-link connection torn down After some period of inactivity, the underlying data-link connection will be torn down (e.g., an ISDN call will be cleared) in order to save connect charges. This will be transparent to the OSPF routing; no LSAs or routing table entries will change as a result. LS age LSA in RTB in RTC ______________________________________________ RTA's Router-LSA 1000 DoNotAge+1001 RTB's Router-LSA 10 DoNotAge+11 RTC's Router-LSA DoNotAge+11 10 Table 1: LS age fields on either side of the demand circuit Moy [Page 12] Internet Draft OSPF over Demand Circuits May 1994 Time T4: Router RTA's LSA is refreshed At some point Router RTA will refresh its own router-LSA (i.e., when the LSA's LS age hits LSRefreshInterval). This refresh will be flooded to Router RTB, who will look at it and decide NOT to flood it over the demand circuit to Router RTC, because the LSA's contents have not really changed (only the LS Sequence Number). At this point, the LS sequence numbers that the routers have for RTA's router-LSA differ depending on which side of the demand circuit the routers lie. Because there is still no application traffic, the underlying data-link connection remains disconnected. Time T5: Router RTA's LAN interface comes up When Router RTA's LAN interface (connecting to Host H1) comes up, RTA will originate a new router-LSA. This router- LSA WILL be flooded over the demand circuit because its contents have now changed. The underlying data-link connection will have to be brought up to flood the LSA. After flooding, routers on both sides of the demand circuit will again agree on the LS Sequence Number for RTA's router-LSA. Time T6: Underlying data-link connection is torn down again Assuming that there is still no application traffic transiting the demand circuit, the underlying data-link connection will again be torn down after some period of inactivity. Time T7: File transfer started between Hosts H1 and H2 As soon as application data needs to be sent across the demand circuit the underlying data-link connection is brought back up. Time T8: Physical link becomes inoperative If an indication is received from the data-link or physical layers indicating that the demand circuit can no longer be established, Routers RTB and RTC declare their point-to- point interfaces down, and originate new router-LSAs. Both routers will attempt to bring the connection back up by sending Hellos at the reduced rate of PollInterval. Note that while the connection is inoperative, Routers RTA and RTB will continue to have an old router-LSA for RTC in their link state database, and this LSA will not age out because Moy [Page 13] Internet Draft OSPF over Demand Circuits May 1994 it has the DoNotAge bit set. However, according to Section 2.2 they will flush Router RTC's router-LSA if the demand circuit remains inoperative for longer than MaxAge. 4.2. Example 2: Demand and non-demand circuits in parallel This example demonstrates the demand circuit functionality when both demand circuits and non-demand circuits (e.g., leased lines) are used to interconnect regions of an internetwork. Such an internetwork is shown in Figure 3. Host H1 can communicate with Host H2 either over the demand link between Routers RTB and RTC, or over the leased line between Routers RTB and RTD. Because the basic properties of the demand circuit functionality were presented in the previous example, this example will only address the unique issues involved when using both demand and non-demand circuits in parallel. Assume that Routers RTB and RTY are powered off, but that all other routers and their attached links are both operational and implement the demand circuit modifications to OSPF. Throughout the example, a TCP connection between Hosts H1 and H2 is transmitting data. Furthermore, assume that the cost of the demand circuit from RTB to RTC has been set considerably higher than the cost of the leased line between RTB and RTD; for this reason traffic between Hosts H1 and H2 will always be sent over the leased line when it is operational. The following events may then transpire: Time T0: Router RTB comes up. Assume RTB supports the demand circuit OSPF modifications. When Router RTB comes up and establishes links to Routers RTC and RTD, it will flood the same information over both. However, LSAs sent over the demand circuit (to Router RTC) will have the DoNotAge bit set, while those sent over the leased line to Router RTD will not. Because the DoNotAge bit is not taken into account when comparing LSA instances, the routers on the right side of RTB (RTC, RTE and RTD) may or may not have the DoNotAge bit set in the copies of the RTA and RTB router-LSAs contained in their database. This depends on whether the LSAs sent over the demand link reach the routers before those sent over the leased line. One possibility is pictured in Table 2. Moy [Page 14] Internet Draft OSPF over Demand Circuits May 1994 + +---+ | |RTC|--| + +---+ | +---+ | + / |--|RTE|--| +--+ +--+ | /ODL | +---+ |--|H2| |H1|----| +---+ +---+/ | + +--+ +--+ |--|RTA|-------|RTB| | | +---+ +---+\ | + + \ | +---+ | \ |--|RTY|--| +---+ | +---+ | |RTD|--| + +---+ | + Figure 3: A sample internetwork. Vertical lines are LAN segments. Six routers are pictured, Routers RTA-RTE and RTY. RTB has three serial line interfaces, two of which are leased lines and the third (connecting to RTC) a demand circuit. Two hosts, H1 and H2, are pictured to illustrate the effect of application traffic. Moy [Page 15] Internet Draft OSPF over Demand Circuits May 1994 LS age LSA in RTC in RTD in RTE ________________________________________________ RTA's Router-LSA DoNotAge+20 21 21 RTB's Router-LSA DoNotAge+5 6 6 Table 2: After Time T0, LS age fields on the right side of Router RTB. LS age LSA in RTC in RTD in RTE _______________________________________________ RTA's Router-LSA 5 6 6 RTB's Router-LSA DoNotAge+5 1785 1785 Table 3: After Time T2, LS age fields on the right side of Router RTB. LS age LSA in RTC in RTD in RTE _______________________________________________________ RTA's Router-LSA 325 326 326 RTB's Router-LSA DoNotAge+5 DoNotAge+6 DoNotAge+6 Table 4: After Time T3, LS age fields on the right side of Router RTB. LS age LSA in RTC in RTD in RTE _______________________________________________________ RTA's Router-LSA DoNotAge+7 DoNotAge+8 DoNotAge+8 RTB's Router-LSA DoNotAge+5 DoNotAge+6 DoNotAge+6 Table 5: After Time T4, LS age fields on the right side of Router RTB. Time T1: Underlying data-link connection is torn down. Moy [Page 16] Internet Draft OSPF over Demand Circuits May 1994 All application traffic is flowing over the leased line connecting Routers RTB and RTD instead of the demand circuit, due to the leased line's lesser OSPF cost. After some period of inactivity, the data-link connection underlying the demand circuit will be torn down. This does not affect the OSPF database or the routers' routing tables. Time T2: Router RTA refreshes its router-LSA. When Router RTA refreshes its router-LSA (as all routers do every LSRefreshInterval), Router RTB floods the refreshed LSA over the leased line but not over the demand circuit, because the contents of the LSA have not changed. This new LSA will not have the DoNotAge bit set, and will replace the old instances (whether or not they have the DoNotAge bit set) by virtue of its higher LS Sequence number. This is pictured in Table 3. Time T3: Leased line becomes inoperational. When the leased line becomes operational, the data-link connection underlying the demand circuit will be reopened, in order to flood a new (and changed) router-LSA for RTB and also to carry the application traffic between Hosts H1 and H2. At this point, all routers on the right side of the demand circuit will have DoNotAge set in their copy of RTB's router-LSA and DoNotAge clear in their copy of RTA's router-LSA (see Table 4). Time T4: In Router RTE, Router RTA's router-LSA times out. Refreshes of Router RTA's router-LSA are not being flooded over the demand circuit. However, RTA's router-LSA is aging in all of the routers to the right of the demand circuit. For this reason, the router-LSA will eventually be flushed (by router RTE in our example). Because this flushed LSA constitutes a real change (see Section 3.4), it is flooded over the demand circuit from Router RTC to RTB. There are then two possible scenarios. First, the LS Sequence numbers for RTA's router-LSA may have diverged on either side of the demand link. In this case, when router RTB receives the flushed LSA it will respond by flooding back the more recent instance (see Section 3.4). If instead the LS sequence numbers are the same, the flushed LSA will be flooded all the way back to Router RTA, which will then be forced to reoriginate the advertisement. Moy [Page 17] Internet Draft OSPF over Demand Circuits May 1994 In any case, after a small period all the routers on the right side of the demand link will have the DoNotAge bit set in their copy of RTA's router-LSA (see Table 5). In the small interval between the flushing and waiting for a new instance of the LSA, there will be a temporary loss of connectivity between Hosts H1 and H2. Time T5: A non-supporting router joins. Suppose Router RTY now becomes operational, and does not support the demand circuit OSPF extensions. Router RTY's router-LSA then does not have the DC-bit set in its Options field, and as the router-LSA is flooded throughout the internetwork it flushes all LSAs having the DoNotAge bit set and causes the flooding behavior over the demand circuit to revert back to the normal flooding behavior defined in [1]. However, although all LSAs will now be flooded over the demand circuit, regardless of whether their contents have really changed, Hellos will still continue to be suppressed on the demand circuit (see Section 3.2). 4.3. Example 3: Operation when suffering SVC shortage Figure 4 shows a single Router (RT1) connected via demand circuits to three other routers (RT2-RT4). Assume that RT1 can only have two out of three underlying data-link connections open at once. This may be due to one of the following reasons. Router RT1 may be using a single Primary rate ISDN interface (2 B channels) to support all three demand circuits. Or, RT1 may be connected a data-link switch (e.g., X.25 or Frame relay) that is only capable of so many simultaneous data-link connections. The following events may transpire, starting with Router RT1 coming up. Time T0: Router RT1 comes up. Router RT1 attempts to establish neighbor connections and synchronize OSPF databases with routers RT2-RT4. But, because it cannot have data-link connections open to all three at once, it will synchronize with RT2 and RT3, while Hellos sent to RT4 will be discarded (see Section 1). Time T1: Data-link connection to RT2 closed due to inactivity. Assuming that no application traffic is being sent to/from Host H3, the underlying data-link connection to RT2 will eventually close due to inactivity. Then, the next Hello Moy [Page 18] Internet Draft OSPF over Demand Circuits May 1994 + +--+ +---+ |--|H3| +---------|RT2|--| +--+ / +---+ | / ODL + +--+ + / |H1|--| / + +--+ | +---+ ODL +---+ | |--|RT1|------------|RT3|--| | +---+ +---+ | | \ + + \ODL \ + +--+ \ +---+ |--|H2| +--------|RT4|--| +--+ +---+ | + Figure 4: Behavior when not all of the demand circuits' data- link connections can be opened at once. that RT1 attempts to send to RT4 will cause that data-link connection to open and synchronization with RT4 will ensue. Note that, until this time, H2 will be considered unreachable by OSPF routing. However, data traffic would not have been deliverable to H2 until now in any case. Time T2: RT2's LAN interface becomes inoperational This causes RT2 to reissue its router-LSA. However, it may be unable to flood it to RT1 if RT1 already has data-link connections opened to RT3 and RT4. While the data-link connection from RT2 to RT1 cannot be opened due to resource shortages, the new router-LSA will be continually retransmitted (and dropped by RT2's ISDN interface; see the last paragraph of Section 1). This means that the routing will not detect the unreachability of H4 until a data-link connection on RT1 becomes available. Increasing the OSPF cost of demand circuits that are currently discarding application packets, due to underlying data-link shortage, may help the routing find paths that can actually Moy [Page 19] Internet Draft OSPF over Demand Circuits May 1994 deliver the packets. This however would create more routing traffic, and is an issue for future study. 5. Topology recommendations Because LSAs indicating topology changes are still flooded over demand circuits, it is still advantageous to design networks so that the demand circuits are isolated from as many topology changes as possible. In OSPF, this is done by encasing the demand circuits within OSPF stub areas or within NSSAs (see [3]). In both cases, this isolates the demand circuits from AS external routing changes, which in many networks are the most frequent (see [6]). Stub areas can even isolate the demand circuits from changes in other OSPF areas. Also, considering the interoperation of OSPF routers supporting demand circuits and those that do not (see Section 2.3), isolated stub areas or NSSAs can be converted independently to support demand circuits. In contrast, regular OSPF areas must all be converted before the functionality can take effect in any particular regular OSPF area. 6. Lost functionality The enhancements defined in this memo to support demand circuits come at some cost. Although we gain an efficient use of demand circuits, holding them open only when there is actual application data to send, we lose the following: Robustness In regular OSPF [1], all LSAs are refreshed every LSRefreshInterval. This provides protection against routers losing LSAs from (or LSAs getting corrupted in) their link state databases due to software errors, etc. Over demand circuits this periodic refresh is removed, and we depend on routers correctly holding LSAs marked with DoNotAge in their databases indefinitely. Database Checksum OSPF supplies network management variables, ospfExternLSACksumSum and ospfAreaLSACksumSum in [7], allowing a network management station to verify OSPF database synchronization among routers. However, these variables are sums of the individual LSAs' LS checksum fields, which are no longer guaranteed to be identical across demand circuits (because the LS checksum covers the LS Sequence Number, which will in general differ across demand circuits). This means that these variables can no longer be used to verify database synchronization in OSPF Moy [Page 20] Internet Draft OSPF over Demand Circuits May 1994 networks containing demand circuits. Moy [Page 21] Internet Draft OSPF over Demand Circuits May 1994 A. The Options field The OSPF Options field is present in OSPF Hello packets, Database Description packets and all LSAs. The Options field enables OSPF routers to support (or not support) optional capabilities, and to communicate their capability level to other OSPF routers. Through this mechanism routers of differing capabilities can be mixed within an OSPF routing domain. The memo defines one of the Option bits: the DC-bit (for Demand Circuit capability). The DC-bit is set in a router's router-LSA if and only if it supports the functionality defined in Section 3 of this memo. Note that this does not necessarily mean that the router can be the endpoint of a demand circuit, but only that it can properly process LSAs having the DoNotAge bit set. In contrast, the DC-bit is set in Hello Packets and Database Description Packets sent out an interface if and only if the router wants to treat the attached network as a demand circuit (see Section 3.1). The addition of the DC-bit makes the current assignment of the OSPF Options field as follows: +------------------------------------+ | * | * | DC | EA | N/P | MC | E | T | +------------------------------------+ Figure 5: The OSPF Options field T-bit This bit describes TOS-based routing capability, as specified in [1]. E-bit This bit describes the way AS-external-LSAs are flooded, as described in [1]. MC-bit This bit describes whether IP multicast datagrams are forwarded according to the specifications in [4]. N/P-bit This bit describes the handling of Type-7 LSAs, as specified in [3]. EA-bit This bit describes the router's willingness to receive and forward External Attributes LSAs, as specified in [5]. Moy [Page 22] Internet Draft OSPF over Demand Circuits May 1994 DC-bit This bit describes the handling of demand circuits, as specified in this memo. Its setting in Hellos and Database Description Packets is described in Section 3.1. Its setting in LSAs is described in Section 2.3. B. Configurable Parameters This memo defines a single additional configuration parameter for OSPF interfaces. In addition, the OSPF Interface configuration parameter PollInterval, previously used only on NBMA networks, is now also used on point-to-point networks (see Section 3.3). DemandInterface Indicates whether the interface connects to a demand circuit. When set to TRUE, the procedures described in Section 3 of this memo are followed, in order to send a minimum of routing traffic over the demand circuit. On point-to-point networks, this allows the circuit to be closed when not carrying application traffic. When the demand interface is configured to be a broadcast or NBMA network (see Section 1.2 of [1]), the circuit will be kept open constantly due to OSPF Hello traffic, but the amount of flooding traffic will still be greatly reduced. C. Architectural Constants This memo defines a single additional OSPF architectural constant. DoNotAge Equal to the hexadecimal value 0x8000, or the high bit of the 16-bit LS Age field in OSPF LSAs. When this bit is set in the LS age field, the LSA is not aged as it is held in the router's link state database. This allows the elimination of the periodic LSA refresh over demand circuits. See Section 2.1 for more information on processing the DoNotAge bit. Moy [Page 23] Internet Draft OSPF over Demand Circuits May 1994 References [1] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994. [2] Meyer, G., "Extensions to RIP to Support Demand Circuits", RFC 1582, Spider Systems, February 1994. [3] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, RainbowBridge Communications, Stanford University, March 1994. [4] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc., March 1994. [5] Ferguson, D., "The OSPF External Attributes LSA", Internet Draft, draft-ietf-ospf-extattr-00.txt, March 1993. [6] Moy, J., editor, "OSPF protocol analysis", RFC 1245, Proteon, Inc., July 1991. [7] Baker F. and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1253, ACC, University of Maryland, August 1991. [8] Baker F., "OSPF Point-to-MultiPoint Interface", Internet Draft, draft-ietf-ospf-pmp-if-00.txt, ACC, March 1994. Security Considerations Security issues are not discussed in this memo. Author's Address John Moy Proteon, Inc. 9 Technology Drive Westborough, MA 01581 Phone: 508-898-2800 Fax: 508-898-3176 Email: jmoy@proteon.com This document expires in November 1994. Moy [Page 24]