< draft-ietf-ospf-demand-00.txt   draft-ietf-ospf-demand-01.txt >
Network Working Group J. Moy Network Working Group J. Moy
Internet Draft Proteon, Inc. Internet Draft Cascade
Expiration Date: November 1994 May 1994 Expiration Date: May 1995 November 1994
File name: draft-ietf-ospf-demand-00.txt File name: draft-ietf-ospf-demand-01.txt
Extending OSPF to support demand circuits Extending OSPF to support demand circuits
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by months and may be updated, replaced, or obsoleted by other documents
other documents at any time. It is not appropriate to use at any time. It is inappropriate to use Internet- Drafts as
Internet-Drafts as reference material or to cite them other than as reference material or to cite them other than as "work in progress".
a "working draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or Directories on ds.internic.net (US East Coast), nic.nordu.net
munnari.oz.au. (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract Abstract
This memo defines enhancements to the OSPF protocol that allow This memo defines enhancements to the OSPF protocol that allow
efficient operation over "demand circuits". Demand circuits are efficient operation over "demand circuits". Demand circuits are
those whose costs vary with usage; charges can be based both on network segments whose costs vary with usage; charges can be based
connect time and on bytes/packets transmitted. Examples of such both on connect time and on bytes/packets transmitted. Examples of
circuits include ISDN circuits, X.25 SVCs, and dial-up lines. The demand circuits include ISDN circuits, X.25 SVCs, and dial-up lines.
periodic nature of OSPF routing traffic (as defined in [1]) requires The periodic nature of OSPF routing traffic has until now required a
such circuits to be open constantly, resulting in unwanted usage demand circuit's underlying data-link connection to be constantly
charges. With the modifications described herein, OSPF Hellos and open, resulting in unwanted usage charges. With the modifications
the refresh of OSPF routing information are suppressed, allowing described herein, OSPF Hellos and the refresh of OSPF routing
demand circuits to be closed when not carrying application traffic. information are suppressed on demand circuits, allowing the
underlying data-link connections to be closed when not carrying
application traffic.
Demand circuits and regular network segments (e.g., leased lines) Demand circuits and regular network segments (e.g., leased lines)
are allowed to be combined in any manner. In other words, there are are allowed to be combined in any manner. In other words, there are
no topological restrictions on the demand circuit support. However, no topological restrictions on the demand circuit support. However,
while any OSPF network segment can be defined as a demand circuit, while any OSPF network segment can be defined as a demand circuit,
only point-to-point networks receive the full benefit. When only point-to-point networks receive the full benefit. When
broadcast and NBMA networks are declared demand circuits, routing broadcast and NBMA networks are declared demand circuits, routing
update traffic is reduced but the periodic sending of Hellos is not, update traffic is reduced but the periodic sending of Hellos is not,
which in effect still requires that the data-link circuits be which in effect still requires that the data-link connections be
constantly open. constantly open.
While mainly intended for use with cost-conscious network links such While mainly intended for use with cost-conscious network links such
as ISDN, X.25 and dial-up, the modifications in this memo may also as ISDN, X.25 and dial-up, the modifications in this memo may also
prove useful over bandwidth-limited network links such as slow-speed prove useful over bandwidth-limited network links such as slow-speed
leased lines and packet radio. leased lines and packet radio.
The enhancements defined in this memo are backward-compatible with The enhancements defined in this memo are backward-compatible with
the OSPF specification defined in [1], and with the OSPF extensions the OSPF specification defined in [1], and with the OSPF extensions
defined in [3] (OSPF NSSA areas), [4] (MOSPF) and [8] (OSPF Point- defined in [3] (OSPF NSSA areas), [4] (MOSPF) and [8] (OSPF Point-
to-MultiPoint Interface). to-MultiPoint Interface).
This memo provides functionality comparable to that specified for This memo provides functionality comparable to that specified for
RIP in [2]. However, because OSPF is a link-state routing protocol RIP in [2]. However, because OSPF employs link-state routing
rather than a Distance Vector protocol, the mechanisms used to technology as opposed to RIP's Distance Vector base, the mechanisms
achieve that functionality are quite different. used to achieve the functionality are quite different.
Please send comments to ospf@gated.cornell.edu. Please send comments to ospf@gated.cornell.edu.
Acknowledgments Acknowledgments
The author would like to acknowledge the helpful comments of Fred The author would like to acknowledge the helpful comments of Fred
Baker, Rob Coltun, Gerry Meyer, and Tom Pusateri. This memo is a Baker, Rob Coltun, Dawn Li, Gerry Meyer, Tom Pusateri and Zhaohui
product of the OSPF Working Group. Zhang. This memo is a product of the OSPF Working Group.
Table of Contents Table of Contents
1 Model for demand circuits .............................. 4 1 Model for demand circuits .............................. 4
2 Modifications to all OSPF routers ...................... 4 2 Modifications to all OSPF routers ...................... 5
2.1 The LS age field ....................................... 5 2.1 The OSPF Options field ................................. 5
2.2 Removing old, non-aging LSAs ........................... 6 2.2 The LS age field ....................................... 5
2.3 Interoperability with unmodified OSPF routers .......... 6 2.3 Removing stale DoNotAge LSAs ........................... 6
3 Modifications to demand circuit endpoints .............. 7 2.4 A change to the flooding algorithm ..................... 7
3.1 Configuring demand circuits ............................ 7 2.5 Interoperability with unmodified OSPF routers .......... 8
3.2 Sending and Receiving OSPF Hellos ...................... 8 2.5.1 Indicating across area boundaries ...................... 9
3.3 Interface State machine modifications .................. 8 2.5.1.1 Limiting indication-LSA origination ................... 10
3.4 Flooding over demand circuits .......................... 9 3 Modifications to demand circuit endpoints ............. 11
4 Examples .............................................. 10 3.1 Interface State machine modifications ................. 11
4.1 Example 1: Sole connectivity through demand circuits .. 10 3.2 Sending and Receiving OSPF Hellos ..................... 11
4.2 Example 2: Demand and non-demand circuits in parallel . 14 3.2.1 Negotiating Hello suppression ......................... 12
4.3 Example 3: Operation when suffering SVC shortage ...... 18 3.2.2 Neighbor state machine modifications .................. 12
5 Topology recommendations .............................. 20 3.3 Flooding over demand circuits ......................... 13
6 Lost functionality .................................... 20 3.4 Virtual link support .................................. 14
A The Options field ..................................... 22 3.5 Point-to-MultiPoint Interface support ................. 15
B Configurable Parameters ............................... 23 4 Examples .............................................. 16
C Architectural Constants ............................... 23 4.1 Example 1: Sole connectivity through demand circuits .. 16
References ............................................ 24 4.2 Example 2: Demand and non-demand circuits in parallel . 20
Security Considerations ............................... 24 4.3 Example 3: Operation when oversubscribed .............. 24
Author's Address ...................................... 24 5 Topology recommendations .............................. 25
6 Lost functionality .................................... 26
7 Future work: Oversubscription ......................... 26
A Format of the OSPF Options field ...................... 29
B Configurable Parameters ............................... 30
C Architectural Constants ............................... 30
References ............................................ 31
Security Considerations ............................... 31
Author's Address ...................................... 31
1. Model for demand circuits 1. Model for demand circuits
In this memo, demand circuits refer to those network segments whose In this memo, demand circuits refer to those network segments whose
cost depends on either connect time or on usage (expressed in terms cost depends on either connect time and/or usage (expressed in terms
of bytes or packets). Examples include ISDN circuits and X.25 SVCs. of bytes or packets). Examples include ISDN circuits and X.25 SVCs.
On these circuits, it is desirable for a routing protocol to send as On these circuits, it is desirable for a routing protocol to send as
little routing traffic as possible. In fact, when there is no change little routing traffic as possible. In fact, when there is no change
in network topology it is desirable for a routing protocol to send in network topology it is desirable for a routing protocol to send
no routing traffic at all; this allows the underlying data-link no routing traffic at all; this allows the underlying data-link
connection to be closed when not needed for application data connection to be closed when not needed for application data
traffic. traffic.
The model used within this memo for the maintenance of demand The model used within this memo for the maintenance of demand
circuits is as follows. If there is no data to send (either routing circuits is as follows. If there is no data to send (either routing
protocol traffic or application data), the data-link connection protocol traffic or application data), the data-link connection
remains closed. As soon as there is data to be sent, an attempt to remains closed. As soon as there is data to be sent, an attempt to
open the data-link connection is made (e.g., an ISDN or X.25 call is open the data-link connection is made (e.g., an ISDN or X.25 call is
placed). If the connection is successful, the data is sent, and the placed). When/if the data-link connection is established, the data
circuit stays open until some period of time elapses without more is sent, and the connection stays open until some period of time
data to send. At this point the data-link connection is again elapses without more data to send. At this point the data-link
closed, in order to conserve cost and resources (see Section 1 of connection is again closed, in order to conserve cost and resources
[2]). (see Section 1 of [2]).
The "Presumption of Reachability" described in [2] is also used. The "Presumption of Reachability" described in [2] is also used.
Even though a data-link connection may be closed at any particular Even though a circuit's data-link connection may be closed at any
time, it is assumed by the routing layer that it is available unless particular time, it is assumed by the routing layer (i.e., OSPF)
other information, such as a discouraging diagnostic code resulting that the circuit is available unless other information, such as a
from an attempted data-link connection, is present. discouraging diagnostic code resulting from an attempted data-link
connection, is present.
It may be possible that a data-link connection cannot be opened due It may be possible that a data-link connection cannot be established
to resource shortages. For example, a router with a single basic due to resource shortages. For example, a router with a single basic
rate ISDN interface cannot open more than two simultaneous ISDN rate ISDN interface cannot open more than two simultaneous ISDN
data-link connections (one for each B channel), and limitations in data-link connections (one for each B channel), and limitations in
interface firmware and/or switch capacity may limit the number of interface firmware and/or switch capacity may limit the number of
X.25 SVCs simultaneously supported. In these cases, datagrams to be X.25 SVCs simultaneously supported. When a router cannot
forwarded out these (temporarily unopenable) data-link connections simultaneously open all of its circuits' underlying data-link
are discarded, instead of queued. Note also that this temporary connections due to resource limitations, we say that the router is
inability to open data-link connections is NOT reported by the OSPF oversubscribed. In these cases, datagrams to be forwarded out the
routing system as unreachability; see Section 4.3 for more (temporarily unopenable) data-link connections are discarded,
information. instead of being queued. Note also that this temporary inability to
open data-link connections due to oversubscription is NOT reported
by the OSPF routing system as unreachability; see Section 4.3 for
more information.
This memo assumes that either end of a demand circuit can open the
underlying data-link connection. Note that this assumption is not
true for certain dial-up modems. Also, for some dial network
technologies, call collisions can result when both ends of a circuit
simultaneously attempt to establish the data-link connection. This
memo does not address how such collisions are handled, assuming
instead that they are resolved at the data-link level.
2. Modifications to all OSPF routers 2. Modifications to all OSPF routers
While most of the modifications to support demand circuits are While most of the modifications to support demand circuits are
isolated to the demand circuit endpoints, there are changes required isolated to the demand circuit endpoints (see Section 3), there are
of all OSPF routers. These changes are described in the subsections changes required of all OSPF routers. These changes are described in
below. Routers implementing these changes set the DC-bit in the the subsections below.
options field of their router-LSA (see Section 2.3 and Appendix A),
even if they do not implement the more substantial modifications
required of demand circuit endpoints that are described in Section
3.
2.1. The LS age field 2.1. The OSPF Options field
A new bit is added to the OSPF Options field to support the
demand circuit extensions. This bit is called the "DC-bit". The
resulting format of the Options field is described in Appendix
A.
A router implementing the functionality described in Section 2
of this memo sets the DC-bit in the Options field of all LSAs
that it originates. This is regardless of the LSAs' LS type, and
also regardless of whether the router implements the more
substantial modifications required of demand circuit endpoints
(see Section 3). Setting the DC-bit in self-originated LSAs
tells the rest of the routing domain that the router can
correctly process DoNotAge LSAs (see Sections 2.2, 2.3 and 2.5).
There is a single exception to the above rule. A router
implementing Section 2 of this memo may sometimes originate an
"indication-LSA"; these LSAs always have the DC-bit clear.
Indication-LSAs are used to convey across area boundaries the
existence of routers incapable of DoNotAge processing; see
Section 2.5.1 for details.
2.2. The LS age field
The semantics of the LSA's LS age field are changed, allowing The semantics of the LSA's LS age field are changed, allowing
the high bit (DoNotAge; see Appendix C) to be set. Previously the high bit to be set. This bit is called "DoNotAge"; see
the LS age field could not exceed the value of MaxAge. LSAs Appendix C for its formal definition. LSAs whose LS age field
whose LS age field have the DoNotAge bit set are not aged while have the DoNotAge bit set are not aged while they are held in
they are held in the link state database, which means that they the link state database, which means that they do not have to be
do not have to be refreshed every LSRefreshInterval as is done refreshed every LSRefreshInterval as is done with all other OSPF
with all other OSPF LSAs. LSAs.
By convention, in the rest of this memo we will express LS age By convention, in the rest of this memo we will express LS age
fields having the DoNotAge set as "DoNotAge+x", while an LS age fields having the DoNotAge set as "DoNotAge+x", while an LS age
expressed as just "x" is assumed not to have the DoNotAge bit expressed as just "x" is assumed to not have the DoNotAge bit
set. set. LSAs having DoNotAge set are also sometimes referred to as
"DoNotAge LSAs".
When comparing two LSA instances to see which one is most When comparing two LSA instances to see which one is most
recent, the two LSAs' LS age fields are compared whenever the LS recent, the two LSAs' LS age fields are compared whenever the LS
sequence numbers and LS checksums are found identical (see sequence numbers and LS checksums are found identical (see
Section 13.1 of [1]). Before comparing, the LS age fields should Section 13.1 of [1]). Before comparing, the LS age fields must
have their DoNotAge bits masked off. For example, in have their DoNotAge bits masked off. For example, in
determining which LSA is more recent, LS ages of 1 and determining which LSA is more recent, LS ages of 1 and
DoNotAge+1 should be considered equivalent; an LSA flooded with DoNotAge+1 are considered equivalent; an LSA flooded with LS age
LS age of 1 may be acknowledged with a Link State of 1 may be acknowledged with a Link State Acknowledgement
Acknowledgement listing an LS age of DoNotAge+1, or vice versa. listing an LS age of DoNotAge+1, or vice versa. In particular,
As a special case, DoNotAge+MaxAge is equivalent to MaxAge, and DoNotAge+MaxAge is equivalent to MaxAge; however for backward-
either form can be used to flush LSAs from the routing domain compatibility the MaxAge form should always be used when
(see Section 14.1 of [1]). flushing LSAs from the routing domain (see Section 14.1 of [1]).
When an LSA is flooded out a non-demand interface, the constant
InfTransDelay is added to the LSA's LS age field. This happens
even if the DoNotAge bit is set; in this case the LS age field
is not allowed to exceed DoNotAge+MaxAge, at which time the LSA
is flushed from the routing domain. This preserves the
protection in [1] afforded against flooding loops. Flooding out
demand interfaces is covered in Section 3.4.
Thus, the set of allowable values for the LS age field fall into Thus, the set of allowable values for the LS age field fall into
the two ranges: 0 through MaxAge and DoNotAge through the two ranges: 0 through MaxAge and DoNotAge through
DoNotAge+MaxAge. Any LS age field not falling into these two DoNotAge+MaxAge. (Previously the LS age field could not exceed
ranges should be considered to be equal to MaxAge. the value of MaxAge.) Any LS age field not falling into these
two ranges should be considered to be equal to MaxAge.
When an LSA is flooded out an interface, the constant
InfTransDelay is added to the LSA's LS age field. This happens
even if the DoNotAge bit is set; in this case the LS age field
is not allowed to exceed DoNotAge+MaxAge. If the LS age field
reaches DoNotAge+MaxAge during flooding, the LSA is flushed from
the routing domain. This preserves the protection in [1]
afforded against flooding loops.
The LS age field is not checksum protected. Errors in a router's The LS age field is not checksum protected. Errors in a router's
memory may mistakenly set an LSA's DoNotAge bit, stopping the memory may mistakenly set an LSA's DoNotAge bit, stopping the
aging of the LSA. However, a router should note that its own aging of the LSA. However, a router should note that its own
self-originated LSAs should never have the DoNotAge bit set in self-originated LSAs should never have the DoNotAge bit set in
its own database. This means that in any case the router's its own database. This means that in any case the router's
self-originated LSAs will be refreshed every LSRefreshInterval. self-originated LSAs will be refreshed every LSRefreshInterval.
As this refresh is flooded throughout the OSPF routing domain, As this refresh is flooded throughout the OSPF routing domain,
it will replace any LSA copies whose DoNotAge bits were it will replace any LSA copies in other routers' databases whose
mistakenly set. DoNotAge bits were mistakenly set.
2.2. Removing old, non-aging LSAs 2.3. Removing stale DoNotAge LSAs
Because LSAs with the DoNotAge bit set are never aged, they can Because LSAs with the DoNotAge bit set are never aged, they can
stay in the link state database even when the originator of the stay in the link state database even when the originator of the
LSA no longer exists. To ensure that these LSAs are eventually LSA no longer exists. To ensure that these LSAs are eventually
flushed from the routing domain, and that the size of the link flushed from the routing domain, and that the size of the link
state database doesn't grow without bound, routers are required state database doesn't grow without bound, routers are required
to flush an LSA if the originator of the LSA has been to flush a DoNotAge LSA if both of the following conditions are
unreachable (according to the routing calculations specified by met:
Section 16 of [1]) for the time MaxAge. For an example, see Time
T8 in Section 4.1. This is an exception to the general OSPF rule (1) The LSA has been in the router's database for at least
that a router can only flush its own self-originated LSAs. MaxAge seconds.
(2) The originator of the LSA has been unreachable (according to
the routing calculations specified by Section 16 of [1]) for
at least MaxAge seconds.
For an example, see Time T8 in the example of Section 4.1. Note
that the above functionality is an exception to the general OSPF
rule that a router can only flush (i.e., prematurely age; see
Section 14.1 of [1]) its own self-originated LSAs. The above
functionality pertains only to DoNotAge LSAs. An LSA having
DoNotAge clear still can be prematurely aged only by its
originator; otherwise, the LSA must age naturally to MaxAge
before being removed from the routing domain.
An interval as long as MaxAge has been chosen to avoid any An interval as long as MaxAge has been chosen to avoid any
possibility of thrashing (i.e., flushing an advertisement only possibility of thrashing (i.e., flushing an LSA only to have it
to have it reoriginated soon afterwards). reoriginated soon afterwards). Note that by the above rules, a
DoNotAge LSA will be removed from the routing domain no faster
than if it were being aged naturally (i.e., if DoNotAge were not
set).
2.3. Interoperability with unmodified OSPF routers 2.4. A change to the flooding algorithm
Unmodified OSPF routers will probably treat LSAs with the The following change is made to the OSPF flooding algorithm.
DoNotAge bit set as if they had LS age of MaxAge. At the very When a Link State Update Packet is received that contains an LSA
worst, this will cause continual retransmissions of LSAs with instance which is actually less recent than the the router's
the DoNotAge bit set. current database copy, the router must now respond by sending
its database copy (encapsulated in a Link State Update Packet)
back to the sending neighbor. When doing so, the LSA is NOT
added to the neighbor's link state retransmission list. The
previous behavior was to ignore the flood of the less recent LSA
instance; see Step 8 of Section 13 in [1].
However, to avoid this confusion, advertisements with DoNotAge This change is necessary to support flooding over demand
set will be allowed in an OSPF area only if, in the area's link circuits. For example, see Time T4 in the example of Section
state database, all router-LSAs and type-4-summary-LSAs 4.2.
(location of ASBRs) have their DC-bit set (indicating their
ability to process DoNotAge). Note that it is not required that
the LSAs' Advertising Router is reachable; if any LSA is found
not having its DC-bit set (regardless of reachability), then the
router should flush from the area all advertisements having
DoNotAge set; this is an exception to the general OSPF rule that
a router can only flush its own self-originated LSAs. When
flushing, the LSAs' LS age field should be set to MaxAge and not
DoNotAge+MaxAge.
(As an implementation suggestion, a new variable "DCBitLessLSAs" However, this change is beneficial when flooding over non-demand
could be added to the OSPF area data structure in Section 6 of interfaces as well. For this reason, the flooding change
[1]. This variable would count the number of the area's router- pertains to all interfaces, not just interfaces to demand
LSAs and type-4-summary-LSAs that do not have the DC-bit set. circuits. The main example involves MaxAge LSAs. There are times
when MaxAge LSAs stay in a router's database for extended
intervals: 1) when they are stuck in a retransmission queue on a
slow link or 2) when a router is not properly flushing them from
its database, due to software bugs. The prolonged existence of
these MaxAge LSAs can inhibit the flooding of new instances of
the LSA. New instances typically start with the initial LS
sequence number, and are treated as less recent (and hence
discarded) by routers still holding MaxAge instances. However,
with the above change to flooding, a router with a MaxAge
instance will respond back with the MaxAge instance. This will
get back to the LSA's originator, which will then pick the next
highest LS sequence number and reflood, overwriting the MaxAge
instance.
This variable would potentially increment/decrement any time a This change will be included in future revisions of the base
new LSA was received or an old LSA was replaced or flushed.) OSPF specification [1].
In particular, AS-external-LSAs with the DoNotAge bit set cannot 2.5. Interoperability with unmodified OSPF routers
exist in the routing domain unless all routers in all "regular
OSPF areas" (all areas that are neither stub areas nor NSSAs) Unmodified OSPF routers will probably treat DoNotAge LSAs as if
are capable of processing DoNotAge. In order to convey this they had LS age of MaxAge. At the very worst, this will cause
information across area boundaries, area border routers must set continual retransmissions of the DoNotAge LSAs. (An example
the DC-bit in a type-4-summary-LSA that they originate if and scenario follows. Suppose Routers A and B are connected by a
only if the described ASBR has the DC-bit set in its original point-to-point link. Router A implements the demand circuit
router-LSA. Additionally, sometimes in may be necessary to extensions, Router B does not. Neither one treats their
convey across areas the the existence of a non-ASBR that cannot connecting link as a demand circuit. At some point in time,
process DoNotAge. In this case, a type-4-summary-LSA should be Router A receives from another neighbor via flooding a DoNotAge
originated with cost of LSInfinity and DC-bit clear. LSA. The DoNotAge LSA is then flooded by Router A to Router B.
Router B, not understanding DoNotAge LSAs, treats it as a MaxAge
LSA and acknowledges it as such to Router A. Router A receives
the acknowledgment, but notices that the acknowledgment is for a
different instance, and so starts retransmitting the LSA.)
However, to avoid this confusion, DoNotAge LSAs will be allowed
in an OSPF area if and only if, in the area's link state
database, all LSAs have the DC-bit set in their Options field
(see Section 2.1). Note that it is not required that the LSAs'
Advertising Router be reachable; if any LSA is found not having
its DC-bit set (regardless of reachability), then the router
should flush (i.e., prematurely age; see Section 14.1 of [1])
from the area all DoNotAge LSAs. These LSAs will then be
reoriginated at their sources, this time with DoNotAge clear.
Like the change in Section 2.3, this change is an exception to
the general OSPF rule that a router can only flush its own
self-originated LSAs. Both changes pertain only to DoNotAge
LSAs, and in both cases a flushed LSA's LS age field should be
set to MaxAge and not DoNotAge+MaxAge.
2.5.1. Indicating across area boundaries
AS-external-LSAs are flooded throughout the entire OSPF
routing domain, excepting only OSPF stub areas and NSSAs.
For that reason, if an OSPF router that is incapable of
DoNotAge processing exists in any "regular" area (i.e., an
area that is not a stub nor an NSSA), no AS-external-LSA can
have DoNotAge set. This memo simplifies that requirement by
broadening it to the following rule: LSAs in regular OSPF
areas are allowed to have DoNotAge set if and only if every
router in the OSPF domain (excepting those in stub areas and
NSSAs) is capable of DoNotAge processing. The rest of this
section describes how the rule is implemented.
As described above in Sections 2.1 and 2.5, a router
indicates that it is capable of DoNotAge processing by
setting the DC-bit in the LSAs that it originates. However,
there is a problem. It is possible that, in all areas to
which Router X directly attaches, all the routers are
capable of DoNotAge processing, yet there is some router in
a remote "regular" area that cannot process DoNotAge LSAs.
This information must then be conveyed to Router X, so that
it does not mistakenly flood/create DoNotAge LSAs.
The solution is as follows. Area border routers transmit the
existence of DoNotAge-incapable routers across area
boundaries, using "indication-LSAs". Indication-LSAs are
type-4-summary LSAs (also called ASBR-summary-LSAs), listing
the area border router itself as the described ASBR, with
the LSA's cost set to LSInfinity and the DC-bit clear. Note
that indication-LSAs convey no additional information; in
particular, they are used even if the area border router is
not really an AS boundary router (ASBR).
Taking indication-LSAs into account, the rule as to whether
DoNotAge LSAs are allowed in any particular area is EXACTLY
the same as given previously in Section 2.5, namely:
DoNotAge LSAs will be allowed in an OSPF area if and only
if, in the area's link state database, all LSAs have the
DC-bit set in their Options field.
Through origination of indication-LSAs, the existence of
DoNotAge-incapable routers can be viewed as going from non-
backbone regular areas, to the backbone area and from there
to all other regular areas. The following two cases
summarize the requirements for an area border router to
originate indication-LSAs:
(1) Suppose an area border router (Router X) is connected to
a regular non-backbone OSPF area (Area A). Furthermore,
assume that Area A has LSAs with the DC-bit clear, other
than indication-LSAs. Then Router X should originate
indication-LSAs into all other directly-connected
"regular" areas, including the backbone area, keeping
the guidelines of Section 2.5.1.1 in mind.
(2) Suppose an area border router (Router X) is connected to
the backbone OSPF area (Area 0.0.0.0). Furthermore,
assume that the backbone has LSAs with the DC-bit clear
that are either a) not indication-LSAs or b)
indication-LSAs that have been originated by routers
other than Router X itself. Then Router X should
originate indication-LSAs into all other directly-
connected "regular" non-backbone areas, keeping the
guidelines of Section 2.5.1.1 in mind.
2.5.1.1. Limiting indication-LSA origination
To limit the number of indication-LSAs originated, the
following guidelines should be observed by an area
border router (Router X) when originating indication-
LSAs. First, indication-LSAs are not originated into an
Area A when A already has LSAs with DC-bit clear other
than indication-LSAs. Second, if another area border
router has originated a indication-LSA into Area A, and
that area border router has a higher OSPF Router ID than
Router X (same tie-breaker as for forwarding address
origination; see Section 12.4.5 of [1]), then Router X
should not originate an indication-LSA into Area A.
As an example, suppose that three regular OSPF areas
(Areas A, B and C) are connected by routers X, Y and Z
(respectively) to the backbone area. Furthermore,
suppose that all routers are capable of DoNotAge
processing, except for routers in Areas A and B.
Finally, suppose that Router Z has a higher Router ID
than Y, which in turn has a higher Router ID than X. In
this case, two indication-LSAs will be generated (if the
rules of Section 2.5.1 and the guidelines of the
preceding paragraph are followed): Router Y will
originate an indication-LSA into the backbone, and
Router Z will originate an indication-LSA into Area C.
3. Modifications to demand circuit endpoints 3. Modifications to demand circuit endpoints
The following subsections detail the modifications required of the The following subsections detail the modifications required of the
routers at the endpoints of demand circuits. This consists of routers at the endpoints of demand circuits. These consist of
modifications to two main pieces of OSPF: 1) sending and receiving modifications to two main pieces of OSPF: 1) sending and receiving
hellos over demand circuits and 2) flooding LSAs over demand Hello Packets over demand circuits and 2) flooding LSAs over demand
circuits. circuits.
3.1. Configuring demand circuits An additional OSPF interface configuration parameter,
DemandInterface, is defined to indicate whether an OSPF interface
connects to a demand circuit (see Appendix B). Two routers
connecting to a common network segment need not agree on that
segment's demand circuit status. However, to get full benefit of the
demand circuit extensions, the two ends of a point-to-point link
must both agree to treat the link as a demand circuit (see Section
3.2).
An additional OSPF interface configuration parameter, 3.1. Interface State machine modifications
DemandInterface, is defined to indicate whether an OSPF
interface connects to a demand circuit (see Appendix B). On
point-to-point demand circuits, the neighboring router must
agree that the point-to-point link is a demand circuit. To
ensure this agreement, the router sets the DC-bit in OSPF Hellos
(and Database Description Packets) sent out the demand
interface. Receiving an Hello or a Database Description Packet
with the DC-bit set indicates agreement. Receiving an Hello with
the DC-bit clear and also listing the router's Router ID in the
body of the Hello message, or a Database Description Packet with
the DC-bit clear (either one indicating bidirectional
connectivity) indicates that the other end refuses to treat the
link as a demand circuit. In these cases, the router reverts to
treating the link as a leased line.
The above procedure indicates that a demand point-to-point An OSPF point-to-point interface connecting to a demand circuit
circuit need be configured in only one of the two endpoints (see is considered to be in state "Point-to-point" if and only if its
Section 4.1). associated neighbor is in state "1-Way" or greater; otherwise
the interface is considered to be in state "Down". Hellos are
sent out such an interface when it is in "Down" state, at the
reduced interval of PollInterval. If the negotiation in Section
3.2.1 succeeds, Hellos will cease to be sent out the interface
whenever the associated neighbor reaches state "Full".
If the negotiation fails, and the router is forced to treat the Note that as a result, an "LLDown" event for the point-to-point
line as a leased line, the router can always renegotiate the demand circuit's neighbor forces both the neighbor and the
link's demand status whenever the link goes down. For example, interface into state "Down" (see Section 3.2.2).
if the neighboring router is rebooted with software that is
capable of operating over demand circuits, a future negotiation
will succeed.
For more information on sending OSPF Hellos over demand For OSPF broadcast and NBMA networks that have been configured
circuits, see Section 3.2. as demand circuits, there are no changes to the Interface State
Machine.
3.2. Sending and Receiving OSPF Hellos 3.2. Sending and Receiving OSPF Hellos
Over point-to-point demand circuits OSPF Hello packets are sent The following sections describe the required modifications to
only until initial link-state database synchronization is OSPF Hello Packet processing on point-to-point demand circuits.
achieved with the neighbor (i.e., the state of the neighbor
connection reaches "Full", as defined in Section 10.1 of [1]).
After this, Hellos are suppressed and the data-link connection
to the neighbor is assumed available until evidence is received
to the contrary. When the router finds that the neighbor is no
longer available, presumably from something like a diagnostic
code contained in a response to a failed call request, the
neighbor connection transitions back to "Down" and Hellos are
sent periodically (at Intervals of PollInterval) in an attempt
to restart synchronization with the neighbor.
This requires changes to the OSPF Neighbor State Machine (see
Section 10.3 of [1]). The receipt of Hellos from neighbors in
state "Loading" or higher cannot be required. In other words,
the InactivityTimer event defined in Section 10.2 of [1] has no
effect on neighbors in state "Loading" or higher. An additional
clarification is needed in the Neighbor State Machine's LLDown
event. This event should be mapped into the "discouraging
diagnostic code" discussed above in Section 1, and should not be
generated when the data-link connection has been closed simply
to save resources.
For OSPF broadcast and NBMA networks that have been configured For OSPF broadcast and NBMA networks that have been configured
as demand circuits, there is no change to the sending and as demand circuits, there is no change to the sending and
receiving of Hellos, nor are there any changes to the Neighbor receiving of Hellos, nor are there any changes to the Neighbor
State Machine. This is because the proper operation of the State Machine. This is because the proper operation of the
Designated Router election algorithm requires periodic exchange Designated Router election algorithm requires periodic exchange
of Hello Packets. of Hello Packets.
3.3. Interface State machine modifications 3.2.1. Negotiating Hello suppression
OSPF interfaces to point-to-point demand circuits are considered On point-to-point demand circuits, both endpoints must agree
to be in "Point-to-point" state if and only if they have a to suppress the sending of Hello Packets. To ensure this
neighbor in state "1-Way" or greater, otherwise they are agreement, a router sets the DC-bit in OSPF Hellos and
considered to be in state "Down". However, as discussed above in Database Description Packets sent out the demand interface.
Section 3.2, Hellos are sent out interfaces in "Down" state, at Receiving an Hello or a Database Description Packet with the
the reduced interval of PollInterval. Hellos cease to be sent DC-bit set indicates agreement. Receiving an Hello with the
out the interface whenever the associated neighbor reaches state DC-bit clear and also listing the router's Router ID in the
"Full". body of the Hello message, or a Database Description Packet
with the DC-bit clear (either one indicating bidirectional
connectivity) indicates that the other end refuses to
suppress Hellos. In these latter cases, the router reverts
to the normal periodic sending of Hello Packets out the
interface (see Section 9.5 of [1]).
Note that as a result, an "LLDown" event for the point-to-point A demand point-to-point circuit need be configured in only
demand circuit's neighbor forces both the neighbor and the one of the two endpoints (see Section 4.1). If a router
interface into state "Down". implementing Sections 2 and 3 of this memo receives an Hello
Packet with the DC-bit set, it should treat the point-to-
point link as a demand circuit, making the appropriate
changes to its Hello Processing (see Section 3.2.2) and
flooding (see Section 3.3).
For OSPF broadcast and NBMA networks that have been configured Even if the above negotiation fails, the router should
as demand circuits, there are no changes to the Interface State continue setting the DC-bit in its Hellos and Database
Machine. Descriptions (the neighbor will just ignore the bit). The
router will then automatically attempt to renegotiate Hello
suppression whenever the link goes down and comes back up.
For example, if the neighboring router is rebooted with
software that is capable of operating over demand circuits
(i.e., implements Sections 2 and 3 of this memo), a future
negotiation will succeed.
3.4. Flooding over demand circuits Also, even if the negotiation to suppress Hellos fails, the
flooding modifications described in Section 3.3 are still
performed over the link.
3.2.2. Neighbor state machine modifications
When the above negotiation succeeds, Hello Packets are sent
over point-to-point demand circuits only until initial
link-state database synchronization is achieved with the
neighbor (i.e., the state of the neighbor connection reaches
"Full", as defined in Section 10.1 of [1]). After this,
Hellos are suppressed and the data-link connection to the
neighbor is assumed available until evidence is received to
the contrary. When the router finds that the neighbor is no
longer available, presumably from something like a
diagnostic code contained in a response to a failed call
request, the neighbor connection transitions back to "Down"
and Hellos are sent periodically (at Intervals of
PollInterval) in an attempt to restart synchronization with
the neighbor.
This requires changes to the OSPF Neighbor State Machine
(see Section 10.3 of [1]). The receipt of Hellos from demand
circuit neighbors in state "Loading" or "Full" can no longer
be required. In other words, the InactivityTimer event
defined in Section 10.2 of [1] has no effect on demand
circuit neighbors in state "Loading" or "Full". An
additional clarification is needed in the Neighbor State
Machine's LLDown event. For demand circuits, this event
should be mapped into the "discouraging diagnostic code"
discussed previously in Section 1, and should not be
generated when the data-link connection has been closed
simply to save resources. Nor should LLDown be generated if
a data-link connection fails due to temporary lack of
resources.
3.3. Flooding over demand circuits
Flooding over demand circuits (point-to-point or otherwise) is Flooding over demand circuits (point-to-point or otherwise) is
modified if and only if all routers have indicated that they can modified if and only if all routers have indicated that they can
process LSAs having DoNotAge set. This is determined by process LSAs having DoNotAge set. This is determined by
examining the link state database of the OSPF area containing examining the link state database of the OSPF area containing
the demand circuit. All the router-LSAs and type-4-summary-LSAs the demand circuit. All LSAs in the database must have the DC-
must have the DC-bit set. If one or more LSAs have the DC-bit bit set. If one or more LSAs have the DC-bit clear, flooding
clear, flooding over demand circuits is unchanged from [1]. (In over demand circuits is unchanged from [1]. Otherwise, flooding
particular, router-LSAs or type-4-summary-LSAs that do not have is changed as follows.
the DC-bit set are flooded unchanged from [1], because their
reception inhibits the flooding behavior defined below).
Otherwise, flooding is changed as follows.
First, only truly changed LSAs are flooded over demand circuits. (1) Only truly changed LSAs are flooded over demand circuits.
When a router receives a new LSA instance, it checks first to When a router receives a new LSA instance, it checks first
see whether the contents have changed. If not, the new LSA is to see whether the contents have changed. If not, the new
simply a periodic refresh and it is not flooded out attached LSA is simply a periodic refresh and it is not flooded out
demand circuits (it is still flooded out other interfaces attached demand circuits (it is still flooded out other
however). This check should be performed in Step 5b of Section interfaces however). This check should be performed in Step
13 in [1]. When comparing an LSA to its previous instance, the 5b of Section 13 in [1]. When comparing an LSA to its
following are all considered to be changes in contents: previous instance, the following are all considered to be
changes in contents:
o The LSA's Options field has changed. o The LSA's Options field has changed.
o One of the LSA instances has LS age set to MaxAge (or o One or both of the LSA instances has LS age set to
DoNotAge+MaxAge). MaxAge (or DoNotAge+MaxAge).
o The length field in the LSA header has changed. o The length field in the LSA header has changed.
o The contents of the LSA, excluding the 20-byte link state o The contents of the LSA, excluding the 20-byte link
header, have changed. Note that this excludes changes in LS state header, have changed. Note that this excludes
Sequence Number and LS Checksum. changes in LS Sequence Number and LS Checksum.
Second, when it has been decided to flood an LSA over a demand (2) When it has been decided to flood an LSA over a demand
circuit, DoNotAge should be set in the LSA's LS age field before circuit, DoNotAge should be set in the copy of the LSA that
flooding. This will cause the routers on the other side of the is flooded out the demand interface. (There is one
demand circuit to hold the LSA in their database indefinitely, exception: DoNotAge should not be set if the LSA's LS age is
removing the need for periodic refresh. Note that it is equal to MaxAge.) Setting DoNotAge will cause the routers on
perfectly possible that DoNotAge will already be set. This the other side of the demand circuit to hold the LSA in
simply indicates that the LSA has already been flooded over their databases indefinitely, removing the need for periodic
demand circuits. In any case, the LS age field must also be refresh. Note that it is perfectly possible that DoNotAge
incremented by InfTransDelay before flooding (see Step 5 of will already be set. This simply indicates that the LSA has
Section 13.3 in [1]), as protection against flooding loops. already been flooded over demand circuits. In any case, the
flooded copy's LS age field must also be incremented by
InfTransDelay (see Step 5 of Section 13.3 in [1], and
Section 2.2 of this memo), as protection against flooding
loops.
The above paragraph also pertains to LSAs flooded over demand The previous paragraph also pertains to LSAs flooded over
circuits in response to Link State Requests. demand circuits in response to Link State Requests. It also
pertains to LSAs that are retransmitted over demand
circuits.
Third, when receiving a Link State Update from a demand circuit 3.4. Virtual link support
neighbor that contains an LSA instance that is actually older
than the the router's current copy, the router must respond by OSPF virtual links are essentially unnumbered point-to-point
flooding its current LSA copy directly to the neighbor (without links (see Section 15 of [1]). Accordingly, demand circuit
putting the LSA on the neighbor's Link State retransmission support for virtual links resembles that described for point-
list). This is instead of the behavior specified in Step 8 of to-point links in the previous sections. The main difference is
Section 13 in [1], which would effectively ignore the flood of that a router implementing Sections 2 and 3 of this memo, and
the older advertisement. To see the necessity of responding to supporting virtual links, always treats virtual links as if they
old LSAs, see Time T4 in Section 4.2. were demand circuits. Otherwise, when a virtual link's
underlying physical path contains one or more demand circuits,
periodic OSPF protocol exchanges over the virtual link would
unnecessarily keep the underlying demand circuits open.
Demand circuit support on virtual links can be summarized as
follows:
o Instead of modifying the Interface state machine for virtual
links as was done for point-to-point links in Section 3.1,
the Interface state machine for virtual links remains
unchanged. A virtual link is considered to be in state
"Point-to-point" if an intra-area path (through the virtual
link's transit area) exists to the other endpoint. Otherwise
it is considered to be in state "Down". See Section 15 of
[1] for more details.
o Virtual links are always treated as demand circuits. In
particular, over virtual links a router always negotiates to
suppress the sending of Hellos. See Sections 3.2.1 and 3.2.2
for details.
o In the demand circuit support over virtual links, there is
no "discouraging diagnostic code" as described in Section 1.
Instead, the connection is considered to exist if and only
if an intra-area path (through the virtual link's transit
area) exists to the other endpoint. See Section 15 of [1]
for more details.
o Since virtual links are always treated as demand circuits,
flooding over virtual links always proceeds as in Section
3.3.
3.5. Point-to-MultiPoint Interface support
The OSPF Point-to-MultiPoint interface has recently been
developed for use with non-mesh-connected network segments. A
common example is a Frame Relay subnet where PVCs are
provisioned between some pairs of routers, but not all pairs. In
this case the Point-to-Multipoint interface represents the
single physical interface to the Frame relay network, over which
multiple point-to-point OSPF conversations (one on each PVC) are
taking place. For more information on the Point-to-MultiPoint
interface, see [8].
Since an OSPF Point-to-MultiPoint interface essentially consists
of multiple point-to-point connections, demand circuit support
on the Point-to-Multipoint interface strongly resembles demand
circuit support for point-to-point links. However, since the
Point-to-MultiPoint interface requires commonality of its
component point-to-point links' configurations, there are some
differences.
Demand circuit support on Point-to-Multipoint interfaces can be
summarized as follows:
o Instead of modifying the Interface state machine for Point-
to-Multipoint interfaces as was done for point-to-point
links in Section 3.1, the Interface state machine for
Point-to-Multipoint interfaces remains unchanged.
o When a Point-to-MultiPoint interface is configured as a
DemandInterface, it tries to negotiate Hello suppression
separately on each of its component point-to-point links.
This negotiation proceeds as in Section 3.2.1. Negotiation
may fail on some component point-to-point links, and succeed
on others. This is acceptable. On those component links
where the negotiation fails, Hellos will always be sent;
otherwise, Hellos will cease to be sent when the Database
Description process completes on the component link (see
Section 3.2.2).
o Section 3.3 defines the demand circuit flooding behavior for
all OSPF interface types. This includes Point-to-Multipoint
interfaces.
4. Examples 4. Examples
This section gives three examples of the operation over demand This section gives three examples of the operation over demand
circuits. The first example is probably the most common and circuits. The first example is probably the most common and
certainly the most basic. It shows a single point-to-point demand certainly the most basic. It shows a single point-to-point demand
circuit connecting two routers. The second illustrates what happens circuit connecting two routers. The second illustrates what happens
when demand circuits and leased lines are used in parallel. The when demand circuits and leased lines are used in parallel. The
third explains what happens when a router has multiple demand third explains what happens when a router has multiple demand
circuits and cannot keep them all open (for resource reasons) at the circuits and cannot keep them all open (for resource reasons) at the
same time. same time.
4.1. Example 1: Sole connectivity through demand circuits 4.1. Example 1: Sole connectivity through demand circuits
Figure 1 shows a sample internetwork with a single demand Figure 1 shows a sample internetwork with a single demand
circuit providing connectivity to the LAN containing Host H2. circuit providing connectivity to the LAN containing Host H2.
Assume that all three routers (RTA, RTB and RTC) have Assume that all three routers (RTA, RTB and RTC) have
implemented the functionality in Section 2 of this memo, and implemented the functionality in Section 2 of this memo, and
thus will be setting the DC-bit in their router-LSAs. thus will be setting the DC-bit in their LSAs. Furthermore
Furthermore assume that Router RTB has been configured to treat assume that Router RTB has been configured to treat the link to
the link to Router RTC as a demand circuit, but Router RTC has Router RTC as a demand circuit, but Router RTC has not been so
not been so configured. Finally assume that the LAN interface configured. Finally assume that the LAN interface connecting
connecting Router RTA to Host H1 is initially down. Router RTA to Host H1 is initially down.
The following sequence of events may then transpire, starting The following sequence of events may then transpire, starting
with Router RTB booting and bringing up its link to Router RTC: with Router RTB booting and bringing up its link to Router RTC:
Time T0: RTB negotiates Hello suppression
Router RTB will start sending Hellos over the demand circuit
with the DC-bit set in the Hello's Options field. Because
RTC is not configured to treat the link as a demand circuit,
the first Hello received from RTC will not have the DC-bit
set. However, subsequent Hellos and Database Description
+ + + + + +
| +---+ | | | +---+ | |
+--+ |---|RTA|---| | +--+ +--+ |---|RTA|---| | +--+
|H1|---| +---+ | |---|H2| |H1|---| +---+ | |---|H2|
+--+ | | +---+ ODL +---+ | +--+ +--+ | | +---+ ODL +---+ | +--+
|LAN Y |---|RTB|-------------|RTC|---| |LAN Y |---|RTB|-------------|RTC|---|
+ | +---+ +---+ | + | +---+ +---+ |
+ + + +
Figure 1: A single demand circuit (labeled Figure 1: In the example of Section 4.1,
ODL) bisecting an internetwork. a single demand circuit (labeled
ODL) bisects an internetwork.
Time T0: RTB negotiates demand circuit status
Router RTB will start sending Hellos over the demand circuit
with the DC-bit set in the Hello's Options field. Because
RTC is not configured to treat the link as a demand circuit,
the first Hello received from RTC may not have the DC-bit
set. However, subsequent Hellos and Database Description
Packets received from RTC will have the DC-bit set, Packets received from RTC will have the DC-bit set,
indicating that the two routers have agreed that the link indicating that the two routers have agreed that the link
will be treated as a demand circuit. The entire negotiation will be treated as a demand circuit. The entire negotiation
is pictured in Figure 2. Note that if RTC were unable or is pictured in Figure 2. Note that if RTC were unable or
unwilling to treat the link as a demand circuit, the initial unwilling to suppress Hellos on the link, the initial
Database Description sent from Router RTC to RTB would have Database Description sent from Router RTC to RTB would have
the DC-bit clear, forcing treatment of the link as a leased the DC-bit clear, forcing Router RTB to revert to the
line. periodic sending of Hellos specified in Section 9.5 of [1].
Time T1: Database exchange over demand circuit
The initial synchronization of link state databases (the
Database Exchange Process) over the demand circuit then
occurs as over any point-to-point link, with one exception.
+---+ +---+ +---+ +---+
|RTB| |RTC| |RTB| |RTC|
+---+ +---+ +---+ +---+
Hello (DC-bit set) Hello (DC-bit set)
-------------------------------------> ------------------------------------->
Hello (DC-bit clear) Hello (DC-bit clear)
<------------------------------------- <-------------------------------------
Hello (DC-bit set, RTC seen) Hello (DC-bit set, RTC seen)
-------------------------------------> ------------------------------------->
Database Description (DC-bit set) Database Description (DC-bit set)
<------------------------------------- <-------------------------------------
Figure 2: Successful negotiation of a link's Figure 2: Successful negotiation of Hello
demand circuit status. suppression.
Time T1: Database exchange over demand circuit
The initial synchronization of link state databases (the LSAs included in Link State Updates Packets sent over the
Database Exchange Process) over the demand circuit then demand circuit (in response to Link State Request Packets),
occurs as over any point-to-point link, with one exception. will have the DoNotAge bit set in their LS age field. So,
LSAs included in Link state updates sent over the demand after the Database Exchange Process is finished, all routers
circuit (in response to Link State Request Packets), will will have 3 LSAs in their link state databases (router-LSAs
have the DoNotAge bit set in their LS age field. So, after for Routers RTA, RTB and RTC), but the LS age fields
the Database Exchange Process is finished, all routers will belonging to the LSAs will vary depending on which side of
have 3 LSAs in their link state databases (router-LSAs for the demand circuit they were originated from (see Table 1).
Routers RTA, RTB and RTC), but the LS age fields belonging For example, all routers other than Router RTC have the
to the LSAs will vary depending on which side of the demand DoNotAge bit set in Router RTC's router-LSA; this removes
circuit they were originated from (see Table 1). For the need for Router RTC to refresh its router-LSA over the
example, all routers other than Router RTC have the DoNotAge demand circuit.
bit set in Router RTC's router-LSA; this removes the need
for Router RTC to refresh its router-LSA over the demand
circuit.
Time T2: Hello traffic ceases Time T2: Hello traffic ceases
After the Database Exchange Process has completed, no Hellos After the Database Exchange Process has completed, no Hellos
are sent over the demand circuit. If there is no application are sent over the demand circuit. If there is no application
data to be sent over the demand circuit, the circuit will be data to be sent over the demand circuit, the circuit will be
idle. idle.
Time T3: Underlying data-link connection torn down Time T3: Underlying data-link connection torn down
After some period of inactivity, the underlying data-link After some period of inactivity, the underlying data-link
connection will be torn down (e.g., an ISDN call will be connection will be torn down (e.g., an ISDN call would be
cleared) in order to save connect charges. This will be cleared) in order to save connect charges. This will be
transparent to the OSPF routing; no LSAs or routing table transparent to the OSPF routing; no LSAs or routing table
entries will change as a result. entries will change as a result.
LS age LS age
LSA in RTB in RTC LSA in RTB in RTC
______________________________________________ ______________________________________________
RTA's Router-LSA 1000 DoNotAge+1001 RTA's Router-LSA 1000 DoNotAge+1001
RTB's Router-LSA 10 DoNotAge+11 RTB's Router-LSA 10 DoNotAge+11
RTC's Router-LSA DoNotAge+11 10 RTC's Router-LSA DoNotAge+11 10
Table 1: LS age fields on either Table 1: After Time T1 in Section 4.1,
possible LS age fields on either
side of the demand circuit side of the demand circuit
Time T4: Router RTA's LSA is refreshed Time T4: Router RTA's LSA is refreshed
At some point Router RTA will refresh its own router-LSA At some point Router RTA will refresh its own router-LSA
(i.e., when the LSA's LS age hits LSRefreshInterval). This (i.e., when the LSA's LS age hits LSRefreshInterval). This
refresh will be flooded to Router RTB, who will look at it refresh will be flooded to Router RTB, who will look at it
and decide NOT to flood it over the demand circuit to Router and decide NOT to flood it over the demand circuit to Router
RTC, because the LSA's contents have not really changed RTC, because the LSA's contents have not really changed
(only the LS Sequence Number). At this point, the LS (only the LS Sequence Number). At this point, the LS
skipping to change at page 14, line 5 skipping to change at page 20, line 5
If an indication is received from the data-link or physical If an indication is received from the data-link or physical
layers indicating that the demand circuit can no longer be layers indicating that the demand circuit can no longer be
established, Routers RTB and RTC declare their point-to- established, Routers RTB and RTC declare their point-to-
point interfaces down, and originate new router-LSAs. Both point interfaces down, and originate new router-LSAs. Both
routers will attempt to bring the connection back up by routers will attempt to bring the connection back up by
sending Hellos at the reduced rate of PollInterval. Note sending Hellos at the reduced rate of PollInterval. Note
that while the connection is inoperative, Routers RTA and that while the connection is inoperative, Routers RTA and
RTB will continue to have an old router-LSA for RTC in their RTB will continue to have an old router-LSA for RTC in their
link state database, and this LSA will not age out because link state database, and this LSA will not age out because
it has the DoNotAge bit set. However, according to Section it has the DoNotAge bit set. However, according to Section
2.2 they will flush Router RTC's router-LSA if the demand 2.3 they will flush Router RTC's router-LSA if the demand
circuit remains inoperative for longer than MaxAge. circuit remains inoperative for longer than MaxAge.
4.2. Example 2: Demand and non-demand circuits in parallel 4.2. Example 2: Demand and non-demand circuits in parallel
This example demonstrates the demand circuit functionality when This example demonstrates the demand circuit functionality when
both demand circuits and non-demand circuits (e.g., leased both demand circuits and non-demand circuits (e.g., leased
lines) are used to interconnect regions of an internetwork. Such lines) are used to interconnect regions of an internetwork. Such
an internetwork is shown in Figure 3. Host H1 can communicate an internetwork is shown in Figure 3. Host H1 can communicate
with Host H2 either over the demand link between Routers RTB and with Host H2 either over the demand link between Routers RTB and
RTC, or over the leased line between Routers RTB and RTD. RTC, or over the leased line between Routers RTB and RTD.
skipping to change at page 14, line 44 skipping to change at page 20, line 44
Time T0: Router RTB comes up. Time T0: Router RTB comes up.
Assume RTB supports the demand circuit OSPF modifications. Assume RTB supports the demand circuit OSPF modifications.
When Router RTB comes up and establishes links to Routers When Router RTB comes up and establishes links to Routers
RTC and RTD, it will flood the same information over both. RTC and RTD, it will flood the same information over both.
However, LSAs sent over the demand circuit (to Router RTC) However, LSAs sent over the demand circuit (to Router RTC)
will have the DoNotAge bit set, while those sent over the will have the DoNotAge bit set, while those sent over the
leased line to Router RTD will not. Because the DoNotAge bit leased line to Router RTD will not. Because the DoNotAge bit
is not taken into account when comparing LSA instances, the is not taken into account when comparing LSA instances, the
routers on the right side of RTB (RTC, RTE and RTD) may or routers on the right side of RTB (RTC, RTE and RTD) may or
may not have the DoNotAge bit set in the copies of the RTA may not have the DoNotAge bit set in their database copies
and RTB router-LSAs contained in their database. This of RTA's and RTB's router-LSAs. This depends on whether the
depends on whether the LSAs sent over the demand link reach LSAs sent over the demand link reach the routers before
the routers before those sent over the leased line. One those sent over the leased line. One possibility is pictured
possibility is pictured in Table 2. in Table 2.
+ +
+---+ | +---+ |
|RTC|--| + |RTC|--| +
+---+ | +---+ | +---+ | +---+ |
+ / |--|RTE|--| +--+ + / |--|RTE|--| +--+
+--+ | /ODL | +---+ |--|H2| +--+ | /ODL | +---+ |--|H2|
|H1|----| +---+ +---+/ | + +--+ |H1|----| +---+ +---+/ | + +--+
+--+ |--|RTA|-------|RTB| | +--+ |--|RTA|-------|RTB| |
| +---+ +---+\ | + | +---+ +---+\ | +
+ \ | +---+ | + \ | +---+ |
\ |--|RTY|--| \ |--|RTY|--|
+---+ | +---+ | +---+ | +---+ |
|RTD|--| + |RTD|--| +
+---+ | +---+ |
+ +
Figure 3: A sample internetwork. Figure 3: Example 2's internetwork.
Vertical lines are LAN segments. Six routers Vertical lines are LAN segments. Six routers
are pictured, Routers RTA-RTE and RTY. are pictured, Routers RTA-RTE and RTY.
RTB has three serial line interfaces, two of RTB has three serial line interfaces, two of
which are leased lines and the third (connecting to which are leased lines and the third (connecting to
RTC) a demand circuit. Two hosts, H1 and RTC) a demand circuit. Two hosts, H1 and
H2, are pictured to illustrate the effect of H2, are pictured to illustrate the effect of
application traffic. application traffic.
LS age LS age
LSA in RTC in RTD in RTE LSA in RTC in RTD in RTE
________________________________________________ ________________________________________________
RTA's Router-LSA DoNotAge+20 21 21 RTA's Router-LSA DoNotAge+20 21 21
RTB's Router-LSA DoNotAge+5 6 6 RTB's Router-LSA DoNotAge+5 6 6
Table 2: After Time T0, LS age fields Table 2: After Time T0 in Example 2, LS age
on the right side of Router RTB. fields on the right side of Router RTB.
LS age LS age
LSA in RTC in RTD in RTE LSA in RTC in RTD in RTE
_______________________________________________ _______________________________________________
RTA's Router-LSA 5 6 6 RTA's Router-LSA 5 6 6
RTB's Router-LSA DoNotAge+5 1785 1785 RTB's Router-LSA DoNotAge+5 1785 1785
Table 3: After Time T2, LS age fields Table 3: After Time T2 in Example 2, LS age
on the right side of Router RTB. fields on the right side of Router RTB.
LS age LS age
LSA in RTC in RTD in RTE LSA in RTC in RTD in RTE
_______________________________________________________ _______________________________________________________
RTA's Router-LSA 325 326 326 RTA's Router-LSA 325 326 326
RTB's Router-LSA DoNotAge+5 DoNotAge+6 DoNotAge+6 RTB's Router-LSA DoNotAge+5 DoNotAge+6 DoNotAge+6
Table 4: After Time T3, LS age fields Table 4: After Time T3 in Example 2, LS age
on the right side of Router RTB. fields on the right side of Router RTB.
LS age LS age
LSA in RTC in RTD in RTE LSA in RTC in RTD in RTE
_______________________________________________________ _______________________________________________________
RTA's Router-LSA DoNotAge+7 DoNotAge+8 DoNotAge+8 RTA's Router-LSA DoNotAge+7 DoNotAge+8 DoNotAge+8
RTB's Router-LSA DoNotAge+5 DoNotAge+6 DoNotAge+6 RTB's Router-LSA DoNotAge+5 DoNotAge+6 DoNotAge+6
Table 5: After Time T4, LS age fields Table 5: After Time T4 in Example 2, LS age
on the right side of Router RTB. fields on the right side of Router RTB.
Time T1: Underlying data-link connection is torn down. Time T1: Underlying data-link connection is torn down.
All application traffic is flowing over the leased line All application traffic is flowing over the leased line
connecting Routers RTB and RTD instead of the demand connecting Routers RTB and RTD instead of the demand
circuit, due to the leased line's lesser OSPF cost. After circuit, due to the leased line's lesser OSPF cost. After
some period of inactivity, the data-link connection some period of inactivity, the data-link connection
underlying the demand circuit will be torn down. This does underlying the demand circuit will be torn down. This does
not affect the OSPF database or the routers' routing tables. not affect the OSPF database or the routers' routing tables.
skipping to change at page 17, line 25 skipping to change at page 23, line 27
every LSRefreshInterval), Router RTB floods the refreshed every LSRefreshInterval), Router RTB floods the refreshed
LSA over the leased line but not over the demand circuit, LSA over the leased line but not over the demand circuit,
because the contents of the LSA have not changed. This new because the contents of the LSA have not changed. This new
LSA will not have the DoNotAge bit set, and will replace the LSA will not have the DoNotAge bit set, and will replace the
old instances (whether or not they have the DoNotAge bit old instances (whether or not they have the DoNotAge bit
set) by virtue of its higher LS Sequence number. This is set) by virtue of its higher LS Sequence number. This is
pictured in Table 3. pictured in Table 3.
Time T3: Leased line becomes inoperational. Time T3: Leased line becomes inoperational.
When the leased line becomes operational, the data-link When the leased line becomes inoperational, the data-link
connection underlying the demand circuit will be reopened, connection underlying the demand circuit will be reopened,
in order to flood a new (and changed) router-LSA for RTB and in order to flood a new (and changed) router-LSA for RTB and
also to carry the application traffic between Hosts H1 and also to carry the application traffic between Hosts H1 and
H2. At this point, all routers on the right side of the H2. After flooding the new LSA, all routers on the right
demand circuit will have DoNotAge set in their copy of RTB's side of the demand circuit will have DoNotAge set in their
router-LSA and DoNotAge clear in their copy of RTA's copy of RTB's router-LSA and DoNotAge clear in their copy of
router-LSA (see Table 4). RTA's router-LSA (see Table 4).
Time T4: In Router RTE, Router RTA's router-LSA times out. Time T4: In Router RTE, Router RTA's router-LSA times out.
Refreshes of Router RTA's router-LSA are not being flooded Refreshes of Router RTA's router-LSA are not being flooded
over the demand circuit. However, RTA's router-LSA is aging over the demand circuit. However, RTA's router-LSA is aging
in all of the routers to the right of the demand circuit. in all of the routers to the right of the demand circuit.
For this reason, the router-LSA will eventually be flushed For this reason, the router-LSA will eventually be aged out
(by router RTE in our example). Because this flushed LSA and reflooded (by router RTE in our example). Because this
constitutes a real change (see Section 3.4), it is flooded aged out LSA constitutes a real change (see Section 3.3), it
over the demand circuit from Router RTC to RTB. There are is flooded over the demand circuit from Router RTC to RTB.
then two possible scenarios. First, the LS Sequence numbers There are then two possible scenarios. First, the LS
for RTA's router-LSA may have diverged on either side of the Sequence number for RTA's router-LSA may be larger on RTB's
demand link. In this case, when router RTB receives the side of the demand link. In this case, when router RTB
flushed LSA it will respond by flooding back the more recent receives the flushed LSA it will respond by flooding back
instance (see Section 3.4). If instead the LS sequence the more recent instance (see Section 2.4). If instead the
numbers are the same, the flushed LSA will be flooded all LS sequence numbers are the same, the flushed LSA will be
the way back to Router RTA, which will then be forced to flooded all the way back to Router RTA, which will then be
reoriginate the advertisement. forced to reoriginate the LSA.
In any case, after a small period all the routers on the In any case, after a small period all the routers on the
right side of the demand link will have the DoNotAge bit set 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 in their copy of RTA's router-LSA (see Table 5). In the
small interval between the flushing and waiting for a new small interval between the flushing and waiting for a new
instance of the LSA, there will be a temporary loss of instance of the LSA, there will be a temporary loss of
connectivity between Hosts H1 and H2. connectivity between Hosts H1 and H2.
Time T5: A non-supporting router joins. Time T5: A non-supporting router joins.
Suppose Router RTY now becomes operational, and does not Suppose Router RTY now becomes operational, and does not
support the demand circuit OSPF extensions. Router RTY's support the demand circuit OSPF extensions. Router RTY's
router-LSA then does not have the DC-bit set in its Options router-LSA then will not have the DC-bit set in its Options
field, and as the router-LSA is flooded throughout the field, and as the router-LSA is flooded throughout the
internetwork it flushes all LSAs having the DoNotAge bit set internetwork it flushes all LSAs having the DoNotAge bit set
and causes the flooding behavior over the demand circuit to and causes the flooding behavior over the demand circuit to
revert back to the normal flooding behavior defined in [1]. revert back to the normal flooding behavior defined in [1].
However, although all LSAs will now be flooded over the However, although all LSAs will now be flooded over the
demand circuit, regardless of whether their contents have demand circuit, regardless of whether their contents have
really changed, Hellos will still continue to be suppressed really changed, Hellos will still continue to be suppressed
on the demand circuit (see Section 3.2). on the demand circuit (see Section 3.2.2).
4.3. Example 3: Operation when suffering SVC shortage 4.3. Example 3: Operation when oversubscribed
Figure 4 shows a single Router (RT1) connected via demand Figure 4 shows a single Router (RT1) connected via demand
circuits to three other routers (RT2-RT4). Assume that RT1 can circuits to three other routers (RT2-RT4). Assume that RT1 can
only have two out of three underlying data-link connections open only have two out of three underlying data-link connections open
at once. This may be due to one of the following reasons. at once. This may be due to one of the following reasons:
Router RT1 may be using a single Primary rate ISDN interface (2 Router RT1 may be using a single Basic Rate ISDN interface (2 B
B channels) to support all three demand circuits. Or, RT1 may be channels) to support all three demand circuits, or, RT1 may be
connected a data-link switch (e.g., X.25 or Frame relay) that is connected a data-link switch (e.g., X.25 or Frame relay) that is
only capable of so many simultaneous data-link connections. only capable of so many simultaneous data-link connections.
The following events may transpire, starting with Router RT1 The following events may transpire, starting with Router RT1
coming up. coming up.
Time T0: Router RT1 comes up. Time T0: Router RT1 comes up.
Router RT1 attempts to establish neighbor connections and Router RT1 attempts to establish neighbor connections and
synchronize OSPF databases with routers RT2-RT4. But, synchronize OSPF databases with routers RT2-RT4. But,
because it cannot have data-link connections open to all because it cannot have data-link connections open to all
three at once, it will synchronize with RT2 and RT3, while three at once, it will synchronize with RT2 and RT3, while
Hellos sent to RT4 will be discarded (see Section 1). Hellos sent to RT4 will be discarded (see Section 1).
Time T1: Data-link connection to RT2 closed due to inactivity. Time T1: Data-link connection to RT2 closed due to inactivity.
Assuming that no application traffic is being sent to/from Assuming that no application traffic is being sent to/from
Host H3, the underlying data-link connection to RT2 will Host H3, the underlying data-link connection to RT2 will
eventually close due to inactivity. Then, the next Hello eventually close due to inactivity. Then, the next Hello
+ +--+ + +--+
+---+ |--|H3| +---+ |--|H3|
+---------|RT2|--| +--+ +---------|RT2|--| +--+
/ +---+ | / +---+ |
/ ODL + / ODL +
+--+ + / +--+ + /
|H1|--| / + |H1|--| / +
+--+ | +---+ ODL +---+ | +--+ | +---+ ODL +---+ | +--+
|--|RT1|------------|RT3|--| |--|RT1|------------|RT3|--|--|H4|
| +---+ +---+ | | +---+ +---+ | +--+
| \ + | \ +
+ \ODL + \ODL
\ + +--+ \ + +--+
\ +---+ |--|H2| \ +---+ |--|H2|
+--------|RT4|--| +--+ +--------|RT4|--| +--+
+---+ | +---+ |
+ +
Figure 4: Behavior when not all Figure 4: Example 3's internetwork.
of the demand circuits' data-
link connections can be opened
at once.
that RT1 attempts to send to RT4 will cause that data-link that RT1 attempts to send to RT4 will cause that data-link
connection to open and synchronization with RT4 will ensue. connection to open and synchronization with RT4 will ensue.
Note that, until this time, H2 will be considered Note that, until this time, H2 will be considered
unreachable by OSPF routing. However, data traffic would not unreachable by OSPF routing. However, data traffic would not
have been deliverable to H2 until now in any case. have been deliverable to H2 until now in any case.
Time T2: RT2's LAN interface becomes inoperational Time T2: RT2's LAN interface becomes inoperational
This causes RT2 to reissue its router-LSA. However, it may This causes RT2 to reissue its router-LSA. However, it may
be unable to flood it to RT1 if RT1 already has data-link be unable to flood it to RT1 if RT1 already has data-link
connections opened to RT3 and RT4. While the data-link connections open to RT3 and RT4. While the data-link
connection from RT2 to RT1 cannot be opened due to resource connection from RT2 to RT1 cannot be opened due to resource
shortages, the new router-LSA will be continually shortages, the new router-LSA will be continually
retransmitted (and dropped by RT2's ISDN interface; see the retransmitted (and dropped by RT2's ISDN interface; see
last paragraph of Section 1). This means that the routing Section 1). This means that the routers RT1, RT3 and RT4
will not detect the unreachability of H4 until a data-link will not detect the unreachability of Host H3 until a data-
connection on RT1 becomes available. link connection on RT1 becomes available.
Increasing the OSPF cost of demand circuits that are currently
discarding application packets, due to underlying data-link
shortage, may help the routing find paths that can actually
deliver the packets. This however would create more routing
traffic, and is an issue for future study.
5. Topology recommendations 5. Topology recommendations
Because LSAs indicating topology changes are still flooded over Because LSAs indicating topology changes are still flooded over
demand circuits, it is still advantageous to design networks so that demand circuits, it is still advantageous to design networks so that
the demand circuits are isolated from as many topology changes as the demand circuits are isolated from as many topology changes as
possible. In OSPF, this is done by encasing the demand circuits possible. In OSPF, this is done by encasing the demand circuits
within OSPF stub areas or within NSSAs (see [3]). In both cases, within OSPF stub areas or within NSSAs (see [3]). In both cases,
this isolates the demand circuits from AS external routing changes, this isolates the demand circuits from AS external routing changes,
which in many networks are the most frequent (see [6]). Stub areas which in many networks are the most frequent (see [6]). Stub areas
can even isolate the demand circuits from changes in other OSPF can even isolate the demand circuits from changes in other OSPF
areas. areas.
Also, considering the interoperation of OSPF routers supporting Also, considering the interoperation of OSPF routers supporting
demand circuits and those that do not (see Section 2.3), isolated demand circuits and those that do not (see Section 2.5), isolated
stub areas or NSSAs can be converted independently to support demand stub areas or NSSAs can be converted independently to support demand
circuits. In contrast, regular OSPF areas must all be converted circuits. In contrast, regular OSPF areas must all be converted
before the functionality can take effect in any particular regular before the functionality can take effect in any particular regular
OSPF area. OSPF area.
6. Lost functionality 6. Lost functionality
The enhancements defined in this memo to support demand circuits The enhancements defined in this memo to support demand circuits
come at some cost. Although we gain an efficient use of demand come at some cost. Although we gain an efficient use of demand
circuits, holding them open only when there is actual application circuits, holding them open only when there is actual application
skipping to change at page 20, line 43 skipping to change at page 26, line 35
Robustness Robustness
In regular OSPF [1], all LSAs are refreshed every In regular OSPF [1], all LSAs are refreshed every
LSRefreshInterval. This provides protection against routers LSRefreshInterval. This provides protection against routers
losing LSAs from (or LSAs getting corrupted in) their link state losing LSAs from (or LSAs getting corrupted in) their link state
databases due to software errors, etc. Over demand circuits databases due to software errors, etc. Over demand circuits
this periodic refresh is removed, and we depend on routers this periodic refresh is removed, and we depend on routers
correctly holding LSAs marked with DoNotAge in their databases correctly holding LSAs marked with DoNotAge in their databases
indefinitely. indefinitely.
Database Checksum Database Checksum
OSPF supplies network management variables, OSPF supplies network management variables, namely
ospfExternLSACksumSum and ospfAreaLSACksumSum in [7], allowing a ospfExternLSACksumSum and ospfAreaLSACksumSum in [7], allowing a
network management station to verify OSPF database network management station to verify OSPF database
synchronization among routers. However, these variables are sums synchronization among routers. However, these variables are sums
of the individual LSAs' LS checksum fields, which are no longer of the individual LSAs' LS checksum fields, which are no longer
guaranteed to be identical across demand circuits (because the guaranteed to be identical across demand circuits (because the
LS checksum covers the LS Sequence Number, which will in general LS checksum covers the LS Sequence Number, which will in general
differ across demand circuits). This means that these variables differ across demand circuits). This means that these variables
can no longer be used to verify database synchronization in OSPF can no longer be used to verify database synchronization in OSPF
networks containing demand circuits. networks containing demand circuits.
A. The Options field 7. Future work: Oversubscription
An internetwork is oversubscribed when not all of its demand
circuits' underlying connections can be open at once, due to
resource limitations. These internetworks were addressed in Section
4.3. However, when all possible sources in the internetwork are
+--+ + + +--+
|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 connections
active at once, problems can occur which are not addressed in this
memo:
(1) There is a network design problem. Does a subset of demand
circuits exist such that a) their data-link connections can be
open simultaneously and b) they can provide connectivity for all
possible sources? This requires that (at least) a spanning tree
be formed out of established connections. Figure 4 shows an
example where this is not possible; Hosts H1 through H4 cannot
simultaneously talk, since Router RT1 is limited to two
simultaneously open demand circuits.
(2) Even if it is possible that a spanning tree can form, will one?
Given the model in Section 1, demand circuits are brought up
when needed for data traffic, and stay established as long as
data traffic is present. One example is shown in Figure 5. Four
routers are interconnected via demand circuits, with each router
being able to establish a circuit to any other. However, we
assume that each router can only have two circuits open at once
(e.g., the routers could be using Basic Rate ISDN). In this
case, one would hope that the data-link connections in Figure 5a
would form. But the connections in Figure 5b are equally
likely, which leave Host H2 unable to communicate.
One possible approach to this problem would be for a) the OSPF
database to indicate which demand circuits have actually been
established and b) implement a distributed spanning tree
construction (see for example Chapter 5.2.2 of [9]) when
necessary.
(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 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.
On possible approach to this problem is to increase the OSPF
cost of demand circuits that are currently discarding
application packets (i.e., can't be established) due to resource
shortages. This may help the routing find paths that can
actually deliver the packets. On the downside, it would create
more routing traffic. Also, unwanted routing oscillations may
result when you start varying routing metrics to reflect dynamic
network conditions; see [10].
A. Format of the OSPF Options field
The OSPF Options field is present in OSPF Hello packets, Database The OSPF Options field is present in OSPF Hello packets, Database
Description packets and all LSAs. The Options field enables OSPF Description packets and all LSAs. The Options field enables OSPF
routers to support (or not support) optional capabilities, and to routers to support (or not support) optional capabilities, and to
communicate their capability level to other OSPF routers. Through communicate their capability level to other OSPF routers. Through
this mechanism routers of differing capabilities can be mixed within this mechanism routers of differing capabilities can be mixed within
an OSPF routing domain. an OSPF routing domain.
The memo defines one of the Option bits: the DC-bit (for Demand The memo defines one of the Option bits: the DC-bit (for Demand
Circuit capability). The DC-bit is set in a router's router-LSA if Circuit capability). The DC-bit is set in a router's self-originated
and only if it supports the functionality defined in Section 3 of LSAs if and only if it supports the functionality defined in Section
this memo. Note that this does not necessarily mean that the router 2 of this memo. Note that this does not necessarily mean that the
can be the endpoint of a demand circuit, but only that it can 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 properly process LSAs having the DoNotAge bit set. In contrast, the
DC-bit is set in Hello Packets and Database Description Packets sent 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 out an interface if and only if the router wants to treat the
attached network as a demand circuit (see Section 3.1). 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 The addition of the DC-bit makes the current assignment of the OSPF
Options field as follows: Options field as follows:
+------------------------------------+ +------------------------------------+
| * | * | DC | EA | N/P | MC | E | T | | * | * | DC | EA | N/P | MC | E | T |
+------------------------------------+ +------------------------------------+
Figure 5: The OSPF Options field Figure 5: The OSPF Options field
skipping to change at page 23, line 8 skipping to change at page 30, line 9
This bit describes the handling of Type-7 LSAs, as specified in This bit describes the handling of Type-7 LSAs, as specified in
[3]. [3].
EA-bit EA-bit
This bit describes the router's willingness to receive and This bit describes the router's willingness to receive and
forward External Attributes LSAs, as specified in [5]. forward External Attributes LSAs, as specified in [5].
DC-bit DC-bit
This bit describes the handling of demand circuits, as specified This bit describes the handling of demand circuits, as specified
in this memo. Its setting in Hellos and Database Description in this memo. Its setting in Hellos and Database Description
Packets is described in Section 3.1. Its setting in LSAs is Packets is described in Sections 3.2.1 and 3.2.2. Its setting in
described in Section 2.3. LSAs is described in Sections 2.1 and 2.5.
B. Configurable Parameters B. Configurable Parameters
This memo defines a single additional configuration parameter for This memo defines a single additional configuration parameter for
OSPF interfaces. In addition, the OSPF Interface configuration OSPF interfaces. In addition, the OSPF Interface configuration
parameter PollInterval, previously used only on NBMA networks, is parameter PollInterval, previously used only on NBMA networks, is
now also used on point-to-point networks (see Section 3.3). now also used on point-to-point networks (see Sections 3.1 and
3.2.2).
DemandInterface DemandInterface
Indicates whether the interface connects to a demand circuit. Indicates whether the interface connects to a demand circuit.
When set to TRUE, the procedures described in Section 3 of this When set to TRUE, the procedures described in Section 3 of this
memo are followed, in order to send a minimum of routing traffic memo are followed, in order to send a minimum of routing traffic
over the demand circuit. On point-to-point networks, this allows over the demand circuit. On point-to-point networks, this allows
the circuit to be closed when not carrying application traffic. the circuit to be closed when not carrying application traffic.
When the demand interface is configured to be a broadcast or When a broadcast or NBMA network is configured to be a demand
NBMA network (see Section 1.2 of [1]), the circuit will be kept interface (see Section 1.2 of [1]), the circuit will be kept
open constantly due to OSPF Hello traffic, but the amount of open constantly due to OSPF Hello traffic, but the amount of
flooding traffic will still be greatly reduced. flooding traffic will still be greatly reduced.
C. Architectural Constants C. Architectural Constants
This memo defines a single additional OSPF architectural constant. This memo defines a single additional OSPF architectural constant.
DoNotAge DoNotAge
Equal to the hexadecimal value 0x8000, or the high bit of the Equal to the hexadecimal value 0x8000, which is the high bit of
16-bit LS Age field in OSPF LSAs. When this bit is set in the LS the 16-bit LS Age field in OSPF LSAs. When this bit is set in
age field, the LSA is not aged as it is held in the router's the LS age field, the LSA is not aged as it is held in the
link state database. This allows the elimination of the periodic router's link state database. This allows the elimination of the
LSA refresh over demand circuits. See Section 2.1 for more periodic LSA refresh over demand circuits. See Section 2.2 for
information on processing the DoNotAge bit. more information on processing the DoNotAge bit.
References References
[1] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994. [1] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994.
[2] Meyer, G., "Extensions to RIP to Support Demand Circuits", RFC [2] Meyer, G., "Extensions to RIP to Support Demand Circuits", RFC
1582, Spider Systems, February 1994. 1582, Spider Systems, February 1994.
[3] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, [3] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587,
RainbowBridge Communications, Stanford University, March 1994. RainbowBridge Communications, Stanford University, March 1994.
[4] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, [4] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon,
Inc., March 1994. Inc., March 1994.
[5] Ferguson, D., "The OSPF External Attributes LSA", Internet [5] Ferguson, D., "The OSPF External Attributes LSA", work in
Draft, draft-ietf-ospf-extattr-00.txt, March 1993. progress.
[6] Moy, J., editor, "OSPF protocol analysis", RFC 1245, Proteon, [6] Moy, J., editor, "OSPF protocol analysis", RFC 1245, Proteon,
Inc., July 1991. Inc., July 1991.
[7] Baker F. and R. Coltun, "OSPF Version 2 Management Information [7] Baker F. and R. Coltun, "OSPF Version 2 Management Information
Base", RFC 1253, ACC, University of Maryland, August 1991. Base", RFC 1253, ACC, University of Maryland, August 1991.
[8] Baker F., "OSPF Point-to-MultiPoint Interface", Internet Draft, [8] Baker F., "OSPF Point-to-MultiPoint Interface", work in
draft-ietf-ospf-pmp-if-00.txt, ACC, March 1994. progress.
[9] Bertsekas, D. and Gallager R., "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 Considerations
Security issues are not discussed in this memo. Security issues are not discussed in this memo.
Author's Address Author's Address
John Moy John Moy
Proteon, Inc. Cascade Communications Corp.
9 Technology Drive 5 Carlisle Road
Westborough, MA 01581 Westford, MA 01886
Phone: 508-898-2800 Phone: 508-692-2600 Ext. 394
Fax: 508-898-3176 Fax: 508-692-9214
Email: jmoy@proteon.com Email: jmoy@casc.com
This document expires in November 1994. This document expires in May 1995.
 End of changes. 101 change blocks. 
386 lines changed or deleted 764 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/