RFC 1793
Extending OSPF to Support Demand Circuits
RFC 1793: Extending OSPF to Support Demand Circuits 🎀
Part 1 of 7, so more is coming 💖
- Series: Network Working Group, RFC 1793
- Author: J. Moy, from Cascade 🧑💻
- Category: Standards Track ✅
- Date: April 1995 📅
- Obsoletes and updates: nothing is listed in this title block, so it doesn't say it obsoletes or updates any earlier RFC 🙈
Status of this Memo 📜
This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements 💬. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔍. Distribution of this memo is unlimited 🌈.
Abstract ✨
Okay bestie, this memo adds upgrades to OSPF so it can run efficiently over "demand circuits" 💖. Demand circuits are network segments where the cost depends on how much you use them, since you can get charged for connect time, for bytes or packets sent, or for both 💸. Examples are ISDN circuits, X.25 SVCs and dial-up lines 📞.
OSPF's routing traffic is periodic, so until now a demand circuit's underlying data-link had to stay open all the time, and that racked up unwanted usage charges 😭. With the changes in this memo, OSPF Hellos and the refresh of OSPF routing information are suppressed on demand circuits. That means the data-link connections can close whenever they aren't carrying application traffic 🦋.
Demand circuits and regular network segments (like leased lines) can be combined in any manner, so there are no topological restrictions on demand circuit support 🗺️. However, while any OSPF network segment can be defined as a demand circuit, only point-to-point networks get the full benefit 🎯. When broadcast and NBMA networks are declared demand circuits, routing update traffic goes down but the periodic sending of Hellos doesn't, so the data-link connections still end up needing to stay constantly open 💀.
This is mainly for cost-conscious links like ISDN, X.25 and dial-up, but the changes may also be useful over bandwidth-limited links like slow-speed leased lines and packet radio 📻.
The enhancements here are backward-compatible with the OSPF specification in [1], and with the OSPF extensions in [3] (OSPF NSSA areas), [4] (MOSPF) and [8] (OSPF Point-to-MultiPoint Interface) 🧩.
This memo gives you functionality similar to what [2] specifies for RIP. The main difference is how the two proposals handle oversubscription (see Sections 4.3 and 7 below) 🔥. OSPF uses link-state routing instead of RIP's Distance Vector base, so the mechanisms for demand circuit functionality are pretty different 🤯.
Please send comments to ospf@gated.cornell.edu 💌.
Acknowledgments 🫶
The author would like to thank Fred Baker, Rob Coltun, Dawn Li, Gerry Meyer, Tom Pusateri and Zhaohui Zhang for their helpful comments 💜. 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
Security Considerations ............................... 32
Author's Address ...................................... 321. Model for demand circuits ⚡
Okay so demand circuits are the segments where cost depends on connect time and/or usage (measured in bytes or packets) 💸. ISDN circuits and X.25 SVCs are examples. On these circuits you want the routing protocol to send as little routing traffic as possible 📉. Honestly, if the topology hasn't changed, it's ideal for the routing protocol to send no routing traffic at all 🙌. That way the data-link connection can close whenever it isn't needed for application data 🦋.
Here's how this memo handles demand circuits. If there's nothing to send (routing protocol traffic or application data), the data-link connection stays closed 🔒. As soon as there's data to send, the router tries to open the data-link connection (for example, by placing an ISDN or X.25 call) 📞. If the connection comes up, the data gets sent, and the connection stays open until some period of time passes with no more data to send ⏳. Then it closes again to save cost and resources (see Section 1 of [2]) 💅.
This memo also uses the "Presumption of Reachability" described in [2] 🧠. Even when a circuit's data-link is closed, the routing layer (OSPF) assumes the circuit is available, unless other information says otherwise, like a discouraging diagnostic code from an attempted data-link connection 🔍.
Sometimes a data-link connection can't be established because of resource shortages 😬. For example, a router with a single basic rate ISDN interface can't open more than two simultaneous ISDN data-link connections (one for each B channel). Interface firmware and/or switch capacity may also limit how many X.25 SVCs can run at once 🚫. When a router can't open all of its circuits' data-link connections at the same time because of resource limits, we say the router is oversubscribed 🚨. In that case, datagrams to be forwarded out the temporarily unopenable data-link connections are discarded instead of queued 🗑️.
Also, this temporary inability to open data-link connections because of oversubscription is not reported by the OSPF routing system as unreachability. See Section 4.3 for more info 👀.
Either end of a demand circuit can try to open the data-link connection 🤝. If both ends try at the same time, there's a possibility of call collision 💥. Not all data-links specify how call collisions are handled. OSPF requires that all periodic timers be randomized to avoid synchronization (see Section 4.4 of [1]), but if call attempts are strictly data-driven, there may still not be enough spacing between them to avoid collisions on some data-links 😵💫. So for data-links without collision detection/avoidance support, it is suggested (but not specified herein) that an exponential backoff scheme for call retries be used at the data-link layer 🌀. Besides helping with call collisions, a scheme like this could minimize charges (if any exist) for failed call attempts 💸.
Finally, because of how some demand circuits are physically implemented, only one end may be able to open the data-link connection 🙃. For example, some async modems can initiate calls but can't accept incoming calls 📟. In these cases, connection initiation in this memo is data-driven, so you have to make sure the initiating application party is located at the calling end of the demand circuit 🧚.
(Part 1 of 7. More coming, bestie 💖)
2. Modifications to all OSPF routers ✨
okay so most of the demand circuit stuff is tucked away at the demand circuit endpoints (see Section 3) 🫶 but there are also changes that every OSPF router needs, no exceptions. we'll go through them in the subsections below 💅
2.1. The OSPF Options field 🎀
a brand new bit gets added to the OSPF Options field to power up the demand circuit extensions 🔥 it's called the "DC-bit", and the full new layout of the Options field lives in Appendix A.
a router doing the Section 2 stuff sets the DC-bit in the Options field of all the LSAs it originates 🙌 and it doesn't matter what the LS type is, or whether the router also does the bigger endpoint upgrades from Section 3. setting that bit on its own LSAs is basically a flex that tells the whole routing domain "hey, i can correctly handle DoNotAge LSAs" 💜 (see Sections 2.2, 2.3 and 2.5)
there's one exception 👀 a router following Section 2 might sometimes originate an "indication-LSA", and those always have the DC-bit clear 🦋 indication-LSAs carry the news across area boundaries about routers that can't do DoNotAge processing (see Section 2.5.1 for the deets).
2.2. The LS age field ⏰
the meaning of the LSA's LS age field has been glowed up 💖 it's now allowed to have its high bit set. that bit is called "DoNotAge" (its formal definition is in Appendix C). LSAs with the DoNotAge bit set don't get aged while they're sitting in the link state database, so they don't need the LSRefreshInterval refresh that every other OSPF LSA gets 🧚
in this memo, an LS age written as DoNotAge+x means the DoNotAge bit is set, and a plain x means it isn't 🌸 LSAs with DoNotAge set can also be called "DoNotAge LSAs" (iykyk).
when comparing two LSA instances to figure out which one is most recent, the LS age fields only get compared if the LS sequence numbers and LS checksums are identical (see Section 13.1 of [1]). before comparing, the DoNotAge bits get masked off ✨ so for example, 1 and DoNotAge+1 count as equivalent when deciding recency. an LSA flooded with LS age 1 can get acknowledged with a Link State Acknowledgement listing DoNotAge+1, or the other way around 🫶 DoNotAge+MaxAge is equivalent to MaxAge, but for backward-compatibility the MaxAge form should always be used when flushing LSAs from the routing domain (see Section 14.1 of [1]).
so the allowable LS age values fall into 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 outside those two ranges should be considered equal to MaxAge 🙈
when an LSA is flooded out an interface, the constant InfTransDelay gets added to its LS age 📬 this happens even if DoNotAge is set, but then the LS age isn't allowed to go past DoNotAge+MaxAge 🙅 if it reaches DoNotAge+MaxAge during flooding, the LSA gets flushed from the routing domain. this keeps the protection in [1] against flooding loops fully intact 🛡️
the LS age field is not checksum protected 😬 so errors in a router's memory could accidentally set an LSA's DoNotAge bit and stop it from aging. but a router should note that its own self-originated LSAs should never have the DoNotAge bit set in its own database 💅 so in any case, the router's self-originated LSAs get refreshed every LSRefreshInterval. since that refresh floods through the whole OSPF routing domain, it replaces any copies in other routers' databases whose DoNotAge bits got mistakenly set ✨
2.3. Removing stale DoNotAge LSAs 🗑️
since DoNotAge LSAs never age, they can hang around in the link state database even after their originator is gone 👻 to make sure they eventually get flushed from the routing domain, and the size of the 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, check out Time T8 in the example of Section 4.1 🍓 this 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 was chosen to avoid any possibility of thrashing (i.e., flushing an LSA only to have it reoriginated soon afterwards) 🔁 and 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 🌊
okay bestie, this is the big flooding glow-up 💅 The following change is made to the OSPF flooding algorithm. When a Link State Update Packet shows up with an LSA instance that's actually less recent than the router's current database copy, the router must now handle it like this (modifying Step 8 of Section 13 in [1] accordingly):
- If the database copy has LS age equal to
MaxAgeand LS sequence number equal toMaxSequenceNumber, simply discard the received LSA without acknowledging it. (Here the LSA's sequence number is wrapping, so theMaxSequenceNumberLSA 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]. - Otherwise, send the database copy back to the sending neighbor, encapsulated within a Link State Update Packet. When you do this, 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. MaxAge LSAs can stick around in a router's database for extended intervals, and there are two ways that happens: 1) they're stuck in a retransmission queue on a slow link, or 2) a router isn't properly flushing them from its database, because of 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, so routers still holding MaxAge instances treat them as less recent (and hence discard them) 😤. But with the above change to flooding, a router with a MaxAge instance will respond back with the MaxAge instance. That gets back to the LSA's originator, who then picks the next highest LS sequence number and reflloods, 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 😩. (Here's an example scenario. Say Routers A and B are connected by a point-to-point link. Router A implements the demand circuit extensions, but Router B does not. Neither one treats their connecting link as a demand circuit. At some point, Router A receives a DoNotAge LSA from another neighbor via flooding. Router A then floods that DoNotAge LSA to Router B. Router B doesn't understand DoNotAge LSAs, so it treats the LSA as a MaxAge LSA and acknowledges it as such to Router A. Router A gets the acknowledgment, but notices that it's for a different instance, so it starts retransmitting the LSA. Chaos 🙈.)
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]) all DoNotAge LSAs from the area. 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's incapable of DoNotAge processing exists in any "regular" area (i.e., an area that is not a stub nor an NSSA), then 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's capable of DoNotAge processing by setting the DC-bit in the LSAs that it originates. However, there's a problem 😬. It's possible that, in all areas to which Router X directly attaches, all the routers are capable of DoNotAge processing, yet there's some router in a remote "regular" area that can't process DoNotAge LSAs. This information must then be conveyed to Router X, so that it doesn't mistakenly flood or create DoNotAge LSAs.
Here's the solution. 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 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're used even if the area border router is not really an AS boundary router (ASBR) 🤷♀️.
Taking indication-LSAs into account, the rule for 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 an indication-LSA into Area A, and that area border router has a higher OSPF Router ID than Router X (same tie-breaker as for forwarding address origination; see Section 12.4.5 of [1]), then Router X should not originate an indication-LSA into Area A.
Here's an example to make it click ✨. Suppose 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 don't need to agree on that segment's demand circuit status. However, to get the 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's 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).
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 set up as demand circuits, nothing changes about how Hellos get sent and received, and the Neighbor State Machine stays the same too 💅. Why? Because the Designated Router election algorithm needs Hello Packets to keep getting exchanged periodically to work properly 🫶 no skipping allowed, bestie.
3.2.1. Negotiating Hello suppression 🦋
okay so on point-to-point demand circuits, both endpoints must agree to suppress the sending of Hello Packets 🤝. To make sure they're on the same page, a router sets the DC-bit in the OSPF Hellos and Database Description Packets it sends out the demand interface. If you receive a Hello or a Database Description Packet with the DC-bit set, that means the other side agrees ✨. If you get a Hello with the DC-bit clear that also lists your Router ID in its body, or a Database Description Packet with the DC-bit clear (either one proves bidirectional connectivity), then the other end is refusing to suppress Hellos 🙅♀️. In those cases, the router goes back to the normal periodic sending of Hello Packets out the interface (see Section 9.5 of [1]).
A demand point-to-point circuit only needs to be configured on one of the two endpoints (see Section 4.1) 🧚. If a router implementing Sections 2 and 3 of this memo receives a Hello Packet with the DC-bit set, it should treat the point-to-point link as a demand circuit, making the right changes to its Hello Processing (see Section 3.2.2) and flooding (see Section 3.3) 💖.
Even if the negotiation above fails, the router should keep setting the DC-bit in its Hellos and Database Descriptions. The neighbor will just ignore it, no drama 🙈. The router will also automatically try to renegotiate Hello suppression whenever the link goes down and comes back up. For example, if the neighboring router gets rebooted with software that can operate over demand circuits (i.e., it implements Sections 2 and 3 of this memo), a future negotiation will succeed 🎀.
Also, even if the negotiation to suppress Hellos fails, the flooding modifications described in Section 3.3 still happen over the link 🌈.
3.2.2. Neighbor state machine modifications 💜
When the negotiation above succeeds, Hello Packets only get sent over point-to-point demand circuits 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 that, Hellos are suppressed and the data-link connection to the neighbor is assumed available until evidence shows up saying otherwise 👀. If the router finds out the neighbor isn't available anymore, probably because of something like a discouraging diagnostic code in a response to a failed call request, the neighbor connection drops back to "Down" and Hellos get sent periodically (at Intervals of PollInterval) to try restarting synchronization with the neighbor 🔁.
This needs changes to the OSPF Neighbor State Machine (see Section 10.3 of [1]) 🧠. Receiving Hellos from demand circuit neighbors in state "Loading" or "Full" can no longer be required. Put another way, the InactivityTimer event defined in Section 10.2 of [1] has no effect on demand circuit neighbors in state "Loading" or "Full" 😤. There's also one more clarification needed for the Neighbor State Machine's LLDown event. For demand circuits, this event should be mapped into the "discouraging diagnostic code" we talked about earlier in Section 1, and it should not be generated when the data-link connection was closed simply to save resources 💅. And LLDown should not be generated if a data-link connection fails because of a temporary lack of resources either 🫠.
3.3. Flooding over demand circuits 🌊
Flooding over demand circuits (point-to-point or otherwise) only gets modified if all routers have indicated that they can process LSAs having DoNotAge set 🙌. You check this by looking at the link state database of the OSPF area that contains 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 stays exactly the same as in [1]. Otherwise, flooding changes like this:
- Only truly changed LSAs get flooded over demand circuits. When a router receives a new LSA instance, it checks first whether the contents actually changed 🔍. If they didn't, the new LSA is just a periodic refresh, so it does not get flooded out attached demand circuits (it still gets flooded out other interfaces, though 💁♀️). This check should be done in Step 5b of Section 13 in [1]. When comparing an LSA to its previous instance, all of these count as changes in contents:
- The LSA's
Optionsfield has changed. - One or both of the LSA instances has
LS ageset toMaxAge(orDoNotAge+MaxAge). - The
lengthfield in the LSA header has changed. - The contents of the LSA, excluding the 20-byte link state header, have changed. Note that this excludes changes in
LS Sequence NumberandLS Checksum🙅♀️.
- The LSA's
- When it's been decided to flood an LSA over a demand circuit,
DoNotAgeshould be set in the copy of the LSA that gets flooded out the demand interface. (There's one exception:DoNotAgeshould not be set if the LSA'sLS ageis equal toMaxAge.) SettingDoNotAgemakes the routers on the other side of the demand circuit hold the LSA in their databases indefinitely, so there's no need for periodic refresh ♻️. It's totally possible thatDoNotAgeis already set. That just means the LSA has already been flooded over demand circuits before 🤷♀️. Either way, the flooded copy'sLS agefield also has to be incremented byInfTransDelay(see Step 5 of Section 13.3 in [1], and Section 2.2 of this memo), as protection against flooding loops 🔒.
The paragraph above also applies to LSAs flooded over demand circuits in response to Link State Requests 📬. It also applies to LSAs that get retransmitted over demand circuits 🔁.
3.4. Virtual link support 🌸
OSPF virtual links are basically unnumbered point-to-point links (see Section 15 of [1]) 🧸. So demand circuit support for virtual links looks a lot like what we described for point-to-point links in the previous sections. The big 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, if a virtual link's underlying physical path has one or more demand circuits in it, the periodic OSPF protocol exchanges over the virtual link would keep the underlying demand circuits open for no reason 😩.
Here's the summary of demand circuit support on virtual links:
- Instead of modifying the Interface state machine for virtual links the way we did for point-to-point links in Section 3.1, the Interface state machine for virtual links stays unchanged. A virtual link is considered to be in state
Point-to-pointif an intra-area path (through the virtual link's transit area) exists to the other endpoint. Otherwise, it's considered to be in stateDown. See Section 15 of [1] for more details 🗺️. - Virtual links are always treated as demand circuits. Specifically, over virtual links a router always negotiates to suppress the sending of Hellos. See Sections 3.2.1 and 3.2.2 for details 🤝.
- In demand circuit support over virtual links, there's no "discouraging diagnostic code" like the one 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 💫.
- Since virtual links are always treated as demand circuits, flooding over virtual links always goes through the process in Section 3.3 🌊.
3.5. Point-to-MultiPoint Interface support 🕸️
The OSPF Point-to-MultiPoint interface was recently developed for use with non-mesh-connected network segments 🌐. A common example is a Frame Relay subnet where PVCs are set up between some pairs of routers, but not all of them. In that case, the Point-to-MultiPoint interface represents the single physical interface to the Frame Relay network, and multiple point-to-point OSPF conversations (one on each PVC) are happening over it 📡. For more information on the Point-to-MultiPoint interface, see [8] 📚.
Since an OSPF Point-to-MultiPoint interface is basically made up of multiple point-to-point links, demand circuit support on the Point-to-MultiPoint interface is super similar to demand circuit support for point-to-point links 👯♀️. But since the Point-to-MultiPoint interface requires its component point-to-point links to share the same configuration, there are a few differences 🤓.
Here's the summary of demand circuit support on Point-to-MultiPoint interfaces:
- Instead of modifying the Interface state machine for Point-to-MultiPoint interfaces the way we did for point-to-point links in Section 3.1, the Interface state machine for Point-to-MultiPoint interfaces stays unchanged 🙌.
- When
ospfIfDemandis set on a Point-to-MultiPoint interface, the router tries to negotiate Hello suppression separately on each of the interface's component point-to-point links. This negotiation goes exactly like Section 3.2.1 says. Negotiation might fail on some component point-to-point links and succeed on others, and that's totally fine 😌. On the component links where negotiation fails, Hellos will always be sent. Otherwise, Hellos will stop being sent when the Database Description process completes on the component link (see Section 3.2.2) 🛑. - Section 3.3 defines the demand circuit flooding behavior for all OSPF interface types, and that includes Point-to-MultiPoint interfaces 🌊.
4. Examples ✨
This section gives three examples of how things operate over demand circuits 🎬. The first example is probably the most common and definitely the most basic: it shows a single point-to-point demand circuit connecting two routers 👭. The second shows 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 can't keep them all open at the same time (for resource reasons) 🥺.
4.1. Example 1: Sole connectivity through demand circuits 🌟
okay so bestie, picture this 🦋 Figure 1 is a sample internetwork with a single demand circuit giving connectivity to the LAN where Host H2 lives 🏠 Assume all three routers (RTA, RTB and RTC) have the functionality from Section 2 of this memo, so they'll be setting the DC-bit in their LSAs 💅 Also assume Router RTB has been configured to treat the link to Router RTC as a demand circuit, but Router RTC has not been so configured 👀 Last thing: the LAN interface connecting Router RTA to Host H1 starts out down 💀
so here's the sequence of events that might go down ✨, starting with Router RTB booting up and bringing its link to Router RTC online:
Time T0: RTB negotiates Hello suppression
Router RTB starts sending Hellos over the demand circuit with the DC-bit set in the Hello's Options field 🫶 Since RTC isn't configured to treat the link as a demand circuit, the first Hello RTB gets from RTC may not have the DC-bit set 🙈 But the subsequent Hellos and Database Description Packets from RTC will have the DC-bit set, which means the two routers agreed to treat the link as a demand circuit 🎀 The whole negotiation is pictured in Figure 2 ✨ Note: if RTC couldn't or wouldn't suppress Hellos on the link, the initial Database Description sent from Router RTC to RTB would have the DC-bit clear, forcing RTB to go back to the periodic sending of Hellos specified in Section 9.5 of [1] 😭
+ + +
| +---+ | |
+--+ |---|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.
+---+ +---+
|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.
Time T1: Database exchange over demand circuit
The initial synchronization of link state databases (the Database Exchange Process) over the demand circuit happens just like over any point-to-point link, with one exception ✨ LSAs included in Link State Updates Packets 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 will vary depending on which side of the demand circuit the LSAs 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, which 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 10Table 1: After Time T1 in Section 4.1, possible LS age fields on either side of the demand circuit
Time T2: Hello traffic ceases
Once the Database Exchange Process has completed, no Hellos get sent over the demand circuit 🤐 If there's no application data to send, the circuit just sits idle 😴
Time T3: Underlying data-link connection torn down
After some period of inactivity, the underlying data-link connection gets torn down (e.g., an ISDN call would be cleared) to save connect charges 💸 This is totally transparent to OSPF routing, so no LSAs or routing table entries change as a result 🫠
Time T4: Router RTA's LSA is refreshed
At some point Router RTA refreshes its own router-LSA (i.e., when the LSA's LS age hits LSRefreshInterval) 🔄 This refresh gets flooded to Router RTB, who looks at it and decides NOT to flood it over the demand circuit to Router RTC, because the LSA's contents haven't really changed (only the LS Sequence Number) 🙅♀️ At this point, the LS sequence numbers the routers have for RTA's router-LSA differ depending on which side of the demand circuit they lie on 🤔 Because there's still no application traffic, the underlying data-link connection stays 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 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 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 🏎️
Here's what may 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 ✨
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.Time T1: Underlying data-link connection is torn down. 💀
Okay so at Time T1, the data-link connection underlying the demand circuit gets torn down. Traffic is all flowing over the leased line between RTB and RTD now, instead of the demand circuit, because the leased line has the lesser OSPF cost 💅. After some period of inactivity, the data-link connection under the demand circuit gets torn down. The best part? This does not affect the OSPF database or the routers' routing tables. Not me being impressed ✨
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. The new LSA will not have the DoNotAge bit set, and it 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. Table 3 is the whole vibe 📸🦋
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). Main character energy 👑
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. So 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. 🫠
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. Bestie, that gap is so brief but it still hurts 💔
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. As the router-LSA is flooded throughout the internetwork, it flushes all LSAs having the DoNotAge bit set, and it 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). The plot thickens 🍓
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. Stay tuned for that one 👀
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. Okay, that's a lot of pipes 🌈
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,
+ +--+
+---+ |--|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). So RT4 gets left on read for now 📵
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. Honestly, same 🙈
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. It's giving unreachable vibes, periodt 💀
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. Literally the best way to keep your circuits chill 🧘♀️
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. So the regular areas have to all get on the same page first 🫶
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: ngl, it's a trade-off 💜
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. Trust fall energy 😬
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. The checksum said no 💅🔥
7. Future work: Oversubscription ✨
okay so an internetwork is oversubscribed when not all of its demand circuits' underlying connections can be open at once, bc resources are limited 🥺 We already covered these in Section 4.3. BUT when every possible source in the internetwork is active at the same time, things can get messy in ways this memo doesn't address 😭 There are three big questions:
(1) First up, is there 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. 🧠
(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. this is the part that gets me every time 🙈
+--+ + + +--+
|H1|--| +---+ ODL +---+ |--|H2|
+--+ |--|RT1|-------|RT2|--| +--+
| +---+ +---+ |
+ | \ / | +
| \ / |
| \ / |
|ODL / |ODL
| / \ODL |
| / \ |
+ | /ODL \ | +
+--+ | +---+ +---+ | +--+
|H4|--|--|RT4|-------|RT3|--|--|H3|
+--+ | +---+ ODL +---+ | +--+
+ +
Figure 5: Example of an oversubscribed
internetwork +---+ +---+ +---+ +---+
|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 connectionsOne 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]. routing drama, not the fun kind 🌀
8. Unsupported capabilities 💅
The following possible capabilities associated with demand circuit routing have explicitly not been supported by this memo:
- okay so when the topology of an OSPF area changes, those changes get flooded over the area's demand circuits, even if that means (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. 🙃
- 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 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. so much potential, so much config chaos 🌸
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 fieldT-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].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. the DC-bit is the star of the show ⭐
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 toTRUE, 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. the circuit can nap when it's not busy 💤
C. Architectural Constants ✨
This memo defines a single additional OSPF architectural constant.
DoNotAge: Equal to the hexadecimal value0x8000, 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. DoNotAge is iconic, no notes 👑
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. Big dramatic pause here: the memo doesn't cover security at all. 💀
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📦 where this page comes from
- ietf: rfc1793 1995-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms