diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc1793.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc1793.txt')
| -rw-r--r-- | doc/rfc/rfc1793.txt | 1795 |
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc1793.txt b/doc/rfc/rfc1793.txt new file mode 100644 index 0000000..f7ab70a --- /dev/null +++ b/doc/rfc/rfc1793.txt @@ -0,0 +1,1795 @@ + + + + + + +Network Working Group J. Moy +Request for Comments: 1793 Cascade +Category: Standards Track April 1995 + + + Extending OSPF to Support Demand Circuits + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo defines enhancements to the OSPF protocol that allow + efficient operation over "demand circuits". Demand circuits are + network segments whose costs vary with usage; charges can be based + both on connect time and on bytes/packets transmitted. Examples of + demand circuits include ISDN circuits, X.25 SVCs, and dial-up lines. + The periodic nature of OSPF routing traffic has until now required a + demand circuit's underlying data-link connection to be constantly + open, resulting in unwanted usage charges. With the modifications + described herein, OSPF Hellos and the refresh of OSPF routing + information are suppressed on demand circuits, allowing the + underlying data-link connections 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, which + in effect still requires that the data-link connections remain + 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- + + + +Moy [Page 1] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + to-MultiPoint Interface). + + This memo provides functionality similar to that specified for RIP in + [2], with the main difference being the way the two proposals handle + oversubscription (see Sections 4.3 and 7 below). However, because + OSPF employs link-state routing technology as opposed to RIP's + Distance Vector base, the mechanisms used to achieve the demand + circuit 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, Dawn Li, Gerry Meyer, Tom Pusateri and Zhaohui + Zhang. This memo is a product of the OSPF Working Group. + +Table of Contents + + 1. Model for demand circuits .............................. 3 + 2. Modifications to all OSPF routers ...................... 4 + 2.1 The OSPF Options field ................................. 4 + 2.2 The LS age field ....................................... 5 + 2.3 Removing stale DoNotAge LSAs ........................... 6 + 2.4 A change to the flooding algorithm ..................... 6 + 2.5 Interoperability with unmodified OSPF routers .......... 7 + 2.5.1 Indicating across area boundaries ...................... 8 + 2.5.1.1 Limiting indication-LSA origination .................... 9 + 3. Modifications to demand circuit endpoints ............. 10 + 3.1 Interface State machine modifications ................. 10 + 3.2 Sending and Receiving OSPF Hellos ..................... 11 + 3.2.1 Negotiating Hello suppression ......................... 11 + 3.2.2 Neighbor state machine modifications .................. 12 + 3.3 Flooding over demand circuits ......................... 12 + 3.4 Virtual link support .................................. 13 + 3.5 Point-to-MultiPoint Interface support ................. 14 + 4. Examples .............................................. 15 + 4.1 Example 1: Sole connectivity through demand circuits .. 15 + 4.2 Example 2: Demand and non-demand circuits in parallel . 19 + 4.3 Example 3: Operation when oversubscribed .............. 23 + 5. Topology recommendations .............................. 25 + 6. Lost functionality .................................... 25 + 7. Future work: Oversubscription ......................... 26 + 8. Unsupported capabilities .............................. 28 + A. Format of the OSPF Options field ...................... 30 + B. Configurable Parameters ............................... 31 + C. Architectural Constants ............................... 31 + References ............................................ 32 + + + +Moy [Page 2] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + Security Considerations ............................... 32 + Author's Address ...................................... 32 + +1. Model for demand circuits + + In this memo, demand circuits refer to those network segments whose + cost depends on either connect time and/or 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). When/if the data-link connection is established, the data is + sent, and the connection 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 circuit's data-link connection may be closed at any + particular time, it is assumed by the routing layer (i.e., OSPF) that + the circuit 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 established + 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. When a router cannot + simultaneously open all of its circuits' underlying data-link + connections due to resource limitations, we say that the router is + oversubscribed. In these cases, datagrams to be forwarded out the + (temporarily unopenable) data-link connections are discarded, instead + of being queued. Note also that this temporary inability to open + data-link connections due to oversubscription is NOT reported by the + OSPF routing system as unreachability; see Section 4.3 for more + information. + + + + + +Moy [Page 3] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + Either end of a demand circuit may attempt to open the data-link + connection. When both ends attempt to open the connection + simultaneously, there is the possibility of call collision. Not all + data-links specify how call collisions are handled. Also, while OSPF + requires that all periodic timers be randomized to avoid + synchronization (see Section 4.4 of [1]), if call attempts are + strictly data-driven there may still be insufficient spacing of call + attempts to avoid collisions on some data-links. For these reasons, + for those data-links without collision detection/avoidance support, + it is suggested (but not specified herein) that an exponential + backoff scheme for call retries be employed at the data-link layer. + Besides helping with call collisions, such a scheme could minimize + charges (if they exist) for failed call attempts. + + As a result of the physical implementation of some demand circuits, + only one end of the circuit may be capable of opening the data-link + connection. For example, some async modems can initiate calls, but + cannot accept incoming calls. In these cases, since connection + initiation in this memo is data-driven, care must be taken to ensure + that the initiating application party is located at the calling end + of the demand circuit. + +2. Modifications to all OSPF routers + + While most of the modifications to support demand circuits are + isolated to the demand circuit endpoints (see Section 3), there are + changes required of all OSPF routers. These changes are described in + the subsections below. + + 2.1. The OSPF Options field + + A new bit is added to the OSPF Options field to support the demand + circuit extensions. This bit is called the "DC-bit". The resulting + format of the Options field is described in Appendix A. + + A router implementing the functionality described in Section 2 of + this memo sets the DC-bit in the Options field of all LSAs that it + originates. This is regardless of the LSAs' LS type, and also + regardless of whether the router implements the more substantial + modifications required of demand circuit endpoints (see Section + 3). Setting the DC-bit in self-originated LSAs tells the rest of + the routing domain that the router can correctly process DoNotAge + LSAs (see Sections 2.2, 2.3 and 2.5). + + There is a single exception to the above rule. A router + implementing Section 2 of this memo may sometimes originate an + "indication-LSA"; these LSAs always have the DC-bit clear. + Indication-LSAs are used to convey across area boundaries the + + + +Moy [Page 4] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + existence of routers incapable of DoNotAge processing; see Section + 2.5.1 for details. + + 2.2. The LS age field + + The semantics of the LSA's LS age field are changed, allowing the + high bit of the LS age field to be set. This bit is called + "DoNotAge"; see Appendix C for its formal definition. 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 bit set as "DoNotAge+x", while an LS + age expressed as just "x" is assumed to not have the DoNotAge bit + set. LSAs having DoNotAge set are also sometimes referred to as + "DoNotAge LSAs". + + 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 must have their DoNotAge + bits masked off. For example, in determining which LSA is more + recent, LS ages of 1 and DoNotAge+1 are 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. In + particular, DoNotAge+MaxAge is equivalent to MaxAge; however for + backward-compatibility the MaxAge form should always be used when + flushing LSAs from the routing domain (see Section 14.1 of [1]). + + Thus, the set of allowable values for the LS age field fall into + the two ranges: 0 through MaxAge and DoNotAge through + DoNotAge+MaxAge. (Previously the LS age field could not exceed + the value of MaxAge.) Any LS age field not falling into these two + ranges should be considered to be equal to MaxAge. + + When an LSA is flooded out an 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. If the LS age field reaches + DoNotAge+MaxAge during flooding, the LSA is flushed from the + routing domain. This preserves the protection in [1] afforded + against flooding loops. + + 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] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + 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 in other routers' databases whose + DoNotAge bits were mistakenly set. + + 2.3. Removing stale DoNotAge 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 a DoNotAge LSA if BOTH of the following conditions are met: + + (1) The LSA has been in the router's database for at least + MaxAge seconds. + + (2) The originator of the LSA has been unreachable (according to + the routing calculations specified by Section 16 of [1]) for + at least MaxAge seconds. + + For an example, see Time T8 in the example of Section 4.1. Note + that the above functionality is an exception to the general OSPF + rule that a router can only flush (i.e., prematurely age; see + Section 14.1 of [1]) its own self-originated LSAs. The above + functionality pertains only to DoNotAge LSAs. An LSA having + DoNotAge clear still can be prematurely aged only by its + originator; otherwise, the LSA must age naturally to MaxAge before + being removed from the routing domain. + + An interval as long as MaxAge has been chosen to avoid any + possibility of thrashing (i.e., flushing an LSA only to have it + reoriginated soon afterwards). Note that by the above rules, a + DoNotAge LSA will be removed from the routing domain no faster + than if it were being aged naturally (i.e., if DoNotAge were not + set). + +2.4. A change to the flooding algorithm + + The following change is made to the OSPF flooding algorithm. When + a Link State Update Packet is received that contains an LSA + instance which is actually less recent than the the router's + current database copy, the router must now process the LSA as + follows (modifying Step 8 of Section 13 in [1] accordingly): + + + + + +Moy [Page 6] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + o If the database copy has LS age equal to MaxAge and LS + sequence number equal to MaxSequenceNumber, simply discard + the received LSA without acknowledging it. (In this case, + the LSA's sequence number is wrapping, and the + MaxSequenceNumber LSA must be completely flushed before any + new LSAs can be introduced). This is identical to the + behavior specified by Step 8 of Section 13 in [1]. + + o Otherwise, send the database copy back to the sending + neighbor, encapsulated within a Link State Update Packet. In + so doing, do not put the database copy of the LSA on the + neighbor's link state retransmission list, and do not + acknowledge the received (less recent) LSA instance. + + This change is necessary to support flooding over demand circuits. + For example, see Time T4 in the example of Section 4.2. + + However, this change is beneficial when flooding over non-demand + interfaces as well. For this reason, the flooding change pertains + to all interfaces, not just interfaces to demand circuits. The + main example involves MaxAge LSAs. There are times when MaxAge + LSAs stay in a router's database for extended intervals: 1) when + they are stuck in a retransmission queue on a slow link or 2) when + a router is not properly flushing them from its database, due to + software bugs. The prolonged existence of these MaxAge LSAs can + inhibit the flooding of new instances of the LSA. New instances + typically start with the initial LS sequence number, and are + treated as less recent (and hence discarded) by routers still + holding MaxAge instances. However, with the above change to + flooding, a router with a MaxAge instance will respond back with + the MaxAge instance. This will get back to the LSA's originator, + which will then pick the next highest LS sequence number and + reflood, overwriting the MaxAge instance. + + This change will be included in future revisions of the base OSPF + specification [1]. + + 2.5. Interoperability with unmodified OSPF routers + + Unmodified OSPF routers will probably treat DoNotAge LSAs as if + they had LS age of MaxAge. At the very worst, this will cause + continual retransmissions of the DoNotAge LSAs. (An example + scenario follows. Suppose Routers A and B are connected by a + point-to-point link. Router A implements the demand circuit + extensions, Router B does not. Neither one treats their connecting + link as a demand circuit. At some point in time, Router A receives + from another neighbor via flooding a DoNotAge LSA. The DoNotAge + LSA is then flooded by Router A to Router B. Router B, not + + + +Moy [Page 7] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + understanding DoNotAge LSAs, treats it as a MaxAge LSA and + acknowledges it as such to Router A. Router A receives the + acknowledgment, but notices that the acknowledgment is for a + different instance, and so starts retransmitting the LSA.) + + However, to avoid this confusion, DoNotAge LSAs will be allowed in + an OSPF area if and only if, in the area's link state database, + all LSAs have the DC-bit set in their Options field (see Section + 2.1). Note that it is not required that the LSAs' Advertising + Router be reachable; if any LSA is found not having its DC-bit set + (regardless of reachability), then the router should flush (i.e., + prematurely age; see Section 14.1 of [1]) from the area all + DoNotAge LSAs. These LSAs will then be reoriginated at their + sources, this time with DoNotAge clear. Like the change in + Section 2.3, this change is an exception to the general OSPF rule + that a router can only flush its own self-originated LSAs. Both + changes pertain only to DoNotAge LSAs, and in both cases a flushed + LSA's LS age field should be set to MaxAge and not + DoNotAge+MaxAge. + + 2.5.1. Indicating across area boundaries + + AS-external-LSAs are flooded throughout the entire OSPF routing + domain, excepting only OSPF stub areas and NSSAs. For that + reason, if an OSPF router that is incapable of DoNotAge + processing exists in any "regular" area (i.e., an area that is + not a stub nor an NSSA), no AS-external-LSA can have DoNotAge + set. This memo simplifies that requirement by broadening it to + the following rule: LSAs in regular OSPF areas are allowed to + have DoNotAge set if and only if every router in the OSPF + domain (excepting those in stub areas and NSSAs) is capable of + DoNotAge processing. The rest of this section describes how the + rule is implemented. + + As described above in Sections 2.1 and 2.5, a router indicates + that it is capable of DoNotAge processing by setting the DC-bit + in the LSAs that it originates. However, there is a problem. It + is possible that, in all areas to which Router X directly + attaches, all the routers are capable of DoNotAge processing, + yet there is some router in a remote "regular" area that cannot + process DoNotAge LSAs. This information must then be conveyed + to Router X, so that it does not mistakenly flood/create + DoNotAge LSAs. + + The solution is as follows. Area border routers transmit the + existence of DoNotAge-incapable routers across area boundaries, + using "indication-LSAs". Indication-LSAs are type-4-summary + LSAs (also called ASBR-summary-LSAs), listing the area border + + + +Moy [Page 8] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + router itself as the described ASBR, with the LSA's cost set to + LSInfinity and the DC-bit clear. Note that indication-LSAs + convey no additional information; in particular, they are used + even if the area border router is not really an AS boundary + router (ASBR). + + Taking indication-LSAs into account, the rule as to whether + DoNotAge LSAs are allowed in any particular area is EXACTLY the + same as given previously in Section 2.5, namely: DoNotAge LSAs + will be allowed in an OSPF area if and only if, in the area's + link state database, all LSAs have the DC-bit set in their + Options field. + + Through origination of indication-LSAs, the existence of + DoNotAge-incapable routers can be viewed as going from non- + backbone regular areas, to the backbone area and from there to + all other regular areas. The following two cases summarize the + requirements for an area border router to originate + indication-LSAs: + + (1) Suppose an area border router (Router X) is connected to + a regular non-backbone OSPF area (Area A). Furthermore, + assume that Area A has LSAs with the DC-bit clear, other + than indication-LSAs. Then Router X should originate + indication-LSAs into all other directly-connected + "regular" areas, including the backbone area, keeping + the guidelines of Section 2.5.1.1 in mind. + + (2) Suppose an area border router (Router X) is connected to + the backbone OSPF area (Area 0.0.0.0). Furthermore, + assume that the backbone has LSAs with the DC-bit clear + that are either a) not indication-LSAs or b) + indication-LSAs that have been originated by routers + other than Router X itself. Then Router X should + originate indication-LSAs into all other directly- + connected "regular" non-backbone areas, keeping the + guidelines of Section 2.5.1.1 in mind. + + 2.5.1.1. Limiting indication-LSA origination + + To limit the number of indication-LSAs originated, the + following guidelines should be observed by an area border + router (Router X) when originating indication-LSAs. First, + indication-LSAs are not originated into an Area A when A + already has LSAs with DC-bit clear other than indication- + LSAs. Second, if another area border router has originated a + indication-LSA into Area A, and that area border router has + a higher OSPF Router ID than Router X (same tie-breaker as + + + +Moy [Page 9] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + for forwarding address origination; see Section 12.4.5 of + [1]), then Router X should not originate an indication-LSA + into Area A. + + As an example, suppose that three regular OSPF areas (Areas + A, B and C) are connected by routers X, Y and Z + (respectively) to the backbone area. Furthermore, suppose + that all routers are capable of DoNotAge processing, except + for routers in Areas A and B. Finally, suppose that Router + Z has a higher Router ID than Y, which in turn has a higher + Router ID than X. In this case, two indication-LSAs will be + generated (if the rules of Section 2.5.1 and the guidelines + of the preceding paragraph are followed): Router Y will + originate an indication-LSA into the backbone, and Router Z + will originate an indication-LSA into Area C. + +3. Modifications to demand circuit endpoints + + The following subsections detail the modifications required of the + routers at the endpoints of demand circuits. These consist of + modifications to two main pieces of OSPF: 1) sending and receiving + Hello Packets over demand circuits and 2) flooding LSAs over demand + circuits. + + An additional OSPF interface configuration parameter, ospfIfDemand, + is defined to indicate whether an OSPF interface connects to a demand + circuit (see Appendix B). Two routers connecting to a common network + segment need not agree on that segment's demand circuit status. + However, to get full benefit of the demand circuit extensions, the + two ends of a point-to-point link must both agree to treat the link + as a demand circuit (see Section 3.2). + + 3.1. Interface State machine modifications + + An OSPF point-to-point interface connecting to a demand circuit is + considered to be in state "Point-to-point" if and only if its + associated neighbor is in state "1-Way" or greater; otherwise the + interface is considered to be in state "Down". Hellos are sent out + such an interface when it is in "Down" state, at the reduced + interval of PollInterval. If the negotiation in Section 3.2.1 + succeeds, Hellos will cease to be sent 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" (see Section 3.2.2). + + + + + +Moy [Page 10] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + For OSPF broadcast and NBMA networks that have been configured as + demand circuits, there are no changes to the Interface State + Machine. + + 3.2. Sending and Receiving OSPF Hellos + + The following sections describe the required modifications to OSPF + Hello Packet processing on point-to-point demand circuits. + + 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.2.1. Negotiating Hello suppression + + On point-to-point demand circuits, both endpoints must agree to + suppress the sending of Hello Packets. To ensure this + agreement, a 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 suppress Hellos. In + these latter cases, the router reverts to the normal periodic + sending of Hello Packets out the interface (see Section 9.5 of + [1]). + + A demand point-to-point circuit need be configured in only one + of the two endpoints (see Section 4.1). If a router + implementing Sections 2 and 3 of this memo receives an Hello + Packet with the DC-bit set, it should treat the point-to-point + link as a demand circuit, making the appropriate changes to its + Hello Processing (see Section 3.2.2) and flooding (see Section + 3.3). + + Even if the above negotiation fails, the router should continue + setting the DC-bit in its Hellos and Database Descriptions (the + neighbor will just ignore the bit). The router will then + automatically attempt to renegotiate Hello suppression whenever + the link goes down and comes back up. For example, if the + neighboring router is rebooted with software that is capable of + operating over demand circuits (i.e., implements Sections 2 and + 3 of this memo), a future negotiation will succeed. + + + +Moy [Page 11] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + Also, even if the negotiation to suppress Hellos fails, the + flooding modifications described in Section 3.3 are still + performed over the link. + + 3.2.2. Neighbor state machine modifications + + When the above negotiation succeeds, Hello Packets are sent + over point-to-point demand circuits 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 discouraging 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 demand circuit + neighbors in state "Loading" or "Full" can no longer be + required. In other words, the InactivityTimer event defined in + Section 10.2 of [1] has no effect on demand circuit neighbors + in state "Loading" or "Full". An additional clarification is + needed in the Neighbor State Machine's LLDown event. For demand + circuits, this event should be mapped into the "discouraging + diagnostic code" discussed previously in Section 1, and should + not be generated when the data-link connection has been closed + simply to save resources. Nor should LLDown be generated if a + data-link connection fails due to temporary lack of resources. + + 3.3. 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 LSAs in the database must have the DC-bit set. If + one or more LSAs have the DC-bit clear, flooding over demand + circuits is unchanged from [1]. Otherwise, flooding is changed as + follows. + + (1) 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 + + + +Moy [Page 12] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + 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 or both 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. + + (2) When it has been decided to flood an LSA over a demand + circuit, DoNotAge should be set in the copy of the LSA that + is flooded out the demand interface. (There is one + exception: DoNotAge should not be set if the LSA's LS age is + equal to MaxAge.) Setting DoNotAge will cause the routers on + the other side of the demand circuit to hold the LSA in + their databases 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 + flooded copy's LS age field must also be incremented by + InfTransDelay (see Step 5 of Section 13.3 in [1], and + Section 2.2 of this memo), as protection against flooding + loops. + + The previous paragraph also pertains to LSAs flooded over + demand circuits in response to Link State Requests. It also + pertains to LSAs that are retransmitted over demand + circuits. + + 3.4. Virtual link support + + OSPF virtual links are essentially unnumbered point-to-point links + (see Section 15 of [1]). Accordingly, demand circuit support for + virtual links resembles that described for point-to-point links in + the previous sections. The main difference is that a router + implementing Sections 2 and 3 of this memo, and supporting virtual + links, always treats virtual links as if they were demand + circuits. Otherwise, when a virtual link's underlying physical + path contains one or more demand circuits, periodic OSPF protocol + exchanges over the virtual link would unnecessarily keep the + + + +Moy [Page 13] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + underlying demand circuits open. + + Demand circuit support on virtual links can be summarized as + follows: + + o Instead of modifying the Interface state machine for virtual + links as was done for point-to-point links in Section 3.1, + the Interface state machine for virtual links remains + unchanged. A virtual link is considered to be in state + "Point-to-point" if an intra-area path (through the virtual + link's transit area) exists to the other endpoint. Otherwise + it is considered to be in state "Down". See Section 15 of + [1] for more details. + + o Virtual links are always treated as demand circuits. In + particular, over virtual links a router always negotiates to + suppress the sending of Hellos. See Sections 3.2.1 and 3.2.2 + for details. + + o In the demand circuit support over virtual links, there is + no "discouraging diagnostic code" as described in Section 1. + Instead, the connection is considered to exist if and only + if an intra-area path (through the virtual link's transit + area) exists to the other endpoint. See Section 15 of [1] + for more details. + + o Since virtual links are always treated as demand circuits, + flooding over virtual links always proceeds as in Section + 3.3. + + 3.5. Point-to-MultiPoint Interface support + + The OSPF Point-to-MultiPoint interface has recently been developed + for use with non-mesh-connected network segments. A common example + is a Frame Relay subnet where PVCs are provisioned between some + pairs of routers, but not all pairs. In this case the Point-to- + Multipoint interface represents the single physical interface to + the Frame relay network, over which multiple point-to-point OSPF + conversations (one on each PVC) are taking place. For more + information on the Point-to-MultiPoint interface, see [8]. + + Since an OSPF Point-to-MultiPoint interface essentially consists + of multiple point-to-point links, demand circuit support on the + Point-to-Multipoint interface strongly resembles demand circuit + support for point-to-point links. However, since the Point-to- + MultiPoint interface requires commonality of its component point- + to-point links' configurations, there are some differences. + + + + +Moy [Page 14] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + Demand circuit support on Point-to-Multipoint interfaces can be + summarized as follows: + + o Instead of modifying the Interface state machine for Point- + to-Multipoint interfaces as was done for point-to-point + links in Section 3.1, the Interface state machine for + Point-to-Multipoint interfaces remains unchanged. + + o When ospfIfDemand is set on a Point-to-MultiPoint interface, + the router tries to negotiate Hello suppression separately + on each of interface's component point-to-point links. This + negotiation proceeds as in Section 3.2.1. Negotiation may + fail on some component point-to-point links, and succeed on + others. This is acceptable. On those component links where + the negotiation fails, Hellos will always be sent; + otherwise, Hellos will cease to be sent when the Database + Description process completes on the component link (see + Section 3.2.2). + + o Section 3.3 defines the demand circuit flooding behavior for + all OSPF interface types. This includes Point-to-Multipoint + interfaces. + +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 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 15] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + Time T0: RTB negotiates Hello suppression + + 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 that RTB receives 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 suppress Hellos on the link, the + initial Database Description sent from Router RTC to RTB + would have the DC-bit clear, forcing Router RTB to revert to + the periodic sending of Hellos specified in Section 9.5 of + [1]. + + 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 Packets sent over the + + + + + + + | +---+ | | + +--+ |---|RTA|---| | +--+ + |H1|---| +---+ | |---|H2| + +--+ | | +---+ ODL +---+ | +--+ + |LAN Y |---|RTB|-------------|RTC|---| + + | +---+ +---+ | + + + + + + Figure 1: In the example of Section 4.1, + a single demand circuit (labeled + ODL) bisects an internetwork. + + + + + + + + + + + + + +Moy [Page 16] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + +---+ +---+ + |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 Hello + suppression. + + 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. + + + 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: After Time T1 in Section 4.1, + possible LS age fields on either + side of 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. + + + + + +Moy [Page 17] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + 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 would 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. + + 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. + + + + + + + +Moy [Page 18] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + 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 + it has the DoNotAge bit set. However, according to Section + 2.3 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 initially 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. + + + + + + + + + + + + + +Moy [Page 19] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + The following events may then transpire: + + + + + +---+ | + |RTC|--| + + +---+ | +---+ | + + / |--|RTE|--| +--+ + +--+ | /ODL | +---+ |--|H2| + |H1|----| +---+ +---+/ | + +--+ + +--+ |--|RTA|-------|RTB| | + | +---+ +---+\ | + + + \ | +---+ | + \ |--|RTY|--| + +---+ | +---+ | + |RTD|--| + + +---+ | + + + + Figure 3: Example 2's 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. + + + 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 their database copies + of RTA's and RTB's router-LSAs. 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 20] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + 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 in Example 2, 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 in Example 2, 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 in Example 2, 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 in Example 2, LS age + fields on the right side of Router RTB. + + + + + + +Moy [Page 21] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + Time T1: Underlying data-link connection is torn down. + + 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 inoperational, 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. After flooding the new LSA, 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 aged out + and reflooded (by router RTE in our example). Because this + aged out LSA constitutes a real change (see Section 3.3), it + is flooded over the demand circuit from Router RTC to RTB. + There are then two possible scenarios. First, the LS + Sequence number for RTA's router-LSA may be larger on RTB's + 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 2.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 LSA. + + + +Moy [Page 22] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + 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 will 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.2). + + 4.3. Example 3: Operation when oversubscribed + + The following example shows the behavior of the demand circuit + extensions in the presence of oversubscribed interfaces. Note that + the example's topology excludes the possibility of alternative + paths. The combination of oversubscription and redundant topology + (i.e., alternative paths) poses special problems for the demand + circuit extensions. These problems are discussed later in Section + 7. + + 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 Basic Rate ISDN interface (2 B channels) to support + all three demand circuits, or, RT1 may be connected to a data-link + switch (e.g., an X.25 or Frame relay switch) that is only capable + of so many simultaneous data-link connections. + + The following events may transpire, starting with Router RT1 + coming up. + + + + + + + + + +Moy [Page 23] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + Time T0: Router RT1 comes up. + + Router RT1 attempts to establish neighbor connections and + synchronize OSPF databases with routers RT2-RT4. But, + + + + +--+ + +---+ |--|H2| + +---------|RT2|--| +--+ + / +---+ | + / ODL + + +--+ + / + |H1|--| / + + +--+ | +---+ ODL +---+ | +--+ + |--|RT1|------------|RT3|--|--|H3| + | +---+ +---+ | +--+ + | \ + + + \ODL + \ + +--+ + \ +---+ |--|H4| + +--------|RT4|--| +--+ + +---+ | + + + + + Figure 4: Example 3's internetwork. + + + + 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 H2, the underlying data-link connection to RT2 will + eventually close due to inactivity. This will allow RT1 to + finally synchronize with RT4; the next Hello 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, H4 will have been considered unreachable by + OSPF routing. However, data traffic would not have been + deliverable to H4 until now in any case. + + + + + + + +Moy [Page 24] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + 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 open 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 + Section 1). This means that the routers RT1, RT3 and RT4 + will not detect the unreachability of Host H2 until a data- + link connection on RT1 becomes available. + +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.5), 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. + + + + + + +Moy [Page 25] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + Database Checksum + OSPF supplies network management variables, namely + 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 + networks containing demand circuits. + +7. Future work: Oversubscription + + An internetwork is oversubscribed when not all of its demand + circuits' underlying connections can be open at once, due to resource + limitations. These internetworks were addressed in Section 4.3. + However, when all possible sources in the internetwork are active at + once, problems can occur which are not addressed in this memo: + + (1) There is a network design problem. Does a subset of demand + circuits exist such that a) their data-link connections can be + open simultaneously and b) they can provide connectivity for all + possible sources? This requires that (at least) a spanning tree + be formed out of established connections. Figure 4 shows an + example where this is not possible; Hosts H1 through H4 cannot + simultaneously talk, since Router RT1 is limited to two + simultaneously open demand circuits. + + (2) Even if it is possible that a spanning tree can form, will one? + Given the model in Section 1, demand circuits are brought up + when needed for data traffic, and stay established as long as + data traffic is present. One example is shown in Figure 5. Four + routers are interconnected via demand circuits, with each router + being able to establish a circuit to any other. However, we + assume that each router can only have two circuits open at once + (e.g., the routers could be using Basic Rate ISDN). In this + case, one would hope that the data-link connections in Figure 5a + would form. But the connections in Figure 5b are equally + likely, which leave Host H2 unable to communicate. + + One possible approach to this problem would be for a) the OSPF + database to indicate which demand circuits have actually been + established and b) implement a distributed spanning tree + construction (see for example Chapter 5.2.2 of [9]) when + necessary. + + + + + +Moy [Page 26] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + (3) Even when a spanning tree has been built, will it be used? + Routers implementing the functionality described in this memo do + not necessarily know which data-link connections are established + at any one time. In fact, they view all demand circuits as being + equally available, whether or not they are currently + established. So for example, even when the established + connections form the pattern in Figure 5a, Router RT1 may still + believe that the best path to Router RT3 is through the direct + demand circuit. However, this circuit cannot be established due + to resource shortages. + + + + + + +--+ + + +--+ + |H1|--| +---+ ODL +---+ |--|H2| + +--+ |--|RT1|-------|RT2|--| +--+ + | +---+ +---+ | + + | \ / | + + | \ / | + | \ / | + |ODL / |ODL + | / \ODL | + | / \ | + + | /ODL \ | + + +--+ | +---+ +---+ | +--+ + |H4|--|--|RT4|-------|RT3|--|--|H3| + +--+ | +---+ ODL +---+ | +--+ + + + + + + Figure 5: Example of an oversubscribed + internetwork + + + + + + + + + + + + + + + + + +Moy [Page 27] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + +---+ +---+ +---+ +---+ + |RT1|-------|RT2| |RT1| |RT2| + +---+ +---+ +---+ +---+ + | | | \ + | | | \ + | | | \ + | | | \ + | | | \ + | | | \ + | | | \ + +---+ +---+ +---+ +---+ + |RT4|-------|RT3| |RT4|-------|RT3| + +---+ +---+ +---+ +---+ + + Figure 5a: One possible Figure 5b: Another possible + pattern of data-link pattern of data-link + connections connections + + On possible approach to this problem is to increase the OSPF cost of + demand circuits that are currently discarding application packets + (i.e., can't be established) due to resource shortages. This may help + the routing find paths that can actually deliver the packets. On the + downside, it would create more routing traffic. Also, unwanted + routing oscillations may result when you start varying routing + metrics to reflect dynamic network conditions; see [10]. + +8. Unsupported capabilities + + The following possible capabilities associated with demand circuit + routing have explicitly not been supported by this memo: + + o When the topology of an OSPF area changes, the changes are + flooded over the area's demand circuits, even if this requires + (re)establishing the demand circuits' data-link connections. One + might imagine a routing system where the flooding of topology + changes over demand circuits were delayed until the demand + circuits were (re)opened for application traffic. However, this + capability is unsupported because delaying the flooding in this + manner would sometimes impair the ability to discover new + network destinations. + + o Refining the previous capability, one might imagine that the + network administrator would be able to configure for each demand + interface whether flooding should be immediate, or whether it + should be delayed until the data-link connection is established + for application traffic. This would allow certain "application- + specific" routing behaviors. For example, a demand circuit may + connect a collection of client-based subnets to a collection of + + + +Moy [Page 28] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + server-based subnets. If the client end was configured to delay + flooding, while the server end was configured to flood changes + immediately, then new servers would be discovered promptly while + clients might not be discovered until they initiate + conversations. However, this capability is unsupported because + of the increased complexity of (and possibility for error in) + the network configuration. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moy [Page 29] + +RFC 1793 OSPF over Demand Circuits April 1995 + + +A. Format of the OSPF 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 self-originated + LSAs if and only if it supports the functionality defined in Section + 2 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 point-to-point network as a demand circuit (see Section + 3.2.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]. + + + + + +Moy [Page 30] + +RFC 1793 OSPF over Demand Circuits April 1995 + + + EA-bit + This bit describes the router's willingness to receive and + forward External-Attributes-LSAs, as specified in [5]. + + 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 Sections 3.2.1 and 3.2.2. Its setting in + LSAs is described in Sections 2.1 and 2.5. + +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 Sections 3.1 and 3.2.2). + + ospfIfDemand + 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 a broadcast or NBMA interface is configured to connect to a + demand circuit (see Section 1.2 of [1]), the data-link + connections 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, which is 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.2 for + more information on processing the DoNotAge bit. + + + + + + + + + + + +Moy [Page 31] + +RFC 1793 OSPF over Demand Circuits April 1995 + + +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", Work in + Progress. + + [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", Work in Progress. + + [9] Bertsekas, D., and R. Gallager, "Data Networks", Prentice Hall, + Inc., 1992. + + [10] Khanna, A., "Short-Term Modifications to Routing and Congestion + Control", BBN Report 6714, BBN, February 1988. + +Security Considerations + + Security issues are not discussed in this memo. + +Author's Address + + John Moy + Cascade Communications Corp. + 5 Carlisle Road + Westford, MA 01886 + + Phone: 508-692-2600 Ext. 394 + Fax: 508-692-9214 + EMail: jmoy@casc.com + + + + + + + +Moy [Page 32] + |