As per Relevance of the word circuits, we have this rfc below:
Network Working Group J.
Request for Comments: 1793
Category: Standards Track April 1995
Extending OSPF to Support Demand
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This memo defines enhancements to the OSPF protocol that
efficient operation over "demand circuits". Demand circuits
network segments whose costs vary with usage; charges can be
both on connect time and on bytes/packets transmitted. Examples
demand circuits include ISDN circuits, X.25 SVCs, and dial-up lines
The periodic nature of OSPF routing traffic has until now required
demand circuit's underlying data-link connection to be
open, resulting in unwanted usage charges. With the
described herein, OSPF Hellos and the refresh of OSPF
information are suppressed on demand circuits, allowing
underlying data-link connections to be closed when not
application traffic
Demand circuits and regular network segments (e.g., leased lines)
allowed to be combined in any manner. In other words, there are
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
and NBMA networks are declared demand circuits, routing
traffic is reduced but the periodic sending of Hellos is not,
in effect still requires that the data-link connections
constantly open
While mainly intended for use with cost-conscious network links
as ISDN, X.25 and dial-up, the modifications in this memo may
prove useful over bandwidth-limited network links such as slow-
leased lines and packet radio
The enhancements defined in this memo are backward-compatible
the OSPF specification defined in [1], and with the OSPF
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
[2], with the main difference being the way the two proposals
oversubscription (see Sections 4.3 and 7 below). However,
OSPF employs link-state routing technology as opposed to RIP'
Distance Vector base, the mechanisms used to achieve the
circuit functionality are quite different
Please send comments to ospf@gated.cornell.edu
The author would like to acknowledge the helpful comments of
Baker, Rob Coltun, Dawn Li, Gerry Meyer, Tom Pusateri and
Zhang. This memo is a product of the OSPF Working Group
Table of
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
In this memo, demand circuits refer to those network segments
cost depends on either connect time and/or usage (expressed in
of bytes or packets). Examples include ISDN circuits and X.25 SVCs
On these circuits, it is desirable for a routing protocol to send
little routing traffic as possible. In fact, when there is no
in network topology it is desirable for a routing protocol to send
routing traffic at all; this allows the underlying data-
connection to be closed when not needed for application data traffic
The model used within this memo for the maintenance of
circuits is as follows. If there is no data to send (either
protocol traffic or application data), the data-link
remains closed. As soon as there is data to be sent, an attempt
open the data-link connection is made (e.g., an ISDN or X.25 call
placed). When/if the data-link connection is established, the data
sent, and the connection stays open until some period of time
without more data to send. At this point the data-link connection
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
particular time, it is assumed by the routing layer (i.e., OSPF)
the circuit is available unless other information, such as
discouraging diagnostic code resulting from an attempted data-
connection, is present
It may be possible that a data-link connection cannot be
due to resource shortages. For example, a router with a single
rate ISDN interface cannot open more than two simultaneous
data-link connections (one for each B channel), and limitations
interface firmware and/or switch capacity may limit the number
X.25 SVCs simultaneously supported. When a router
simultaneously open all of its circuits' underlying data-
connections due to resource limitations, we say that the router
oversubscribed. In these cases, datagrams to be forwarded out
(temporarily unopenable) data-link connections are discarded,
of being queued. Note also that this temporary inability to
data-link connections due to oversubscription is NOT reported by
OSPF routing system as unreachability; see Section 4.3 for
information
Moy [Page 3]
RFC 1793 OSPF over Demand Circuits April 1995
Either end of a demand circuit may attempt to open the data-
connection. When both ends attempt to open the
simultaneously, there is the possibility of call collision. Not
data-links specify how call collisions are handled. Also, while
requires that all periodic timers be randomized to
synchronization (see Section 4.4 of [1]), if call attempts
strictly data-driven there may still be insufficient spacing of
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
backoff scheme for call retries be employed at the data-link layer
Besides helping with call collisions, such a scheme could
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-
connection. For example, some async modems can initiate calls,
cannot accept incoming calls. In these cases, since
initiation in this memo is data-driven, care must be taken to
that the initiating application party is located at the calling
of the demand circuit
2. Modifications to all OSPF
While most of the modifications to support demand circuits
isolated to the demand circuit endpoints (see Section 3), there
changes required of all OSPF routers. These changes are described
the subsections below
2.1. The OSPF Options
A new bit is added to the OSPF Options field to support the
circuit extensions. This bit is called the "DC-bit". The
format of the Options field is described in Appendix A
A router implementing the functionality described in Section 2
this memo sets the DC-bit in the Options field of all LSAs that
originates. This is regardless of the LSAs' LS type, and
regardless of whether the router implements the more
modifications required of demand circuit endpoints (see
3). Setting the DC-bit in self-originated LSAs tells the rest
the routing domain that the router can correctly process
LSAs (see Sections 2.2, 2.3 and 2.5).
There is a single exception to the above rule. A
implementing Section 2 of this memo may sometimes originate
"indication-LSA"; these LSAs always have the DC-bit clear
Indication-LSAs are used to convey across area boundaries
Moy [Page 4]
RFC 1793 OSPF over Demand Circuits April 1995
existence of routers incapable of DoNotAge processing; see
2.5.1 for details
2.2. The LS age
The semantics of the LSA's LS age field are changed, allowing
high bit of the LS age field to be set. This bit is
"DoNotAge"; see Appendix C for its formal definition. LSAs
LS age field have the DoNotAge bit set are not aged while they
held in the link state database, which means that they do not
to be refreshed every LSRefreshInterval as is done with all
OSPF LSAs
By convention, in the rest of this memo we will express LS
fields having the DoNotAge bit set as "DoNotAge+x", while an
age expressed as just "x" is assumed to not have the DoNotAge
set. LSAs having DoNotAge set are also sometimes referred to
"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
numbers and LS checksums are found identical (see Section 13.1
[1]). Before comparing, the LS age fields must have their
bits masked off. For example, in determining which LSA is
recent, LS ages of 1 and DoNotAge+1 are considered equivalent;
LSA flooded with LS age of 1 may be acknowledged with a Link
Acknowledgement listing an LS age of DoNotAge+1, or vice versa.
particular, DoNotAge+MaxAge is equivalent to MaxAge; however
backward-compatibility the MaxAge form should always be used
flushing LSAs from the routing domain (see Section 14.1 of [1]).
Thus, the set of allowable values for the LS age field fall
the two ranges: 0 through MaxAge and DoNotAge
DoNotAge+MaxAge. (Previously the LS age field could not
the value of MaxAge.) Any LS age field not falling into these
ranges should be considered to be equal to MaxAge
When an LSA is flooded out an interface, the
InfTransDelay is added to the LSA's LS age field. This
even if the DoNotAge bit is set; in this case the LS age field
not allowed to exceed DoNotAge+MaxAge. If the LS age field
DoNotAge+MaxAge during flooding, the LSA is flushed from
routing domain. This preserves the protection in [1]
against flooding loops
The LS age field is not checksum protected. Errors in a router'
memory may mistakenly set an LSA's DoNotAge bit, stopping
aging of the LSA. However, a router should note that its
Moy [Page 5]
RFC 1793 OSPF over Demand Circuits April 1995
self-originated LSAs should never have the DoNotAge bit set in
own database. This means that in any case the router's self
originated LSAs will be refreshed every LSRefreshInterval.
this refresh is flooded throughout the OSPF routing domain,
will replace any LSA copies in other routers' databases
DoNotAge bits were mistakenly set
2.3. Removing stale DoNotAge
Because LSAs with the DoNotAge bit set are never aged, they
stay in the link state database even when the originator of
LSA no longer exists. To ensure that these LSAs are
flushed from the routing domain, and that the size of the
state database doesn't grow without bound, routers are required
flush a DoNotAge LSA if BOTH of the following conditions are met
(1) The LSA has been in the router's database for at
MaxAge seconds
(2) The originator of the LSA has been unreachable (according
the routing calculations specified by Section 16 of [1])
at least MaxAge seconds
For an example, see Time T8 in the example of Section 4.1.
that the above functionality is an exception to the general
rule that a router can only flush (i.e., prematurely age;
Section 14.1 of [1]) its own self-originated LSAs. The
functionality pertains only to DoNotAge LSAs. An LSA
DoNotAge clear still can be prematurely aged only by
originator; otherwise, the LSA must age naturally to MaxAge
being removed from the routing domain
An interval as long as MaxAge has been chosen to avoid
possibility of thrashing (i.e., flushing an LSA only to have
reoriginated soon afterwards). Note that by the above rules,
DoNotAge LSA will be removed from the routing domain no
than if it were being aged naturally (i.e., if DoNotAge were
set).
2.4. A change to the flooding
The following change is made to the OSPF flooding algorithm.
a Link State Update Packet is received that contains an
instance which is actually less recent than the the router'
current database copy, the router must now process the LSA
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
sequence number equal to MaxSequenceNumber, simply
the received LSA without acknowledging it. (In this case
the LSA's sequence number is wrapping, and
MaxSequenceNumber LSA must be completely flushed before
new LSAs can be introduced). This is identical to
behavior specified by Step 8 of Section 13 in [1].
o Otherwise, send the database copy back to the
neighbor, encapsulated within a Link State Update Packet.
so doing, do not put the database copy of the LSA on
neighbor's link state retransmission list, and do
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-
interfaces as well. For this reason, the flooding change
to all interfaces, not just interfaces to demand circuits.
main example involves MaxAge LSAs. There are times when
LSAs stay in a router's database for extended intervals: 1)
they are stuck in a retransmission queue on a slow link or 2)
a router is not properly flushing them from its database, due
software bugs. The prolonged existence of these MaxAge LSAs
inhibit the flooding of new instances of the LSA. New
typically start with the initial LS sequence number, and
treated as less recent (and hence discarded) by routers
holding MaxAge instances. However, with the above change
flooding, a router with a MaxAge instance will respond back
the MaxAge instance. This will get back to the LSA's originator
which will then pick the next highest LS sequence number
reflood, overwriting the MaxAge instance
This change will be included in future revisions of the base
specification [1].
2.5. Interoperability with unmodified OSPF
Unmodified OSPF routers will probably treat DoNotAge LSAs as
they had LS age of MaxAge. At the very worst, this will
continual retransmissions of the DoNotAge LSAs. (An
scenario follows. Suppose Routers A and B are connected by
point-to-point link. Router A implements the demand
extensions, Router B does not. Neither one treats their
link as a demand circuit. At some point in time, Router A
from another neighbor via flooding a DoNotAge LSA. The
LSA is then flooded by Router A to Router B. Router B,
Moy [Page 7]
RFC 1793 OSPF over Demand Circuits April 1995
understanding DoNotAge LSAs, treats it as a MaxAge LSA
acknowledges it as such to Router A. Router A receives
acknowledgment, but notices that the acknowledgment is for
different instance, and so starts retransmitting the LSA.)
However, to avoid this confusion, DoNotAge LSAs will be allowed
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
2.1). Note that it is not required that the LSAs'
Router be reachable; if any LSA is found not having its DC-bit
(regardless of reachability), then the router should flush (i.e.,
prematurely age; see Section 14.1 of [1]) from the area
DoNotAge LSAs. These LSAs will then be reoriginated at
sources, this time with DoNotAge clear. Like the change
Section 2.3, this change is an exception to the general OSPF
that a router can only flush its own self-originated LSAs.
changes pertain only to DoNotAge LSAs, and in both cases a
LSA's LS age field should be set to MaxAge and
DoNotAge+MaxAge
2.5.1. Indicating across area
AS-external-LSAs are flooded throughout the entire OSPF
domain, excepting only OSPF stub areas and NSSAs. For
reason, if an OSPF router that is incapable of
processing exists in any "regular" area (i.e., an area that
not a stub nor an NSSA), no AS-external-LSA can have
set. This memo simplifies that requirement by broadening it
the following rule: LSAs in regular OSPF areas are allowed
have DoNotAge set if and only if every router in the
domain (excepting those in stub areas and NSSAs) is capable
DoNotAge processing. The rest of this section describes how
rule is implemented
As described above in Sections 2.1 and 2.5, a router
that it is capable of DoNotAge processing by setting the DC-
in the LSAs that it originates. However, there is a problem.
is possible that, in all areas to which Router X
attaches, all the routers are capable of DoNotAge processing
yet there is some router in a remote "regular" area that
process DoNotAge LSAs. This information must then be
to Router X, so that it does not mistakenly flood/
DoNotAge LSAs
The solution is as follows. Area border routers transmit
existence of DoNotAge-incapable routers across area boundaries
using "indication-LSAs". Indication-LSAs are type-4-
LSAs (also called ASBR-summary-LSAs), listing the area
Moy [Page 8]
RFC 1793 OSPF over Demand Circuits April 1995
router itself as the described ASBR, with the LSA's cost set
LSInfinity and the DC-bit clear. Note that indication-
convey no additional information; in particular, they are
even if the area border router is not really an AS
router (ASBR).
Taking indication-LSAs into account, the rule as to
DoNotAge LSAs are allowed in any particular area is EXACTLY
same as given previously in Section 2.5, namely: DoNotAge
will be allowed in an OSPF area if and only if, in the area'
link state database, all LSAs have the DC-bit set in
Options field
Through origination of indication-LSAs, the existence
DoNotAge-incapable routers can be viewed as going from non
backbone regular areas, to the backbone area and from there
all other regular areas. The following two cases summarize
requirements for an area border router to
indication-LSAs
(1) Suppose an area border router (Router X) is connected
a regular non-backbone OSPF area (Area A). Furthermore
assume that Area A has LSAs with the DC-bit clear,
than indication-LSAs. Then Router X should
indication-LSAs into all other directly-
"regular" areas, including the backbone area,
the guidelines of Section 2.5.1.1 in mind
(2) Suppose an area border router (Router X) is connected
the backbone OSPF area (Area 0.0.0.0). Furthermore
assume that the backbone has LSAs with the DC-bit
that are either a) not indication-LSAs or b
indication-LSAs that have been originated by
other than Router X itself. Then Router X
originate indication-LSAs into all other directly
connected "regular" non-backbone areas, keeping
guidelines of Section 2.5.1.1 in mind
2.5.1.1. Limiting indication-LSA
To limit the number of indication-LSAs originated,
following guidelines should be observed by an area
router (Router X) when originating indication-LSAs. First
indication-LSAs are not originated into an Area A when
already has LSAs with DC-bit clear other than indication
LSAs. Second, if another area border router has originated
indication-LSA into Area A, and that area border router
a higher OSPF Router ID than Router X (same tie-breaker
Moy [Page 9]
RFC 1793 OSPF over Demand Circuits April 1995
for forwarding address origination; see Section 12.4.5
[1]), then Router X should not originate an indication-
into Area A
As an example, suppose that three regular OSPF areas (
A, B and C) are connected by routers X, Y and
(respectively) to the backbone area. Furthermore,
that all routers are capable of DoNotAge processing,
for routers in Areas A and B. Finally, suppose that
Z has a higher Router ID than Y, which in turn has a
Router ID than X. In this case, two indication-LSAs will
generated (if the rules of Section 2.5.1 and the
of the preceding paragraph are followed): Router Y
originate an indication-LSA into the backbone, and Router
will originate an indication-LSA into Area C
3. Modifications to demand circuit
The following subsections detail the modifications required of
routers at the endpoints of demand circuits. These consist
modifications to two main pieces of OSPF: 1) sending and
Hello Packets over demand circuits and 2) flooding LSAs over
circuits
An additional OSPF interface configuration parameter, ospfIfDemand
is defined to indicate whether an OSPF interface connects to a
circuit (see Appendix B). Two routers connecting to a common
segment need not agree on that segment's demand circuit status
However, to get full benefit of the demand circuit extensions,
two ends of a point-to-point link must both agree to treat the
as a demand circuit (see Section 3.2).
3.1. Interface State machine
An OSPF point-to-point interface connecting to a demand circuit
considered to be in state "Point-to-point" if and only if
associated neighbor is in state "1-Way" or greater; otherwise
interface is considered to be in state "Down". Hellos are sent
such an interface when it is in "Down" state, at the
interval of PollInterval. If the negotiation in Section 3.2.1
succeeds, Hellos will cease to be sent out the interface
the associated neighbor reaches state "Full".
Note that as a result, an "LLDown" event for the point-to-
demand circuit's neighbor forces both the neighbor and
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
demand circuits, there are no changes to the Interface
Machine
3.2. Sending and Receiving OSPF
The following sections describe the required modifications to
Hello Packet processing on point-to-point demand circuits
For OSPF broadcast and NBMA networks that have been configured
demand circuits, there is no change to the sending and
of Hellos, nor are there any changes to the Neighbor
Machine. This is because the proper operation of the
Router election algorithm requires periodic exchange of
Packets
3.2.1. Negotiating Hello
On point-to-point demand circuits, both endpoints must agree
suppress the sending of Hello Packets. To ensure
agreement, a router sets the DC-bit in OSPF Hellos and
Description Packets sent out the demand interface.
an Hello or a Database Description Packet with the DC-bit
indicates agreement. Receiving an Hello with the DC-bit
and also listing the router's Router ID in the body of
Hello message, or a Database Description Packet with the DC-
clear (either one indicating bidirectional connectivity
indicates that the other end refuses to suppress Hellos.
these latter cases, the router reverts to the normal
sending of Hello Packets out the interface (see Section 9.5
[1]).
A demand point-to-point circuit need be configured in only
of the two endpoints (see Section 4.1). If a
implementing Sections 2 and 3 of this memo receives an
Packet with the DC-bit set, it should treat the point-to-
link as a demand circuit, making the appropriate changes to
Hello Processing (see Section 3.2.2) and flooding (see
3.3).
Even if the above negotiation fails, the router should
setting the DC-bit in its Hellos and Database Descriptions (
neighbor will just ignore the bit). The router will
automatically attempt to renegotiate Hello suppression
the link goes down and comes back up. For example, if
neighboring router is rebooted with software that is capable
operating over demand circuits (i.e., implements Sections 2
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,
flooding modifications described in Section 3.3 are
performed over the link
3.2.2. Neighbor state machine
When the above negotiation succeeds, Hello Packets are
over point-to-point demand circuits only until initial link
state database synchronization is achieved with the
(i.e., the state of the neighbor connection reaches "Full",
defined in Section 10.1 of [1]). After this, Hellos
suppressed and the data-link connection to the neighbor
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
contained in a response to a failed call request, the
connection transitions back to "Down" and Hellos are
periodically (at Intervals of PollInterval) in an attempt
restart synchronization with the neighbor
This requires changes to the OSPF Neighbor State Machine (
Section 10.3 of [1]). The receipt of Hellos from demand
neighbors in state "Loading" or "Full" can no longer
required. In other words, the InactivityTimer event defined
Section 10.2 of [1] has no effect on demand circuit
in state "Loading" or "Full". An additional clarification
needed in the Neighbor State Machine's LLDown event. For
circuits, this event should be mapped into the "
diagnostic code" discussed previously in Section 1, and
not be generated when the data-link connection has been
simply to save resources. Nor should LLDown be generated if
data-link connection fails due to temporary lack of resources
3.3. Flooding over demand
Flooding over demand circuits (point-to-point or otherwise)
modified if and only if all routers have indicated that they
process LSAs having DoNotAge set. This is determined by
the link state database of the OSPF area containing the
circuit. All LSAs in the database must have the DC-bit set.
one or more LSAs have the DC-bit clear, flooding over
circuits is unchanged from [1]. Otherwise, flooding is changed
follows
(1) Only truly changed LSAs are flooded over demand circuits
When a router receives a new LSA instance, it checks
to see whether the contents have changed. If not, the
LSA is simply a periodic refresh and it is not flooded
Moy [Page 12]
RFC 1793 OSPF over Demand Circuits April 1995
attached demand circuits (it is still flooded out
interfaces however). This check should be performed in
5b of Section 13 in [1]. When comparing an LSA to
previous instance, the following are all considered to
changes in contents
o The LSA's Options field has changed
o One or both of the LSA instances has LS age set
MaxAge (or DoNotAge+MaxAge).
o The length field in the LSA header has changed
o The contents of the LSA, excluding the 20-byte
state header, have changed. Note that this
changes in LS Sequence Number and LS Checksum
(2) When it has been decided to flood an LSA over a
circuit, DoNotAge should be set in the copy of the LSA
is flooded out the demand interface. (There is
exception: DoNotAge should not be set if the LSA's LS age
equal to MaxAge.) Setting DoNotAge will cause the routers
the other side of the demand circuit to hold the LSA
their databases indefinitely, removing the need for
refresh. Note that it is perfectly possible that
will already be set. This simply indicates that the LSA
already been flooded over demand circuits. In any case,
flooded copy's LS age field must also be incremented
InfTransDelay (see Step 5 of Section 13.3 in [1],
Section 2.2 of this memo), as protection against
loops
The previous paragraph also pertains to LSAs flooded
demand circuits in response to Link State Requests. It
pertains to LSAs that are retransmitted over
circuits
3.4. Virtual link
OSPF virtual links are essentially unnumbered point-to-point
(see Section 15 of [1]). Accordingly, demand circuit support
virtual links resembles that described for point-to-point links
the previous sections. The main difference is that a
implementing Sections 2 and 3 of this memo, and supporting
links, always treats virtual links as if they were
circuits. Otherwise, when a virtual link's underlying
path contains one or more demand circuits, periodic OSPF
exchanges over the virtual link would unnecessarily keep
Moy [Page 13]
RFC 1793 OSPF over Demand Circuits April 1995
underlying demand circuits open
Demand circuit support on virtual links can be summarized
follows
o Instead of modifying the Interface state machine for
links as was done for point-to-point links in Section 3.1,
the Interface state machine for virtual links
unchanged. A virtual link is considered to be in
"Point-to-point" if an intra-area path (through the
link's transit area) exists to the other endpoint.
it is considered to be in state "Down". See Section 15
[1] for more details
o Virtual links are always treated as demand circuits.
particular, over virtual links a router always negotiates
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
no "discouraging diagnostic code" as described in Section 1.
Instead, the connection is considered to exist if and
if an intra-area path (through the virtual link's
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
3.3.
3.5. Point-to-MultiPoint Interface
The OSPF Point-to-MultiPoint interface has recently been
for use with non-mesh-connected network segments. A common
is a Frame Relay subnet where PVCs are provisioned between
pairs of routers, but not all pairs. In this case the Point-to
Multipoint interface represents the single physical interface
the Frame relay network, over which multiple point-to-point
conversations (one on each PVC) are taking place. For
information on the Point-to-MultiPoint interface, see [8].
Since an OSPF Point-to-MultiPoint interface essentially
of multiple point-to-point links, demand circuit support on
Point-to-Multipoint interface strongly resembles demand
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
summarized as follows
o Instead of modifying the Interface state machine for Point
to-Multipoint interfaces as was done for point-to-
links in Section 3.1, the Interface state machine
Point-to-Multipoint interfaces remains unchanged
o When ospfIfDemand is set on a Point-to-MultiPoint interface
the router tries to negotiate Hello suppression
on each of interface's component point-to-point links.
negotiation proceeds as in Section 3.2.1. Negotiation
fail on some component point-to-point links, and succeed
others. This is acceptable. On those component links
the negotiation fails, Hellos will always be sent
otherwise, Hellos will cease to be sent when the
Description process completes on the component link (
Section 3.2.2).
o Section 3.3 defines the demand circuit flooding behavior
all OSPF interface types. This includes Point-to-
interfaces
4.
This section gives three examples of the operation over
circuits. The first example is probably the most common and
the most basic. It shows a single point-to-point demand
connecting two routers. The second illustrates what happens
demand circuits and leased lines are used in parallel. The
explains what happens when a router has multiple demand circuits
cannot keep them all open (for resource reasons) at the same time
4.1. Example 1: Sole connectivity through demand
Figure 1 shows a sample internetwork with a single demand
providing connectivity to the LAN containing Host H2. Assume
all three routers (RTA, RTB and RTC) have implemented
functionality in Section 2 of this memo, and thus will be
the DC-bit in their LSAs. Furthermore assume that Router RTB
been configured to treat the link to Router RTC as a
circuit, but Router RTC has not been so configured. Finally
that the LAN interface connecting Router RTA to Host H1
initially down
The following sequence of events may then transpire, starting
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
Router RTB will start sending Hellos over the demand
with the DC-bit set in the Hello's Options field.
RTC is not configured to treat the link as a demand circuit
the first Hello that RTB receives from RTC may not have
DC-bit set. However, subsequent Hellos and
Description Packets received from RTC will have the DC-
set, indicating that the two routers have agreed that
link will be treated as a demand circuit. The
negotiation is pictured in Figure 2. Note that if RTC
unable or unwilling to suppress Hellos on the link,
initial Database Description sent from Router RTC to
would have the DC-bit clear, forcing Router RTB to revert
the periodic sending of Hellos specified in Section 9.5
[1].
Time T1: Database exchange over demand
The initial synchronization of link state databases (
Database Exchange Process) over the demand circuit
occurs as over any point-to-point link, with one exception
LSAs included in Link State Updates Packets sent over
+ + +
| +---+ | |
+--+ |---|RTA|---| | +--+
|H1|---| +---+ | |---|H2|
+--+ | | +---+ ODL +---+ | +--+
|LAN Y |---|RTB|-------------|RTC|---|
+ | +---+ +---+ |
+ +
Figure 1: In the example of Section 4.1,
a single demand circuit (
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
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
will have 3 LSAs in their link state databases (router-
for Routers RTA, RTB and RTC), but the LS age
belonging to the LSAs will vary depending on which side
the demand circuit they were originated from (see Table 1).
For example, all routers other than Router RTC have
DoNotAge bit set in Router RTC's router-LSA; this
the need for Router RTC to refresh its router-LSA over
demand circuit
LS
LSA in RTB in
______________________________________________
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
side of the demand
Time T2: Hello traffic
After the Database Exchange Process has completed, no
are sent over the demand circuit. If there is no
data to be sent over the demand circuit, the circuit will
idle
Moy [Page 17]
RFC 1793 OSPF over Demand Circuits April 1995
Time T3: Underlying data-link connection torn
After some period of inactivity, the underlying data-
connection will be torn down (e.g., an ISDN call would
cleared) in order to save connect charges. This will
transparent to the OSPF routing; no LSAs or routing
entries will change as a result
Time T4: Router RTA's LSA is
At some point Router RTA will refresh its own router-
(i.e., when the LSA's LS age hits LSRefreshInterval).
refresh will be flooded to Router RTB, who will look at
and decide NOT to flood it over the demand circuit to
RTC, because the LSA's contents have not really
(only the LS Sequence Number). At this point, the
sequence numbers that the routers have for RTA's router-
differ depending on which side of the demand circuit
routers lie. Because there is still no application traffic
the underlying data-link connection remains disconnected
Time T5: Router RTA's LAN interface comes
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
contents have now changed. The underlying data-
connection will have to be brought up to flood the LSA
After flooding, routers on both sides of the demand
will again agree on the LS Sequence Number for RTA'
router-LSA
Time T6: Underlying data-link connection is torn down
Assuming that there is still no application
transiting the demand circuit, the underlying data-
connection will again be torn down after some period
inactivity
Time T7: File transfer started between Hosts H1 and H
As soon as application data needs to be sent across
demand circuit the underlying data-link connection
brought back up
Moy [Page 18]
RFC 1793 OSPF over Demand Circuits April 1995
Time T8: Physical link becomes
If an indication is received from the data-link or
layers indicating that the demand circuit can no longer
established, Routers RTB and RTC declare their point-to
point interfaces down, and originate new router-LSAs.
routers will attempt to bring the connection back up
sending Hellos at the reduced rate of PollInterval.
that while the connection is inoperative, Routers RTA
RTB will continue to have an old router-LSA for RTC in
link state database, and this LSA will not age out
it has the DoNotAge bit set. However, according to
2.3 they will flush Router RTC's router-LSA if the
circuit remains inoperative for longer than MaxAge
4.2. Example 2: Demand and non-demand circuits in
This example demonstrates the demand circuit functionality
both demand circuits and non-demand circuits (e.g., leased lines
are used to interconnect regions of an internetwork. Such
internetwork is shown in Figure 3. Host H1 can communicate
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
were presented in the previous example, this example will
address the unique issues involved when using both demand
non-demand circuits in parallel
Assume that Routers RTB and RTY are initially powered off,
that all other routers and their attached links are
operational and implement the demand circuit modifications
OSPF. Throughout the example, a TCP connection between Hosts H
and H2 is transmitting data. Furthermore, assume that the cost
the demand circuit from RTB to RTC has been set
higher than the cost of the leased line between RTB and RTD;
this reason traffic between Hosts H1 and H2 will always be
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
are pictured, Routers RTA-RTE and RTY
RTB has three serial line interfaces, two
which are leased lines and the third (connecting
RTC) a demand circuit. Two hosts, H1
H2, are pictured to illustrate the effect
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
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
leased line to Router RTD will not. Because the DoNotAge
is not taken into account when comparing LSA instances,
routers on the right side of RTB (RTC, RTE and RTD) may
may not have the DoNotAge bit set in their database
of RTA's and RTB's router-LSAs. This depends on whether
LSAs sent over the demand link reach the routers
those sent over the leased line. One possibility is
in Table 2.
Moy [Page 20]
RFC 1793 OSPF over Demand Circuits April 1995
LS
LSA in RTC in RTD in
________________________________________________
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
fields on the right side of Router RTB
LS
LSA in RTC in RTD in
_______________________________________________
RTA's Router-LSA 5 6 6
RTB's Router-LSA DoNotAge+5 1785 1785
Table 3: After Time T2 in Example 2, LS
fields on the right side of Router RTB
LS
LSA in RTC in RTD in
_______________________________________________________
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
fields on the right side of Router RTB
LS
LSA in RTC in RTD in
_______________________________________________________
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
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
connecting Routers RTB and RTD instead of the
circuit, due to the leased line's lesser OSPF cost.
some period of inactivity, the data-link
underlying the demand circuit will be torn down. This
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
every LSRefreshInterval), Router RTB floods the
LSA over the leased line but not over the demand circuit
because the contents of the LSA have not changed. This
LSA will not have the DoNotAge bit set, and will replace
old instances (whether or not they have the DoNotAge
set) by virtue of its higher LS Sequence number. This
pictured in Table 3.
Time T3: Leased line becomes inoperational
When the leased line becomes inoperational, the data-
connection underlying the demand circuit will be reopened
in order to flood a new (and changed) router-LSA for RTB
also to carry the application traffic between Hosts H1
H2. After flooding the new LSA, all routers on the
side of the demand circuit will have DoNotAge set in
copy of RTB's router-LSA and DoNotAge clear in their copy
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
over the demand circuit. However, RTA's router-LSA is
in all of the routers to the right of the demand circuit
For this reason, the router-LSA will eventually be aged
and reflooded (by router RTE in our example). Because
aged out LSA constitutes a real change (see Section 3.3),
is flooded over the demand circuit from Router RTC to RTB
There are then two possible scenarios. First, the
Sequence number for RTA's router-LSA may be larger on RTB'
side of the demand link. In this case, when router
receives the flushed LSA it will respond by flooding
the more recent instance (see Section 2.4). If instead
LS sequence numbers are the same, the flushed LSA will
flooded all the way back to Router RTA, which will then
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
right side of the demand link will have the DoNotAge bit
in their copy of RTA's router-LSA (see Table 5). In
small interval between the flushing and waiting for a
instance of the LSA, there will be a temporary loss
connectivity between Hosts H1 and H2.
Time T5: A non-supporting router joins
Suppose Router RTY now becomes operational, and does
support the demand circuit OSPF extensions. Router RTY'
router-LSA then will not have the DC-bit set in its
field, and as the router-LSA is flooded throughout
internetwork it flushes all LSAs having the DoNotAge bit
and causes the flooding behavior over the demand circuit
revert back to the normal flooding behavior defined in [1].
However, although all LSAs will now be flooded over
demand circuit, regardless of whether their contents
really changed, Hellos will still continue to be
on the demand circuit (see Section 3.2.2).
4.3. Example 3: Operation when
The following example shows the behavior of the demand
extensions in the presence of oversubscribed interfaces. Note
the example's topology excludes the possibility of
paths. The combination of oversubscription and redundant
(i.e., alternative paths) poses special problems for the
circuit extensions. These problems are discussed later in
7.
Figure 4 shows a single Router (RT1) connected via demand
to three other routers (RT2-RT4). Assume that RT1 can only
two out of three underlying data-link connections open at once
This may be due to one of the following reasons: Router RT1 may
using a single Basic Rate ISDN interface (2 B channels) to
all three demand circuits, or, RT1 may be connected to a data-
switch (e.g., an X.25 or Frame relay switch) that is only
of so many simultaneous data-link connections
The following events may transpire, starting with Router RT
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
synchronize OSPF databases with routers RT2-RT4. But
+ +--+
+---+ |--|H2|
+---------|RT2|--| +--+
/ +---+ |
/ ODL +
+--+ + /
|H1|--| / +
+--+ | +---+ ODL +---+ | +--+
|--|RT1|------------|RT3|--|--|H3|
| +---+ +---+ | +--+
| \ +
+ \
\ + +--+
\ +---+ |--|H4|
+--------|RT4|--| +--+
+---+ |
+
Figure 4: Example 3's internetwork
because it cannot have data-link connections open to
three at once, it will synchronize with RT2 and RT3,
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/
Host H2, the underlying data-link connection to RT2
eventually close due to inactivity. This will allow RT1
finally synchronize with RT4; the next Hello that RT
attempts to send to RT4 will cause that data-link
to open and synchronization with RT4 will ensue. Note that
until this time, H4 will have been considered unreachable
OSPF routing. However, data traffic would not have
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
This causes RT2 to reissue its router-LSA. However, it
be unable to flood it to RT1 if RT1 already has data-
connections open to RT3 and RT4. While the data-
connection from RT2 to RT1 cannot be opened due to
shortages, the new router-LSA will be
retransmitted (and dropped by RT2's ISDN interface;
Section 1). This means that the routers RT1, RT3 and RT
will not detect the unreachability of Host H2 until a data
link connection on RT1 becomes available
5. Topology
Because LSAs indicating topology changes are still flooded
demand circuits, it is still advantageous to design networks so
the demand circuits are isolated from as many topology changes
possible. In OSPF, this is done by encasing the demand
within OSPF stub areas or within NSSAs (see [3]). In both cases,
isolates the demand circuits from AS external routing changes,
in many networks are the most frequent (see [6]). Stub areas can
isolate the demand circuits from changes in other OSPF areas
Also, considering the interoperation of OSPF routers
demand circuits and those that do not (see Section 2.5),
stub areas or NSSAs can be converted independently to support
circuits. In contrast, regular OSPF areas must all be
before the functionality can take effect in any particular
OSPF area
6. Lost
The enhancements defined in this memo to support demand circuits
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
In regular OSPF [1], all LSAs are refreshed
LSRefreshInterval. This provides protection against
losing LSAs from (or LSAs getting corrupted in) their link
databases due to software errors, etc. Over demand
this periodic refresh is removed, and we depend on
correctly holding LSAs marked with DoNotAge in their
indefinitely
Moy [Page 25]
RFC 1793 OSPF over Demand Circuits April 1995
Database
OSPF supplies network management variables,
ospfExternLSACksumSum and ospfAreaLSACksumSum in [7], allowing
network management station to verify OSPF
synchronization among routers. However, these variables are
of the individual LSAs' LS checksum fields, which are no
guaranteed to be identical across demand circuits (because
LS checksum covers the LS Sequence Number, which will in
differ across demand circuits). This means that these
can no longer be used to verify database synchronization in
networks containing demand circuits
7. Future work:
An internetwork is oversubscribed when not all of its
circuits' underlying connections can be open at once, due to
limitations. These internetworks were addressed in Section 4.3.
However, when all possible sources in the internetwork are active
once, problems can occur which are not addressed in this memo
(1) There is a network design problem. Does a subset of
circuits exist such that a) their data-link connections can
open simultaneously and b) they can provide connectivity for
possible sources? This requires that (at least) a spanning
be formed out of established connections. Figure 4 shows
example where this is not possible; Hosts H1 through H4
simultaneously talk, since Router RT1 is limited to
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
when needed for data traffic, and stay established as long
data traffic is present. One example is shown in Figure 5.
routers are interconnected via demand circuits, with each
being able to establish a circuit to any other. However,
assume that each router can only have two circuits open at
(e.g., the routers could be using Basic Rate ISDN). In
case, one would hope that the data-link connections in Figure 5
would form. But the connections in Figure 5b are
likely, which leave Host H2 unable to communicate
One possible approach to this problem would be for a) the
database to indicate which demand circuits have actually
established and b) implement a distributed spanning
construction (see for example Chapter 5.2.2 of [9])
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
not necessarily know which data-link connections are
at any one time. In fact, they view all demand circuits as
equally available, whether or not they are
established. So for example, even when the
connections form the pattern in Figure 5a, Router RT1 may
believe that the best path to Router RT3 is through the
demand circuit. However, this circuit cannot be established
to resource shortages
+--+ + + +--+
|H1|--| +---+ ODL +---+ |--|H2|
+--+ |--|RT1|-------|RT2|--| +--+
| +---+ +---+ |
+ | \ / | +
| \ / |
| \ / |
|ODL / |
| / \ODL |
| / \ |
+ | /ODL \ | +
+--+ | +---+ +---+ | +--+
|H4|--|--|RT4|-------|RT3|--|--|H3|
+--+ | +---+ ODL +---+ | +--+
+ +
Figure 5: Example of an
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
pattern of data-link pattern of data-
connections
On possible approach to this problem is to increase the OSPF cost
demand circuits that are currently discarding application
(i.e., can't be established) due to resource shortages. This may
the routing find paths that can actually deliver the packets. On
downside, it would create more routing traffic. Also,
routing oscillations may result when you start varying
metrics to reflect dynamic network conditions; see [10].
8. Unsupported
The following possible capabilities associated with demand
routing have explicitly not been supported by this memo
o When the topology of an OSPF area changes, the changes
flooded over the area's demand circuits, even if this
(re)establishing the demand circuits' data-link connections.
might imagine a routing system where the flooding of
changes over demand circuits were delayed until the
circuits were (re)opened for application traffic. However,
capability is unsupported because delaying the flooding in
manner would sometimes impair the ability to discover
network destinations
o Refining the previous capability, one might imagine that
network administrator would be able to configure for each
interface whether flooding should be immediate, or whether
should be delayed until the data-link connection is
for application traffic. This would allow certain "application
specific" routing behaviors. For example, a demand circuit
connect a collection of client-based subnets to a collection
Moy [Page 28]
RFC 1793 OSPF over Demand Circuits April 1995
server-based subnets. If the client end was configured to
flooding, while the server end was configured to flood
immediately, then new servers would be discovered promptly
clients might not be discovered until they
conversations. However, this capability is unsupported
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
The OSPF Options field is present in OSPF Hello packets,
Description packets and all LSAs. The Options field enables
routers to support (or not support) optional capabilities, and
communicate their capability level to other OSPF routers.
this mechanism routers of differing capabilities can be mixed
an OSPF routing domain
The memo defines one of the Option bits: the DC-bit (for
Circuit capability). The DC-bit is set in a router's self-
LSAs if and only if it supports the functionality defined in
2 of this memo. Note that this does not necessarily mean that
router can be the endpoint of a demand circuit, but only that it
properly process LSAs having the DoNotAge bit set. In contrast,
DC-bit is set in Hello Packets and Database Description Packets
out an interface if and only if the router wants to treat
attached point-to-point network as a demand circuit (see
3.2.1).
The addition of the DC-bit makes the current assignment of the
Options field as follows
+------------------------------------+
| * | * | DC | EA | N/P | MC | E | T |
+------------------------------------+
Figure 5: The OSPF Options
T-
This bit describes TOS-based routing capability, as specified
[1].
E-
This bit describes the way AS-external-LSAs are flooded,
described in [1].
MC-
This bit describes whether IP multicast datagrams are
according to the specifications in [4].
N/P-
This bit describes the handling of Type-7 LSAs, as specified
[3].
Moy [Page 30]
RFC 1793 OSPF over Demand Circuits April 1995
EA-
This bit describes the router's willingness to receive
forward External-Attributes-LSAs, as 