Network Working Group                                             J. Moy
Internet Draft                                             Proteon, Inc.                                                   Cascade
Expiration Date: November 1994 May 1995                                  November 1994
File name: draft-ietf-ospf-demand-00.txt draft-ietf-ospf-demand-01.txt

               Extending OSPF to support demand circuits

Status of this Memo

    This document is an Internet-Draft.  Internet-Drafts are working
    documents of the Internet Engineering Task Force (IETF), its areas,
    and its working groups.  Note that other groups may also distribute
    working documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months.  Internet-Drafts
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is not appropriate inappropriate to use
    Internet-Drafts Internet- Drafts as
    reference material or to cite them other than as
    a "working draft" or "work in progress".

    To learn the current status of any Internet-Draft, please check the
    1id-abstracts.txt
    "1id-abstracts.txt" listing contained in the Internet-Drafts Internet- Drafts Shadow
    Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, ds.internic.net (US East Coast), nic.nordu.net
    (Europe), ftp.isi.edu (US West Coast), or
    munnari.oz.au. munnari.oz.au (Pacific
    Rim).

Abstract

    This memo defines enhancements to the OSPF protocol that allow
    efficient operation over "demand circuits". Demand circuits are
    those
    network segments whose costs vary with usage; charges can be based
    both on connect time and on bytes/packets transmitted. Examples of such
    demand circuits include ISDN circuits, X.25 SVCs, and dial-up lines.
    The periodic nature of OSPF routing traffic (as defined in [1]) requires
    such circuits has until now required a
    demand circuit's underlying data-link connection to be open constantly, constantly
    open, resulting in unwanted usage charges. With the modifications
    described herein, OSPF Hellos and the refresh of OSPF routing
    information are suppressed, allowing suppressed on demand circuits circuits, allowing the
    underlying data-link connections to be closed when not carrying
    application traffic.

    Demand circuits and regular network segments (e.g., leased lines)
    are allowed to be combined in any manner. In other words, there are
    no topological restrictions on the demand circuit support. However,
    while any OSPF network segment can be defined as a demand circuit,
    only point-to-point networks receive the full benefit. When
    broadcast and NBMA networks are declared demand circuits, routing
    update traffic is reduced but the periodic sending of Hellos is not,
    which in effect still requires that the data-link circuits connections be
    constantly open.

    While mainly intended for use with cost-conscious network links such
    as ISDN, X.25 and dial-up, the modifications in this memo may also
    prove useful over bandwidth-limited network links such as slow-speed
    leased lines and packet radio.

    The enhancements defined in this memo are backward-compatible with
    the OSPF specification defined in [1], and with the OSPF extensions
    defined in [3] (OSPF NSSA areas), [4] (MOSPF) and [8] (OSPF Point-
    to-MultiPoint Interface).

    This memo provides functionality comparable to that specified for
    RIP in [2]. However, because OSPF is a employs link-state routing protocol
    rather than a
    technology as opposed to RIP's Distance Vector protocol, base, the mechanisms
    used to achieve that the functionality are quite different.

    Please send comments to ospf@gated.cornell.edu.

Acknowledgments

    The author would like to acknowledge the helpful comments of Fred
    Baker, Rob Coltun, Dawn Li, Gerry Meyer, and Tom Pusateri. Pusateri and Zhaohui
    Zhang. This memo is a product of the OSPF Working Group.

Table of Contents

    1       Model for demand circuits .............................. 4
    2       Modifications to all OSPF routers ...................... 4 5
    2.1     The OSPF Options field ................................. 5
    2.2     The LS age field ....................................... 5
    2.2
    2.3     Removing old, non-aging stale DoNotAge LSAs ........................... 6
    2.3
    2.4     A change to the flooding algorithm ..................... 7
    2.5     Interoperability with unmodified OSPF routers .......... 6 8
    2.5.1   Indicating across area boundaries ...................... 9
    2.5.1.1 Limiting indication-LSA origination ................... 10
    3       Modifications to demand circuit endpoints .............. 7 ............. 11
    3.1     Configuring demand circuits ............................ 7     Interface State machine modifications ................. 11
    3.2     Sending and Receiving OSPF Hellos ...................... 8
    3.3     Interface State ..................... 11
    3.2.1   Negotiating Hello suppression ......................... 12
    3.2.2   Neighbor state machine modifications .................. 8
    3.4 12
    3.3     Flooding over demand circuits .......................... 9 ......................... 13
    3.4     Virtual link support .................................. 14
    3.5     Point-to-MultiPoint Interface support ................. 15
    4       Examples .............................................. 10 16
    4.1     Example 1: Sole connectivity through demand circuits .. 10 16
    4.2     Example 2: Demand and non-demand circuits in parallel . 14 20
    4.3     Example 3: Operation when suffering SVC shortage ...... 18 oversubscribed .............. 24
    5       Topology recommendations .............................. 20 25
    6       Lost functionality .................................... 20 26
    7       Future work: Oversubscription ......................... 26
    A       The       Format of the OSPF Options field ..................................... 22 ...................... 29
    B       Configurable Parameters ............................... 23 30
    C       Architectural Constants ............................... 23 30
            References ............................................ 24 31
            Security Considerations ............................... 24 31
            Author's Address ...................................... 24 31

1.  Model for demand circuits

    In this memo, demand circuits refer to those network segments whose
    cost depends on either connect time or on and/or usage (expressed in terms
    of bytes or packets). Examples include ISDN circuits and X.25 SVCs.
    On these circuits, it is desirable for a routing protocol to send as
    little routing traffic as possible. In fact, when there is no change
    in network topology it is desirable for a routing protocol to send
    no routing traffic at all; this allows the underlying data-link
    connection to be closed when not needed for application data
    traffic.

    The model used within this memo for the maintenance of demand
    circuits is as follows. If there is no data to send (either routing
    protocol traffic or application data), the data-link connection
    remains closed.  As soon as there is data to be sent, an attempt to
    open the data-link connection is made (e.g., an ISDN or X.25 call is
    placed). If When/if the data-link connection is successful, established, the data
    is sent, and the
    circuit connection stays open until some period of time
    elapses without more data to send. At this point the data-link
    connection is again closed, in order to conserve cost and resources
    (see Section 1 of [2]).

    The "Presumption of Reachability" described in [2] is also used.
    Even though a circuit's data-link connection may be closed at any
    particular time, it is assumed by the routing layer (i.e., OSPF)
    that it the circuit is available unless other information, such as a
    discouraging diagnostic code resulting from an attempted data-link
    connection, is present.

    It may be possible that a data-link connection cannot be opened established
    due to resource shortages. For example, a router with a single basic
    rate ISDN interface cannot open more than two simultaneous ISDN
    data-link connections (one for each B channel), and limitations in
    interface firmware and/or switch capacity may limit the number of
    X.25 SVCs simultaneously supported. When a router cannot
    simultaneously open all of its circuits' underlying data-link
    connections due to resource limitations, we say that the router is
    oversubscribed. In these cases, datagrams to be forwarded out these the
    (temporarily unopenable) data-link connections are discarded,
    instead of being queued. Note also that this temporary inability to
    open data-link connections due to oversubscription is NOT reported
    by the OSPF routing system as unreachability; see Section 4.3 for
    more information.

    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

    While most of the modifications to support demand circuits are
    isolated to the demand circuit endpoints, endpoints (see Section 3), there are
    changes required of all OSPF routers. These changes are described in
    the subsections below. Routers implementing these changes set the DC-bit in

    2.1.  The OSPF Options field

        A new bit is added to the
    options OSPF Options field of their router-LSA (see Section 2.3 and 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),
    even if they do not implement
        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 described in used to convey across area boundaries the
        existence of routers incapable of DoNotAge processing; see
        Section
    3.

    2.1. 2.5.1 for details.

    2.2.  The LS age field

        The semantics of the LSA's LS age field are changed, allowing
        the high bit (DoNotAge; see Appendix C) to be set. Previously
        the LS age field could not exceed the value of MaxAge. This bit is called "DoNotAge"; see
        Appendix C for its formal definition. LSAs whose LS age field
        have the DoNotAge bit set are not aged while they are held in
        the link state database, which means that they do not have to be
        refreshed every LSRefreshInterval as is done with all other OSPF
        LSAs.

        By convention, in the rest of this memo we will express LS age
        fields having the DoNotAge set as "DoNotAge+x", while an LS age
        expressed as just "x" is assumed not to not have the DoNotAge bit
        set. LSAs having DoNotAge set are also sometimes referred to as
        "DoNotAge LSAs".

        When comparing two LSA instances to see which one is most
        recent, the two LSAs' LS age fields are compared whenever the LS
        sequence numbers and LS checksums are found identical (see
        Section 13.1 of [1]). Before comparing, the LS age fields should must
        have their DoNotAge bits masked off.  For example, in
        determining which LSA is more recent, LS ages of 1 and
        DoNotAge+1 should be are considered equivalent; an LSA flooded with LS age
        of 1 may be acknowledged with a Link State Acknowledgement
        listing an LS age of DoNotAge+1, or vice versa.
        As a special case, In particular,
        DoNotAge+MaxAge is equivalent to MaxAge, and
        either MaxAge; however for backward-
        compatibility the MaxAge form can should always be used to flush when
        flushing LSAs from the routing domain (see Section 14.1 of [1]).

        Thus, the set of allowable values for the LS age field fall into
        the two ranges: 0 through MaxAge and DoNotAge through
        DoNotAge+MaxAge.  (Previously the LS age field could not exceed
        the value of MaxAge.) Any LS age field not falling into these
        two ranges should be considered to be equal to MaxAge.

        When an LSA is flooded out a non-demand 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, at which time 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. Flooding out
        demand interfaces is covered in Section 3.4.

        Thus, the set of allowable values for the LS age field fall into
        the two ranges: 0 through MaxAge and DoNotAge through
        DoNotAge+MaxAge. Any LS age field not falling into these two
        ranges should be considered to be equal to MaxAge.

        The LS age field is not checksum protected. Errors in a router's
        memory may mistakenly set an LSA's DoNotAge bit, stopping the
        aging of the LSA. However, a router should note that its own
        self-originated LSAs should never have the DoNotAge bit set in
        its own database. This means that in any case the router's
        self-originated LSAs will be refreshed every LSRefreshInterval.
        As this refresh is flooded throughout the OSPF routing domain,
        it will replace any LSA copies in other routers' databases whose
        DoNotAge bits were mistakenly set.

    2.2.

    2.3.  Removing old, non-aging stale DoNotAge LSAs

        Because LSAs with the DoNotAge bit set are never aged, they can
        stay in the link state database even when the originator of the
        LSA no longer exists. To ensure that these LSAs are eventually
        flushed from the routing domain, and that the size of the link
        state database doesn't grow without bound, routers are required
        to flush an a DoNotAge LSA if both of the following conditions are
        met:

        (1) The LSA has been in the router's database for at least
            MaxAge seconds.

        (2) The originator of the LSA has been unreachable (according to
            the routing calculations specified by Section 16 of [1]) for the time MaxAge.
            at least MaxAge seconds.

        For an example, see Time T8 in the example of Section 4.1. This Note
        that the above functionality is an exception to the general OSPF
        rule that a router can only flush (i.e., prematurely age; see
        Section 14.1 of [1]) its own self-originated LSAs. The above
        functionality pertains only to DoNotAge LSAs. An LSA having
        DoNotAge clear still can be prematurely aged only by its
        originator; otherwise, the LSA must age naturally to MaxAge
        before being removed from the routing domain.

        An interval as long as MaxAge has been chosen to avoid any
        possibility of thrashing (i.e., flushing an advertisement LSA only to have it
        reoriginated soon afterwards).

    2.3.  Interoperability with unmodified OSPF routers

        Unmodified OSPF routers will probably treat LSAs with Note that by the above rules, a
        DoNotAge bit set as if they had LS age of MaxAge. At the very
        worst, this LSA will cause continual retransmissions of LSAs with be removed from the routing domain no faster
        than if it were being aged naturally (i.e., if DoNotAge bit set.

        However, were not
        set).

    2.4.  A change to avoid this confusion, advertisements with DoNotAge
        set will be allowed in an OSPF area only if, in the area's link
        state database, all router-LSAs and type-4-summary-LSAs
        (location of ASBRs) have their DC-bit set (indicating their
        ability to process DoNotAge). Note that it flooding algorithm

        The following change is not required that made to the LSAs' Advertising Router OSPF flooding algorithm.
        When a Link State Update Packet is reachable; if any received that contains an LSA
        instance which is found
        not having its DC-bit set (regardless of reachability), then actually less recent than the
        router should flush from the area all advertisements having
        DoNotAge set; this is an exception to router's
        current database copy, the general OSPF rule that
        a router can only flush must now respond by sending
        its own self-originated LSAs. database copy (encapsulated in a Link State Update Packet)
        back to the sending neighbor. When
        flushing, doing so, the LSAs' LS age field should be set to MaxAge and not
        DoNotAge+MaxAge.

        (As an implementation suggestion, a new variable "DCBitLessLSAs"
        could be LSA is NOT
        added to the OSPF area data structure in Section 6 of
        [1]. This variable would count neighbor's link state retransmission list. The
        previous behavior was to ignore the number flood of the area's router-
        LSAs and type-4-summary-LSAs that do not have the DC-bit set.

        This variable would potentially increment/decrement any time a
        new LSA was received or an old less recent LSA was replaced or flushed.)

        In particular, AS-external-LSAs with the DoNotAge bit set cannot
        exist
        instance; see Step 8 of Section 13 in the routing domain unless all routers [1].

        This change is necessary to support flooding over demand
        circuits. For example, see Time T4 in all "regular
        OSPF areas" (all areas that are neither stub areas nor NSSAs)
        are capable the example of processing DoNotAge. In order to convey Section
        4.2.

        However, this
        information across area boundaries, area border routers must set change is beneficial when flooding over non-demand
        interfaces as well. For this reason, the DC-bit flooding change
        pertains to all interfaces, not just interfaces to demand
        circuits. The main example involves MaxAge LSAs. There are times
        when MaxAge LSAs stay in a type-4-summary-LSA that router's database for extended
        intervals: 1) when they originate if and
        only if the described ASBR has the DC-bit set in its original
        router-LSA.  Additionally, sometimes are stuck in may be necessary to
        convey across areas the the existence of a non-ASBR that cannot
        process DoNotAge. In this case, retransmission queue on a type-4-summary-LSA should be
        originated with cost of LSInfinity and DC-bit clear.

3.  Modifications
        slow link or 2) when a router is not properly flushing them from
        its database, due to demand circuit endpoints software bugs. The following subsections detail the modifications required prolonged existence of
        these MaxAge LSAs can inhibit the
    routers at the endpoints of demand circuits. This consists flooding of
    modifications to two main pieces new instances of OSPF: 1) sending and receiving
    hellos over demand circuits and 2) flooding LSAs over demand
    circuits.

    3.1.  Configuring demand circuits

        An additional OSPF interface configuration parameter,
        DemandInterface, is defined to indicate whether an OSPF
        interface connects to a demand circuit (see Appendix B). On
        point-to-point demand circuits, the neighboring router must
        agree that the point-to-point link is a demand circuit. To
        ensure this agreement,
        the router sets LSA. New instances typically start with the DC-bit in OSPF Hellos initial LS
        sequence number, and are treated as less recent (and Database Description Packets) sent out hence
        discarded) by routers still holding MaxAge instances. However,
        with the demand
        interface. Receiving an Hello or above change to flooding, a Database Description Packet router with the DC-bit set indicates agreement. Receiving an Hello a MaxAge
        instance will respond back with the DC-bit clear MaxAge instance. This will
        get back to the LSA's originator, which will then pick the next
        highest LS sequence number and also listing reflood, overwriting the router's Router ID MaxAge
        instance.

        This change will be included in the
        body future revisions of the Hello message, or a Database Description Packet base
        OSPF specification [1].

    2.5.  Interoperability with
        the DC-bit clear (either one indicating bidirectional
        connectivity) indicates that the other end refuses to unmodified OSPF routers

        Unmodified OSPF routers will probably treat DoNotAge LSAs as if
        they had LS age of MaxAge. At the
        link as a demand circuit. In these cases, the router reverts to
        treating very worst, this will cause
        continual retransmissions of the DoNotAge LSAs. (An example
        scenario follows. Suppose Routers A and B are connected by a
        point-to-point link. Router A implements the demand circuit
        extensions, Router B does not. Neither one treats their
        connecting link as a leased line.

        The above procedure indicates that a demand point-to-point
        circuit need be configured circuit. At some point in only one of the two endpoints (see
        Section 4.1).

        If the negotiation fails, and the router time,
        Router A receives from another neighbor via flooding a DoNotAge
        LSA. The DoNotAge LSA is forced then flooded by Router A to treat the
        line Router B.
        Router B, not understanding DoNotAge LSAs, treats it as a leased line, the router can always renegotiate the
        link's demand status whenever the link goes down. For example,
        if MaxAge
        LSA and acknowledges it as such to Router A. Router A receives
        the neighboring router is rebooted with software acknowledgment, but notices that the acknowledgment is
        capable of operating over demand circuits, for a future negotiation
        different instance, and so starts retransmitting the LSA.)

        However, to avoid this confusion, DoNotAge LSAs will succeed.

        For more information on sending be allowed
        in an OSPF Hellos over demand
        circuits, see Section 3.2.

    3.2.  Sending area if and Receiving OSPF Hellos

        Over point-to-point demand circuits OSPF Hello packets are sent only until initial link-state database synchronization is
        achieved with the neighbor (i.e., if, in the area's link state of
        database, all LSAs have the neighbor
        connection reaches "Full", as defined DC-bit set in their Options field
        (see Section 10.1 of [1]).
        After this, Hellos are suppressed and 2.1). Note that it is not required that the data-link connection
        to the neighbor is assumed available until evidence LSAs'
        Advertising Router be reachable; if any LSA is received
        to the contrary. When found not having
        its DC-bit set (regardless of reachability), then the router finds that the neighbor is no
        longer available, presumably
        should flush (i.e., prematurely age; see Section 14.1 of [1])
        from something like a diagnostic
        code contained 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 response router can only flush its own
        self-originated LSAs. Both changes pertain only to DoNotAge
        LSAs, and in both cases a failed call request, the
        neighbor connection transitions back flushed LSA's LS age field should be
        set to "Down" MaxAge and Hellos not DoNotAge+MaxAge.

        2.5.1.  Indicating across area boundaries

            AS-external-LSAs are
        sent periodically (at Intervals 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 PollInterval)
            DoNotAge processing exists in any "regular" area (i.e., an attempt
            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 restart synchronization with the neighbor.

        This requires changes following rule: LSAs in regular OSPF
            areas are allowed to have DoNotAge set if and only if every
            router in the OSPF Neighbor State Machine (see
        Section 10.3 domain (excepting those in stub areas and
            NSSAs) is capable of [1]). DoNotAge processing. The receipt rest of Hellos from neighbors in
        state "Loading" or higher cannot be required. In other words, this
            section describes how the InactivityTimer event defined rule is implemented.

            As described above in Section 10.2 of [1] has no
        effect on neighbors in state "Loading" or higher.  An additional
        clarification Sections 2.1 and 2.5, a router
            indicates that it is needed in the Neighbor State Machine's LLDown
        event. This event should be mapped into capable of DoNotAge processing by
            setting the "discouraging
        diagnostic code" discussed above DC-bit 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 LSAs that have been configured
        as demand circuits, it originates. However,
            there is no change a problem. It is possible that, in all areas to
            which Router X directly attaches, all the sending and
        receiving of Hellos, nor routers are
            capable of DoNotAge processing, yet there any changes to the Neighbor
        State Machine. 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 because the proper operation of as follows. Area border routers transmit the
        Designated Router election algorithm requires periodic exchange
            existence of Hello Packets.

    3.3.  Interface State machine modifications

        OSPF interfaces to point-to-point demand circuits DoNotAge-incapable routers across area
            boundaries, using "indication-LSAs". Indication-LSAs are considered
            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 be in "Point-to-point" state if LSInfinity and only if they have a
        neighbor the DC-bit clear. Note
            that indication-LSAs convey no additional information; in state "1-Way" or greater, otherwise
            particular, they are
        considered used even if the area border router is
            not really an AS boundary router (ASBR).

            Taking indication-LSAs into account, the rule as to be whether
            DoNotAge LSAs are allowed in state "Down". However, any particular area is EXACTLY
            the same as discussed above given previously in Section 3.2, Hellos are sent out interfaces 2.5, namely:
            DoNotAge LSAs will be allowed in "Down" state, at
        the reduced interval of PollInterval.  Hellos cease to be sent
        out the interface whenever the associated neighbor reaches state
        "Full".

        Note that as a result, an "LLDown" event for the point-to-point
        demand circuit's neighbor forces both the neighbor OSPF area if and only
            if, in the
        interface into area's link state "Down".

        For OSPF broadcast and NBMA networks that database, all LSAs have been configured the
            DC-bit set in their Options field.

            Through origination of indication-LSAs, the existence of
            DoNotAge-incapable routers can be viewed as demand circuits, there are no changes going from non-
            backbone regular areas, to the Interface State
        Machine.

    3.4.  Flooding over demand circuits

        Flooding over demand circuits (point-to-point or otherwise) is
        modified if backbone area and only if from there
            to all routers have indicated 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 they can
        process Area A has LSAs having DoNotAge set. This is determined by
        examining with the link state database 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 containing
        the demand circuit.  All the router-LSAs and type-4-summary-LSAs
        must have (Area 0.0.0.0). Furthermore,
                assume that the DC-bit set.  If one or more backbone has LSAs have with the DC-bit
        clear, flooding over demand circuits is unchanged from [1]. (In
        particular, router-LSAs or type-4-summary-LSAs clear
                that do 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 DC-bit set are flooded unchanged from [1], because their
        reception inhibits
                guidelines of Section 2.5.1.1 in mind.

            2.5.1.1.  Limiting indication-LSA origination

                To limit the flooding behavior defined below).
        Otherwise, flooding is changed as follows.

        First, only truly changed LSAs 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 flooded over demand circuits.
        When 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 receives has a new LSA instance, it checks first to higher OSPF Router ID than
                Router X (same tie-breaker as for forwarding address
                origination; see whether the contents have changed. If not, the new LSA is
        simply a periodic refresh and it is not flooded out attached
        demand circuits (it is still flooded out other interfaces
        however).  This check should be performed in Step 5b of Section
        13 in [1]. When comparing 12.4.5 of [1]), then Router X
                should not originate an LSA 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 its previous instance, the
        following are backbone area.  Furthermore,
                suppose that all considered to be changes routers are capable of DoNotAge
                processing, except for routers in contents:

        o   The LSA's Options field Areas A and B.
                Finally, suppose that Router Z has changed.

        o   One 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 LSA instances has LS age set 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 MaxAge (or
            DoNotAge+MaxAge).

        o demand circuit endpoints

    The length field in following subsections detail the LSA header has changed.

        o   The contents modifications required of the LSA, excluding
    routers at the 20-byte link state
            header, have changed. Note that this excludes changes in LS
            Sequence Number endpoints of demand circuits. These consist of
    modifications to two main pieces of OSPF: 1) sending and LS Checksum.

        Second, when it has been decided receiving
    Hello Packets over demand circuits and 2) flooding LSAs over demand
    circuits.

    An additional OSPF interface configuration parameter,
    DemandInterface, is defined to flood indicate whether an LSA over OSPF interface
    connects to a demand
        circuit, DoNotAge should be set in the LSA's LS age field before
        flooding. This will cause the circuit (see Appendix B). Two routers
    connecting to a common network segment need not agree on the other side of the that
    segment's demand circuit status. However, to hold the LSA in their database indefinitely,
        removing the need for periodic refresh. Note that it is
        perfectly possible that DoNotAge will already be set. This
        simply indicates that get full benefit of the LSA has already been flooded over
    demand circuits. In any case, circuit extensions, the LS age field must also be
        incremented by InfTransDelay before flooding (see Step 5 two ends of
        Section 13.3 in [1]), as protection against flooding loops.

        The above paragraph also pertains to LSAs flooded over demand
        circuits in response a point-to-point link
    must both agree to Link State Requests.

        Third, when receiving treat the link as a Link demand circuit (see Section
    3.2).

    3.1.  Interface State Update from machine modifications

        An OSPF point-to-point interface connecting to a demand circuit
        neighbor that contains an LSA instance that
        is actually older
        than the the router's current copy, the router must respond by
        flooding its current LSA copy directly considered to the be in state "Point-to-point" if and only if its
        associated neighbor (without
        putting the LSA on the neighbor's Link State retransmission
        list). This is instead of in state "1-Way" or greater; otherwise
        the behavior specified interface is considered to be in Step 8 of
        Section 13 state "Down". Hellos are
        sent out such an interface when it is in [1], which would effectively ignore "Down" state, at the flood
        reduced interval of PollInterval. If the older advertisement. To see the necessity of responding to
        old LSAs, see Time T4 negotiation in Section 4.2.

4.  Examples

    This section gives three examples of the operation over demand
    circuits. The first example is probably
        3.2.1 succeeds, Hellos will cease to be sent out the most common and
    certainly interface
        whenever the most basic. It shows a single point-to-point demand
    circuit connecting two routers.  The second illustrates what happens
    when demand circuits and leased lines are used in parallel. The
    third explains what happens when associated neighbor reaches state "Full".

        Note that as a router has multiple demand
    circuits and cannot keep them all open (for resource reasons) at result, an "LLDown" event for the
    same time.

    4.1.  Example 1: Sole connectivity through demand circuits

        Figure 1 shows a sample internetwork with a single point-to-point
        demand
        circuit providing connectivity to circuit's neighbor forces both the LAN containing Host H2.
        Assume that all three routers (RTA, RTB neighbor and RTC) have
        implemented the functionality in
        interface into state "Down" (see Section 2 of this memo, 3.2.2).

        For OSPF broadcast and
        thus will be setting the DC-bit in their router-LSAs.
        Furthermore assume NBMA networks that Router RTB has have been configured
        as demand circuits, there are no changes to treat the link Interface State
        Machine.

    3.2.  Sending and Receiving OSPF Hellos

        The following sections describe the required modifications to Router RTC as a
        OSPF Hello Packet processing on point-to-point demand circuit, but Router RTC has
        not been so configured. Finally assume circuits.

        For OSPF broadcast and NBMA networks that have been configured
        as demand circuits, there is no change to the LAN interface
        connecting Router RTA sending and
        receiving of Hellos, nor are there any changes to Host H1 the Neighbor
        State Machine. This is initially down.

        The following sequence because the proper operation of events may then transpire, starting
        with Router RTB booting and bringing up its link to the
        Designated Router RTC:

               +           +                             +
               |   +---+   |                             |
        +--+   |---|RTA|---|                             |   +--+
        |H1|---|   +---+   |                             |---|H2|
        +--+   |           |   +---+    ODL      +---+   |   +--+
               |LAN Y      |---|RTB|-------------|RTC|---|
               +           |   +---+             +---+   |
                           +                             +

               Figure 1: A single demand circuit (labeled
                    ODL) bisecting an internetwork.

        Time T0: RTB negotiates election algorithm requires periodic exchange
        of Hello Packets.

        3.2.1.  Negotiating Hello suppression

            On point-to-point demand circuit status

            Router RTB will start circuits, both endpoints must agree
            to suppress the sending of Hello Packets.  To ensure this
            agreement, a router sets the DC-bit in OSPF Hellos over and
            Database Description Packets sent out the demand circuit interface.
            Receiving an Hello or a Database Description Packet 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 indicates agreement. Receiving an Hello received from RTC may not have with the
            DC-bit
            set. However, subsequent Hellos clear and also listing the router's Router ID in the
            body of the Hello message, or a Database Description
            Packets received from RTC will have Packet
            with the DC-bit set, clear (either one indicating bidirectional
            connectivity) indicates that the two routers have agreed that other end refuses to
            suppress Hellos. In these latter cases, the link
            will be treated as a router reverts
            to the normal periodic sending of Hello Packets out the
            interface (see Section 9.5 of [1]).

            A demand circuit. The entire negotiation
            is pictured point-to-point circuit need be configured in Figure 2. Note that if RTC were unable or
            unwilling to only
            one of the two endpoints (see Section 4.1).  If a router
            implementing Sections 2 and 3 of this memo receives an Hello
            Packet with the DC-bit set, it should treat the point-to-
            point link as a demand circuit, making the initial
            Database Description sent from Router RTC appropriate
            changes to RTB would have its Hello Processing (see Section 3.2.2) and
            flooding (see Section 3.3).

            Even if the above negotiation fails, the router should
            continue setting the DC-bit clear, forcing treatment of in its Hellos and Database
            Descriptions (the neighbor will just ignore the link as a leased
            line.

            +---+                                        +---+
            |RTB|                                        |RTC|
            +---+                                        +---+
                          Hello (DC-bit set)
                  ------------------------------------->
                          Hello (DC-bit clear)
                  <------------------------------------- bit). The
            router will then automatically attempt to renegotiate Hello (DC-bit set, RTC seen)
                  ------------------------------------->
                     Database Description (DC-bit set)
                  <-------------------------------------

              Figure 2: Successful negotiation
            suppression whenever the link goes down and comes back up.
            For example, if the neighboring router is rebooted with
            software that is capable of a link's
                          demand circuit status.

        Time T1: Database exchange operating over demand circuit

            The initial synchronization circuits
            (i.e., implements Sections 2 and 3 of link state databases (the
            Database Exchange Process) over this memo), a future
            negotiation will succeed.

            Also, even if the demand circuit then
            occurs as over any point-to-point link, with one exception.
            LSAs included negotiation to suppress Hellos fails, the
            flooding modifications described in Link state updates sent Section 3.3 are still
            performed over the demand
            circuit (in response to Link State Request Packets), will
            have the DoNotAge bit set in their LS age field. So, after link.

        3.2.2.  Neighbor state machine modifications

            When the Database Exchange Process above negotiation succeeds, Hello Packets are sent
            over point-to-point demand circuits only until initial
            link-state database synchronization is finished, all routers will
            have 3 LSAs in their link state databases (router-LSAs for
            Routers RTA, RTB and RTC), but achieved with the LS age fields belonging
            to
            neighbor (i.e., the LSAs will vary depending on which side state of the demand
            circuit they were originated from (see Table 1). For
            example, all routers other than Router RTC have the DoNotAge
            bit set neighbor connection reaches
            "Full", as defined in Router RTC's router-LSA; this removes Section 10.1 of [1]). After this,
            Hellos are suppressed and the need
            for Router RTC data-link connection to refresh its router-LSA over the demand
            circuit.

        Time T2: Hello traffic ceases

            After
            neighbor is assumed available until evidence is received to
            the Database Exchange Process has completed, no Hellos
            are sent over contrary. When the demand circuit. If there router finds that the neighbor is no application
            data
            longer available, presumably from something like a
            diagnostic code contained in a response to be sent over the demand circuit, a failed call
            request, the circuit will be
            idle.

        Time T3: Underlying data-link neighbor connection torn down

            After some period transitions back to "Down"
            and Hellos are sent periodically (at Intervals of inactivity, the underlying data-link
            connection will be torn down (e.g., an ISDN call will be
            cleared)
            PollInterval) in order an attempt to save connect charges. restart synchronization with
            the neighbor.

            This will be
            transparent requires changes to the OSPF routing; no LSAs or routing table
            entries will change as a result.

                                          LS age
             LSA Neighbor State Machine
            (see Section 10.3 of [1]). The receipt of Hellos from demand
            circuit neighbors in RTB state "Loading" or "Full" can no longer
            be required. In other words, the InactivityTimer event
            defined in RTC
             ______________________________________________
             RTA's Router-LSA   1000          DoNotAge+1001
             RTB's Router-LSA   10            DoNotAge+11
             RTC's Router-LSA   DoNotAge+11   10

                    Table 1: LS age fields on either
                       side Section 10.2 of the [1] has no effect on demand
            circuit
        Time T4: Router RTA's LSA neighbors in state "Loading" or "Full".  An
            additional clarification is refreshed

            At some point Router RTA will refresh its own router-LSA
            (i.e., when needed in the LSA's LS age hits LSRefreshInterval). This
            refresh will Neighbor State
            Machine's LLDown event. For demand circuits, this event
            should be flooded to Router RTB, who will look at it mapped into the "discouraging diagnostic code"
            discussed previously in Section 1, and decide NOT should not be
            generated when the data-link connection has been closed
            simply to flood it save resources. Nor should LLDown be generated if
            a data-link connection fails due to temporary lack of
            resources.

    3.3.  Flooding over the demand circuit to Router
            RTC, because the LSA's contents circuits

        Flooding over demand circuits (point-to-point or otherwise) is
        modified if and only if all routers have not really changed
            (only the LS Sequence Number). At this point, the LS
            sequence numbers indicated that they can
        process LSAs having DoNotAge set. This is determined by
        examining the routers have for RTA's router-LSA
            differ depending on which side link state database of the OSPF area containing
        the demand circuit circuit.  All LSAs in the
            routers lie. Because there is still no application traffic, database must have the underlying data-link connection remains disconnected.

        Time T5: Router RTA's LAN interface comes up DC-
        bit set.  If one or more LSAs have the DC-bit clear, flooding
        over demand circuits is unchanged from [1].  Otherwise, flooding
        is changed as follows.

        (1) Only truly changed LSAs are flooded over demand circuits.
            When Router RTA's LAN interface (connecting to Host H1)
            comes up, RTA will originate a router receives a new router-LSA. This router- LSA WILL be flooded over instance, it checks first
            to see whether the demand circuit because its contents have now changed. The underlying data-link
            connection will have to If not, the new
            LSA is simply a periodic refresh and it is not flooded out
            attached demand circuits (it is still flooded out other
            interfaces however).  This check should be brought up performed in Step
            5b of Section 13 in [1]. When comparing an LSA to flood its
            previous instance, the LSA.
            After flooding, routers on following are all considered to be
            changes in contents:

            o   The LSA's Options field has changed.

            o   One or both sides of the demand circuit
            will again agree on LSA instances has LS age set to
                MaxAge (or DoNotAge+MaxAge).

            o   The length field in the LSA header has changed.

            o   The contents of the LSA, excluding the 20-byte link
                state header, have changed. Note that this excludes
                changes in LS Sequence Number for RTA's
            router-LSA.

        Time T6: Underlying data-link connection is torn down again

            Assuming that there is still no application traffic
            transiting the and LS Checksum.

        (2) When it has been decided to flood an LSA over a demand
            circuit, the underlying data-link
            connection will again DoNotAge should be torn down after some period set in the copy of
            inactivity.

        Time T7: File transfer started between Hosts H1 and H2

            As soon as application data needs to be sent across the
            demand circuit LSA that
            is flooded out the underlying data-link connection demand interface. (There is
            brought back up.

        Time T8: Physical link becomes inoperative

            If an indication one
            exception: DoNotAge should not be set if the LSA's LS age is received from
            equal to MaxAge.) Setting DoNotAge will cause the data-link or physical
            layers indicating that routers on
            the other side of the demand circuit can no longer be
            established, Routers RTB and RTC declare their point-to-
            point interfaces down, and originate new router-LSAs. Both
            routers will attempt to bring hold the connection back up by
            sending Hellos at LSA in
            their databases indefinitely, removing the reduced rate of PollInterval. need for periodic
            refresh. Note that while the connection it is inoperative, Routers RTA and
            RTB perfectly possible that DoNotAge
            will continue to have an old router-LSA for RTC in their
            link state database, and this already be set. This simply indicates that the LSA will not age out because
            it has
            already been flooded over demand circuits. In any case, the DoNotAge bit set. However, according to
            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 they will flush Router RTC's router-LSA if the of this memo), as protection against flooding
            loops.

            The previous paragraph also pertains to LSAs flooded over
            demand
            circuit remains inoperative for longer than MaxAge.

    4.2.  Example 2: Demand and non-demand circuits in parallel

        This example demonstrates the demand circuit functionality when
        both demand circuits and non-demand circuits (e.g., leased
        lines) are used response to interconnect regions of an internetwork. Such
        an internetwork is shown in Figure 3. Host H1 can communicate
        with Host H2 either Link State Requests. It also
            pertains to LSAs that are retransmitted over the demand
            circuits.

    3.4.  Virtual link between Routers RTB and
        RTC, or over the leased line between Routers RTB and RTD.

        Because the basic properties support

        OSPF virtual links are essentially unnumbered point-to-point
        links (see Section 15 of the [1]). Accordingly, demand circuit functionality
        were presented
        support for virtual links resembles that described for point-
        to-point links in the previous example, this example will only
        address the unique issues involved when using both demand and
        non-demand circuits in parallel.

        Assume sections. The main difference is
        that Routers RTB a router implementing Sections 2 and RTY are powered off, but that all
        other routers 3 of this memo, and their attached
        supporting virtual links, always treats virtual links are both operational and
        implement the as if they
        were demand circuit modifications to OSPF. Throughout
        the example, circuits. Otherwise, when a TCP connection between Hosts H1 and H2 is
        transmitting data. Furthermore, assume that virtual link's
        underlying physical path contains one or more demand circuits,
        periodic OSPF protocol exchanges over the cost of virtual link would
        unnecessarily keep the underlying demand circuits open.

        Demand circuit from RTB to RTC has been set considerably higher
        than the cost support on virtual links can be summarized as
        follows:

        o   Instead of modifying the leased line between RTB and RTD; Interface state machine for this
        reason traffic between Hosts H1 and H2 will always be sent over virtual
            links as was done for point-to-point links in Section 3.1,
            the leased line when it Interface state machine for virtual links remains
            unchanged. A virtual link is operational.

        The following events may then transpire:

        Time T0: Router RTB comes up.

            Assume RTB supports 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 circuit OSPF modifications.
            When Router RTB comes up and establishes circuits. In
            particular, over virtual links a router always negotiates to Routers
            RTC and RTD, it will flood
            suppress the same information over both.
            However, LSAs sent over sending of Hellos. See Sections 3.2.1 and 3.2.2
            for details.

        o   In the demand circuit (to Router RTC)
            will have the DoNotAge bit set, while those sent support over virtual links, there is
            no "discouraging diagnostic code" as described in Section 1.
            Instead, the
            leased line to Router RTD will not. Because the DoNotAge bit connection is not taken into account when comparing LSA instances, considered to exist if and only
            if an intra-area path (through the
            routers on virtual link's transit
            area) exists to the right side other endpoint. See Section 15 of RTB (RTC, RTE and RTD) may or
            may [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 have all pairs. In
        this case the DoNotAge bit set in Point-to-Multipoint interface represents the copies of
        single physical interface to the RTA
            and RTB router-LSAs contained in their database. This
            depends Frame relay network, over which
        multiple point-to-point OSPF conversations (one on each PVC) are
        taking place. For more information on whether the LSAs sent over 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 link reach
        circuit support for point-to-point links. However, since the routers before those sent over
        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 leased line. One
            possibility 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 pictured 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 Table 2.

                                             +
                                      +---+  |
                                      |RTC|--|         +
                                      +---+  |  +---+  |
               +                     /       |--|RTE|--|  +--+
       +--+    |                    /ODL     |  +---+  |--|H2|
       |H1|----|  +---+       +---+/         |         +  +--+
       +--+    |--|RTA|-------|RTB|          |
               |  +---+       +---+\         |         +
               +                    \        |  +---+  |
                                     \       |--|RTY|--|
                                      +---+  |  +---+  |
                                      |RTD|--|         +
                                      +---+  |
                                             +

                       Figure 3: A sample internetwork.

                 Vertical lines are LAN segments. Six routers
                 are pictured, Routers RTA-RTE Section 3.2.1.  Negotiation
            may fail on some component point-to-point links, and RTY.
                 RTB has succeed
            on others. This is acceptable. On those component links
            where the negotiation fails, Hellos will always be sent;
            otherwise, Hellos will cease to be sent when the Database
            Description process completes on the component link (see
            Section 3.2.2).

        o   Section 3.3 defines the demand circuit flooding behavior for
            all OSPF interface types. This includes Point-to-Multipoint
            interfaces.

4.  Examples

    This section gives three serial line interfaces, two examples of
                 which are leased lines the operation over demand
    circuits. The first example is probably the most common and
    certainly the third (connecting to
                 RTC) most basic. It shows a single point-to-point demand circuit. Two hosts, H1
    circuit connecting two routers.  The second illustrates what happens
    when demand circuits and
                 H2, leased lines are pictured to illustrate the effect of
                              application traffic.

                                          LS age
            LSA                in RTC        in RTD used in RTE
            ________________________________________________
            RTA's Router-LSA   DoNotAge+20   21       21
            RTB's Router-LSA   DoNotAge+5    6        6

                 Table 2: After Time T0, LS age fields
                    on parallel. The
    third explains what happens when a router has multiple demand
    circuits and cannot keep them all open (for resource reasons) at the right side of Router RTB.

                                          LS age
            LSA                in RTC
    same time.

    4.1.  Example 1: Sole connectivity through demand circuits

        Figure 1 shows a sample internetwork with a single demand
        circuit providing connectivity to the LAN containing Host H2.
        Assume that all three routers (RTA, RTB and RTC) have
        implemented the functionality in RTD Section 2 of this memo, and
        thus will be setting the DC-bit in RTE
            _______________________________________________
            RTA's Router-LSA   5            6        6
            RTB's Router-LSA   DoNotAge+5   1785     1785

                 Table 3: After Time T2, LS age fields
                    on their LSAs. Furthermore
        assume that Router RTB has been configured to treat the right side of link to
        Router RTB.

                                          LS age
        LSA                in RTC       in RTD       in RTE
        _______________________________________________________
        RTA's Router-LSA   325          326          326
        RTB's Router-LSA   DoNotAge+5   DoNotAge+6   DoNotAge+6

                 Table 4: After Time T3, LS age fields
                    on the right side of as a demand circuit, but Router RTB.

                                          LS age
        LSA                in RTC       in RTD       in RTE
        _______________________________________________________
        RTA's Router-LSA   DoNotAge+7   DoNotAge+8   DoNotAge+8
        RTB's Router-LSA   DoNotAge+5   DoNotAge+6   DoNotAge+6

                 Table 5: After Time T4, LS age fields
                    on has not been so
        configured. Finally assume that the right side of LAN interface connecting
        Router RTB.

        Time T1: Underlying data-link connection RTA to Host H1 is torn initially down.

            All application traffic is flowing over the leased line
            connecting Routers RTB and RTD instead of the demand
            circuit, due to the leased line's lesser OSPF cost. After
            some period

        The following sequence of inactivity, the data-link connection
            underlying the demand circuit will be torn down. This does
            not affect the OSPF database or the routers' routing tables.

        Time T2: events may then transpire, starting
        with Router RTA refreshes RTB booting and bringing up its router-LSA.

            When link to Router RTA refreshes its router-LSA (as all routers do
            every LSRefreshInterval), RTC:

        Time T0: RTB negotiates Hello suppression

            Router RTB floods the refreshed
            LSA will start sending Hellos over the leased line but demand circuit
            with the DC-bit set in the Hello's Options field. Because
            RTC is not over configured to treat the link as a demand circuit,
            because
            the contents of the LSA have not changed. This new
            LSA first Hello received from RTC will not have the DoNotAge bit set, DC-bit
            set. However, subsequent Hellos and Database Description
               +           +                             +
               |   +---+   |                             |
        +--+   |---|RTA|---|                             |   +--+
        |H1|---|   +---+   |                             |---|H2|
        +--+   |           |   +---+    ODL      +---+   |   +--+
               |LAN Y      |---|RTB|-------------|RTC|---|
               +           |   +---+             +---+   |
                           +                             +

               Figure 1: In the example of Section 4.1,
                    a single demand circuit (labeled
                     ODL) bisects an internetwork.

            Packets received from RTC will replace have the
            old instances (whether or not they DC-bit set,
            indicating that the two routers have agreed that the DoNotAge bit
            set) by virtue of its higher LS Sequence number. This link
            will be treated as a demand circuit. The entire negotiation
            is pictured in Table 3.

        Time T3: Leased line becomes inoperational.

            When Figure 2. Note that if RTC were unable or
            unwilling to suppress Hellos on the leased line becomes operational, link, the data-link
            connection underlying the demand circuit will be reopened,
            in order initial
            Database Description sent from Router RTC to flood a new (and changed) router-LSA for RTB and
            also would have
            the DC-bit clear, forcing Router RTB to revert to carry the application traffic between Hosts H1 and
            H2. At this point, all routers on
            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 right side demand circuit then
            occurs as over any point-to-point link, with one exception.

            +---+                                        +---+
            |RTB|                                        |RTC|
            +---+                                        +---+
                          Hello (DC-bit set)
                  ------------------------------------->
                          Hello (DC-bit clear)
                  <-------------------------------------
                       Hello (DC-bit set, RTC seen)
                  ------------------------------------->
                     Database Description (DC-bit set)
                  <-------------------------------------

              Figure 2: Successful negotiation of Hello
                              suppression.

            LSAs included in Link State Updates Packets sent over the
            demand circuit (in response to Link State Request Packets),
            will have the DoNotAge bit set in their copy of RTB's
            router-LSA and DoNotAge clear LS age field. So,
            after the Database Exchange Process is finished, all routers
            will have 3 LSAs in their copy link state databases (router-LSAs
            for Routers RTA, RTB and RTC), but the LS age fields
            belonging to the LSAs will vary depending on which side of RTA's
            router-LSA
            the demand circuit they were originated from (see Table 4).

        Time T4: In 1).
            For example, all routers other than Router RTE, RTC have the
            DoNotAge bit set in Router RTA's router-LSA times out.

            Refreshes of RTC's router-LSA; this removes
            the need for Router RTA's RTC to refresh its router-LSA are not being flooded over the
            demand circuit. However, RTA's router-LSA is aging
            in all of

        Time T2: Hello traffic ceases

            After the routers to the right of Database Exchange Process has completed, no Hellos
            are sent over the demand circuit.
            For this reason, the router-LSA will eventually be flushed
            (by router RTE in our example).  Because this flushed LSA
            constitutes a real change (see Section 3.4), it If there is flooded no application
            data to be sent over the demand circuit, the circuit from Router RTC will be
            idle.

        Time T3: Underlying data-link connection torn down

            After some period of inactivity, the underlying data-link
            connection will be torn down (e.g., an ISDN call would be
            cleared) in order to save connect charges. This will be
            transparent to RTB. There are
            then two possible scenarios. First, the OSPF routing; no LSAs or routing table
            entries will change as a result.

                                          LS Sequence numbers
            for age
             LSA                in RTB        in RTC
             ______________________________________________
             RTA's router-LSA may have diverged Router-LSA   1000          DoNotAge+1001
             RTB's Router-LSA   10            DoNotAge+11
             RTC's Router-LSA   DoNotAge+11   10

                 Table 1: After Time T1 in Section 4.1,
                    possible LS age fields on either
                       side of the demand link. In this case, when router RTB receives the
            flushed circuit
        Time T4: Router RTA's LSA it is refreshed

            At some point Router RTA will respond by flooding back the more recent
            instance (see Section 3.4). If instead refresh its own router-LSA
            (i.e., when the LSA's LS sequence
            numbers are the same, the flushed LSA age hits LSRefreshInterval). This
            refresh will be flooded all
            the way back to Router RTA, which RTB, who will then be forced look at it
            and decide NOT to
            reoriginate the advertisement.

            In any case, after a small period all the routers on the
            right side of flood it over the demand link will circuit to Router
            RTC, because the LSA's contents have not really changed
            (only the DoNotAge bit set
            in their copy of RTA's router-LSA (see Table 5). In LS Sequence Number). At this point, the
            small interval between LS
            sequence numbers that the flushing and waiting routers have for a new
            instance of the LSA, there will be a temporary loss RTA's router-LSA
            differ depending on which side of
            connectivity between Hosts H1 and H2.

        Time T5: A non-supporting router joins.

            Suppose Router RTY now becomes operational, and does not
            support the demand circuit OSPF extensions. Router RTY's
            router-LSA then does not have the DC-bit set in its Options
            field, and as the router-LSA
            routers lie. Because there is flooded throughout the
            internetwork it flushes all LSAs having the DoNotAge bit set
            and causes the flooding behavior over still no application traffic,
            the demand circuit to
            revert back underlying data-link connection remains disconnected.

        Time T5: Router RTA's LAN interface comes up

            When Router RTA's LAN interface (connecting to the normal flooding behavior defined in [1].
            However, although all LSAs Host H1)
            comes up, RTA will now originate a new router-LSA. This router-
            LSA WILL be flooded over the demand circuit, regardless of whether their circuit because its
            contents have
            really changed, Hellos now changed. The underlying data-link
            connection will still continue have to be suppressed brought up to flood the LSA.
            After flooding, routers on both sides of the demand circuit (see Section 3.2).

    4.3.  Example 3: Operation when suffering SVC shortage

        Figure 4 shows a single Router (RT1) connected via demand
        circuits to three other routers (RT2-RT4). Assume that RT1 can
        only have two out of three underlying data-link connections open
        at once.  This may be due to one of
            will again agree on the following reasons.
        Router RT1 may be using a single Primary rate ISDN interface (2
        B channels) to support all three demand circuits. Or, RT1 may be
        connected a data-link switch (e.g., X.25 or Frame relay) that is
        only capable of so many simultaneous data-link connections.

        The following events may transpire, starting with Router RT1
        coming up. LS Sequence Number for RTA's
            router-LSA.

        Time T0: Router RT1 comes up.

            Router RT1 attempts to establish neighbor connections and
            synchronize OSPF databases with routers RT2-RT4. But,
            because it cannot have T6: Underlying data-link connections open to all
            three at once, it will synchronize with RT2 and RT3, while
            Hellos sent to RT4 will be discarded (see Section 1).

        Time T1: Data-link connection to RT2 closed due to inactivity. is torn down again

            Assuming that there is still no application traffic is being sent to/from
            Host H3,
            transiting the demand circuit, the underlying data-link
            connection to RT2 will
            eventually close due to inactivity. Then, the next Hello
                                                 +  +--+
                                          +---+  |--|H3|
                                +---------|RT2|--|  +--+
                               /          +---+  |
                              / ODL              +
                +--+  +      /
                |H1|--|     /                    +
                +--+  |  +---+    ODL     +---+  |
                      |--|RT1|------------|RT3|--|
                      |  +---+            +---+  |
                      |      \                   +
                      +       \ODL
                               \                 +  +--+
                                \         +---+  |--|H2|
                                 +--------|RT4|--|  +--+
                                          +---+  |
                                                 +

                     Figure 4: Behavior when not all again be torn down after some period of
            inactivity.

        Time T7: File transfer started between Hosts H1 and H2

            As soon as application data needs to be sent across the
            demand circuits' data- circuit the underlying data-link connection is
            brought back up.

        Time T8: Physical link connections becomes inoperative

            If an indication is received from the data-link or physical
            layers indicating that the demand circuit can no longer be opened
                                at once.

            that RT1 attempts to send to RT4
            established, Routers RTB and RTC declare their point-to-
            point interfaces down, and originate new router-LSAs. Both
            routers will cause attempt to bring the connection back up by
            sending Hellos at the reduced rate of PollInterval. Note
            that data-link while the connection to open is inoperative, Routers RTA and synchronization with RT4
            RTB will ensue.
            Note that, until continue to have an old router-LSA for RTC in their
            link state database, and this time, H2 LSA will be considered
            unreachable by OSPF routing. However, data traffic would not
            have been deliverable to H2 until now in any case.

        Time T2: RT2's LAN interface becomes inoperational

            This causes RT2 to reissue its router-LSA. However, it may
            be unable to flood age out because
            it to RT1 if RT1 already has data-link
            connections opened to RT3 and RT4. While the data-link
            connection from RT2 to RT1 cannot be opened due DoNotAge bit set. However, according to resource
            shortages, the new router-LSA will be continually
            retransmitted (and dropped by RT2's ISDN interface; see the
            last paragraph of Section 1). This means that the routing
            2.3 they will not detect flush Router RTC's router-LSA if the unreachability of H4 until a data-link
            connection on RT1 becomes available.

        Increasing demand
            circuit remains inoperative for longer than MaxAge.

    4.2.  Example 2: Demand and non-demand circuits in parallel

        This example demonstrates the OSPF cost of demand circuit functionality when
        both demand circuits that and non-demand circuits (e.g., leased
        lines) are currently
        discarding application packets, due used 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 interconnect regions of an issue for future study.

5.  Topology recommendations

    Because LSAs indicating topology changes are still flooded over
    demand circuits, it internetwork. Such
        an internetwork is still advantageous to design networks so that shown in Figure 3. Host H1 can communicate
        with Host H2 either over the demand circuits are isolated from as many topology changes as
    possible. In OSPF, this is done by encasing link between Routers RTB and
        RTC, or over the leased line between Routers RTB and RTD.

        Because the basic properties of the demand circuits
    within OSPF stub areas or within NSSAs (see [3]). In both cases, circuit functionality
        were presented in the previous example, this isolates example will only
        address the unique issues involved when using both demand and
        non-demand circuits from AS external routing changes,
    which in many networks parallel.

        Assume that Routers RTB and RTY are powered off, but that all
        other routers and their attached links are both operational and
        implement the most frequent (see [6]). Stub areas
    can even isolate demand circuit modifications to OSPF. Throughout
        the example, a TCP connection between Hosts H1 and H2 is
        transmitting data. Furthermore, assume that the cost of the
        demand circuits circuit from changes in other OSPF
    areas.

    Also, considering RTB to RTC has been set considerably higher
        than the interoperation cost of OSPF routers supporting
    demand circuits the leased line between RTB and those RTD; for this
        reason traffic between Hosts H1 and H2 will always be sent over
        the leased line when it is operational.

        The following events may then transpire:

        Time T0: Router RTB comes up.

            Assume RTB supports the demand circuit OSPF modifications.
            When Router RTB comes up and establishes links to Routers
            RTC and RTD, it will flood the same information over both.
            However, LSAs sent over the demand circuit (to Router RTC)
            will have the DoNotAge bit set, while those sent over the
            leased line to Router RTD will not. Because the DoNotAge bit
            is not taken into account when comparing LSA instances, the
            routers on the right side of RTB (RTC, RTE and RTD) may or
            may not have the DoNotAge bit set in their database copies
            of RTA's and RTB's router-LSAs.  This depends on whether the
            LSAs sent over the demand link reach the routers before
            those sent over the leased line. One possibility is pictured
            in Table 2.

                                             +
                                      +---+  |
                                      |RTC|--|         +
                                      +---+  |  +---+  |
               +                     /       |--|RTE|--|  +--+
       +--+    |                    /ODL     |  +---+  |--|H2|
       |H1|----|  +---+       +---+/         |         +  +--+
       +--+    |--|RTA|-------|RTB|          |
               |  +---+       +---+\         |         +
               +                    \        |  +---+  |
                                     \       |--|RTY|--|
                                      +---+  |  +---+  |
                                      |RTD|--|         +
                                      +---+  |
                                             +

                       Figure 3: Example 2's internetwork.

                 Vertical lines are LAN segments. Six routers
                 are pictured, Routers RTA-RTE and RTY.
                 RTB has three serial line interfaces, two of
                 which are leased lines and the third (connecting to
                 RTC) a demand circuit. Two hosts, H1 and
                 H2, are pictured to illustrate the effect of
                              application traffic.

                                          LS age
            LSA                in RTC        in RTD   in RTE
            ________________________________________________
            RTA's Router-LSA   DoNotAge+20   21       21
            RTB's Router-LSA   DoNotAge+5    6        6

              Table 2: After Time T0 in Example 2, LS age
                fields on the right side of Router RTB.

                                          LS age
            LSA                in RTC       in RTD   in RTE
            _______________________________________________
            RTA's Router-LSA   5            6        6
            RTB's Router-LSA   DoNotAge+5   1785     1785

              Table 3: After Time T2 in Example 2, LS age
                fields on the right side of Router RTB.

                                          LS age
        LSA                in RTC       in RTD       in RTE
        _______________________________________________________
        RTA's Router-LSA   325          326          326
        RTB's Router-LSA   DoNotAge+5   DoNotAge+6   DoNotAge+6

              Table 4: After Time T3 in Example 2, LS age
                fields on the right side of Router RTB.

                                          LS age
        LSA                in RTC       in RTD       in RTE
        _______________________________________________________
        RTA's Router-LSA   DoNotAge+7   DoNotAge+8   DoNotAge+8
        RTB's Router-LSA   DoNotAge+5   DoNotAge+6   DoNotAge+6

              Table 5: After Time T4 in Example 2, LS age
                fields on the right side of Router RTB.

        Time T1: Underlying data-link connection is torn down.

            All application traffic is flowing over the leased line
            connecting Routers RTB and RTD instead of the demand
            circuit, due to the leased line's lesser OSPF cost. After
            some period of inactivity, the data-link connection
            underlying the demand circuit will be torn down. This does
            not affect the OSPF database or the routers' routing tables.

        Time T2: Router RTA refreshes its router-LSA.

            When Router RTA refreshes its router-LSA (as all routers do
            every LSRefreshInterval), Router RTB floods the refreshed
            LSA over the leased line but not over the demand circuit,
            because the contents of the LSA have not changed. This new
            LSA will not have the DoNotAge bit set, and will replace the
            old instances (whether or not they have the DoNotAge bit
            set) by virtue of its higher LS Sequence number. This is
            pictured in Table 3.

        Time T3: Leased line becomes inoperational.

            When the leased line becomes inoperational, the data-link
            connection underlying the demand circuit will be reopened,
            in order to flood a new (and changed) router-LSA for RTB and
            also to carry the application traffic between Hosts H1 and
            H2. After flooding the new LSA, all routers on the right
            side of the demand circuit will have DoNotAge set in their
            copy of RTB's router-LSA and DoNotAge clear in their copy of
            RTA's router-LSA (see Table 4).

        Time T4: In Router RTE, Router RTA's router-LSA times out.

            Refreshes of Router RTA's router-LSA are not being flooded
            over the demand circuit. However, RTA's router-LSA is aging
            in all of the routers to the right of the demand circuit.
            For this reason, the router-LSA will eventually be aged out
            and reflooded (by router RTE in our example).  Because this
            aged out LSA constitutes a real change (see Section 3.3), it
            is flooded over the demand circuit from Router RTC to RTB.
            There are then two possible scenarios. First, the LS
            Sequence number for RTA's router-LSA may be larger on RTB's
            side of the demand link. In this case, when router RTB
            receives the flushed LSA it will respond by flooding back
            the more recent instance (see Section 2.4). If instead the
            LS sequence numbers are the same, the flushed LSA will be
            flooded all the way back to Router RTA, which will then be
            forced to reoriginate the LSA.

            In any case, after a small period all the routers on the
            right side of the demand link will have the DoNotAge bit set
            in their copy of RTA's router-LSA (see Table 5). In the
            small interval between the flushing and waiting for a new
            instance of the LSA, there will be a temporary loss of
            connectivity between Hosts H1 and H2.

        Time T5: A non-supporting router joins.

            Suppose Router RTY now becomes operational, and does not
            support the demand circuit OSPF extensions. Router RTY's
            router-LSA then will not have the DC-bit set in its Options
            field, and as the router-LSA is flooded throughout the
            internetwork it flushes all LSAs having the DoNotAge bit set
            and causes the flooding behavior over the demand circuit to
            revert back to the normal flooding behavior defined in [1].
            However, although all LSAs will now be flooded over the
            demand circuit, regardless of whether their contents have
            really changed, Hellos will still continue to be suppressed
            on the demand circuit (see Section 3.2.2).

    4.3.  Example 3: Operation when oversubscribed

        Figure 4 shows a single Router (RT1) connected via demand
        circuits to three other routers (RT2-RT4). Assume that RT1 can
        only have two out of three underlying data-link connections open
        at once.  This may be due to one of the following reasons:
        Router RT1 may be using a single Basic Rate ISDN interface (2 B
        channels) to support all three demand circuits, or, RT1 may be
        connected a data-link switch (e.g., X.25 or Frame relay) that is
        only capable of so many simultaneous data-link connections.

        The following events may transpire, starting with Router RT1
        coming up.

        Time T0: Router RT1 comes up.

            Router RT1 attempts to establish neighbor connections and
            synchronize OSPF databases with routers RT2-RT4. But,
            because it cannot have data-link connections open to all
            three at once, it will synchronize with RT2 and RT3, while
            Hellos sent to RT4 will be discarded (see Section 1).

        Time T1: Data-link connection to RT2 closed due to inactivity.

            Assuming that no application traffic is being sent to/from
            Host H3, the underlying data-link connection to RT2 will
            eventually close due to inactivity. Then, the next Hello
                                                 +  +--+
                                          +---+  |--|H3|
                                +---------|RT2|--|  +--+
                               /          +---+  |
                              / ODL              +
                +--+  +      /
                |H1|--|     /                    +
                +--+  |  +---+    ODL     +---+  |  +--+
                      |--|RT1|------------|RT3|--|--|H4|
                      |  +---+            +---+  |  +--+
                      |      \                   +
                      +       \ODL
                               \                 +  +--+
                                \         +---+  |--|H2|
                                 +--------|RT4|--|  +--+
                                          +---+  |
                                                 +

                     Figure 4: Example 3's internetwork.

            that RT1 attempts to send to RT4 will cause that data-link
            connection to open and synchronization with RT4 will ensue.
            Note that, until this time, H2 will be considered
            unreachable by OSPF routing. However, data traffic would not
            have been deliverable to H2 until now in any case.

        Time T2: RT2's LAN interface becomes inoperational

            This causes RT2 to reissue its router-LSA. However, it may
            be unable to flood it to RT1 if RT1 already has data-link
            connections open to RT3 and RT4. While the data-link
            connection from RT2 to RT1 cannot be opened due to resource
            shortages, the new router-LSA will be continually
            retransmitted (and dropped by RT2's ISDN interface; see
            Section 1). This means that the routers RT1, RT3 and RT4
            will not detect the unreachability of Host H3 until a data-
            link connection on RT1 becomes available.

5.  Topology recommendations

    Because LSAs indicating topology changes are still flooded over
    demand circuits, it is still advantageous to design networks so that
    the demand circuits are isolated from as many topology changes as
    possible. In OSPF, this is done by encasing the demand circuits
    within OSPF stub areas or within NSSAs (see [3]). In both cases,
    this isolates the demand circuits from AS external routing changes,
    which in many networks are the most frequent (see [6]). Stub areas
    can even isolate the demand circuits from changes in other OSPF
    areas.

    Also, considering the interoperation of OSPF routers supporting
    demand circuits and those that do not (see Section 2.5), isolated
    stub areas or NSSAs can be converted independently to support demand
    circuits. In contrast, regular OSPF areas must all be converted
    before the functionality can take effect in any particular regular
    OSPF area.

6.  Lost functionality

    The enhancements defined in this memo to support demand circuits
    come at some cost. Although we gain an efficient use of demand
    circuits, holding them open only when there is actual application
    data to send, we lose the following:

    Robustness
        In regular OSPF [1], all LSAs are refreshed every
        LSRefreshInterval.  This provides protection against routers
        losing LSAs from (or LSAs getting corrupted in) their link state
        databases due to software errors, etc.  Over demand circuits
        this periodic refresh is removed, and we depend on routers
        correctly holding LSAs marked with DoNotAge in their databases
        indefinitely.

    Database Checksum
        OSPF supplies network management variables, namely
        ospfExternLSACksumSum and ospfAreaLSACksumSum in [7], allowing a
        network management station to verify OSPF database
        synchronization among routers. However, these variables are sums
        of the individual LSAs' LS checksum fields, which are no longer
        guaranteed to be identical across demand circuits (because the
        LS checksum covers the LS Sequence Number, which will in general
        differ across demand circuits). This means that these variables
        can no longer be used to verify database synchronization in OSPF
        networks containing demand circuits.

7.  Future work: Oversubscription

    An internetwork is oversubscribed when not all of its demand
    circuits' underlying connections can be open at once, due to
    resource limitations.  These internetworks were addressed in Section
    4.3. However, when all possible sources in the internetwork are
                     +--+  +                     +  +--+
                     |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 do not (see Section 2.3), isolated
    stub areas or NSSAs a) their data-link connections can be converted independently
        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 support two
        simultaneously open demand circuits. In contrast, regular OSPF areas must all be converted
    before the functionality

    (2) Even if it is possible that a spanning tree can take effect in any particular regular
    OSPF area.

6.  Lost functionality

    The enhancements defined form, will one?
        Given the model in this memo to support Section 1, demand circuits
    come at some cost. Although we gain an efficient use of demand
    circuits, holding them open only are brought up
        when there is actual application 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 send, establish a circuit to any other. However, we lose
        assume that each router can only have two circuits open at once
        (e.g., the following:

    Robustness
        In regular OSPF [1], all LSAs are refreshed every
        LSRefreshInterval.  This provides protection against routers
        losing LSAs from (or LSAs getting corrupted in) their link state
        databases due to software errors, etc.  Over demand circuits could be using Basic Rate ISDN).  In this periodic refresh is removed, and we depend on routers
        correctly holding LSAs marked with DoNotAge in their databases
        indefinitely.

    Database Checksum
        OSPF supplies network management variables,
        ospfExternLSACksumSum and ospfAreaLSACksumSum
        case, one would hope that the data-link connections in [7], allowing a
        network management station Figure 5a
        would form.  But the connections in Figure 5b are equally
        likely, which leave Host H2 unable to verify communicate.

        One possible approach to this problem would be for a) the OSPF
        database
        synchronization among routers. However, these variables are sums 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 individual LSAs' LS checksum fields, functionality described in this memo do
        not necessarily know which data-link connections are no longer
        guaranteed to be identical across established
        at any one time. In fact, they view all demand circuits (because as being
        equally available, whether or not they are established. So for
        example, even when the
        LS checksum covers established connections form the LS Sequence Number, which will pattern
        in general
        differ across demand circuits). This means Figure 5a, Router RT1 may still believe that these variables
        can no longer the best path to
        Router RT3 is through the direct demand circuit.  However, this
        circuit cannot be used established due to verify database synchronization in resource shortages.

        On possible approach to this problem is to increase the OSPF
        networks containing
        cost of demand circuits. 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. The Format of the OSPF Options field

    The OSPF Options field is present in OSPF Hello packets, Database
    Description packets and all LSAs. The Options field enables OSPF
    routers to support (or not support) optional capabilities, and to
    communicate their capability level to other OSPF routers. Through
    this mechanism routers of differing capabilities can be mixed within
    an OSPF routing domain.

    The memo defines one of the Option bits: the DC-bit (for Demand
    Circuit capability). The DC-bit is set in a router's router-LSA self-originated
    LSAs if and only if it supports the functionality defined in Section 3
    2 of this memo. Note that this does not necessarily mean that the
    router can be the endpoint of a demand circuit, but only that it can
    properly process LSAs having the DoNotAge bit set. In contrast, the
    DC-bit is set in Hello Packets and Database Description Packets sent
    out an interface if and only if the router wants to treat the
    attached point-to-point network as a demand circuit (see Section 3.1).
    3.2.1).

    The addition of the DC-bit makes the current assignment of the OSPF
    Options field as follows:

                       +------------------------------------+
                       | * | * | DC | EA | N/P | MC | E | T |
                       +------------------------------------+

                         Figure 5: The OSPF Options field

    T-bit
        This bit describes TOS-based routing capability, as specified in
        [1].

    E-bit
        This bit describes the way AS-external-LSAs are flooded, as
        described in [1].

    MC-bit
        This bit describes whether IP multicast datagrams are forwarded
        according to the specifications in [4].

    N/P-bit
        This bit describes the handling of Type-7 LSAs, as specified in
        [3].

    EA-bit
        This bit describes the router's willingness to receive and
        forward External Attributes LSAs, as specified in [5].

    DC-bit
        This bit describes the handling of demand circuits, as specified
        in this memo.  Its setting in Hellos and Database Description
        Packets is described in Section 3.1. Sections 3.2.1 and 3.2.2. Its setting in
        LSAs is described in Section 2.3. Sections 2.1 and 2.5.

B. Configurable Parameters

    This memo defines a single additional configuration parameter for
    OSPF interfaces. In addition, the OSPF Interface configuration
    parameter PollInterval, previously used only on NBMA networks, is
    now also used on point-to-point networks (see Section 3.3). Sections 3.1 and
    3.2.2).

    DemandInterface
        Indicates whether the interface connects to a demand circuit.
        When set to TRUE, the procedures described in Section 3 of this
        memo are followed, in order to send a minimum of routing traffic
        over the demand circuit. On point-to-point networks, this allows
        the circuit to be closed when not carrying application traffic.
        When the demand interface is configured to be a broadcast or NBMA network is configured to be a demand
        interface (see Section 1.2 of [1]), the circuit will be kept
        open constantly due to OSPF Hello traffic, but the amount of
        flooding traffic will still be greatly reduced.

C. Architectural Constants

    This memo defines a single additional OSPF architectural constant.

    DoNotAge
        Equal to the hexadecimal value 0x8000, or which is the high bit of
        the 16-bit LS Age field in OSPF LSAs. When this bit is set in
        the LS age field, the LSA is not aged as it is held in the
        router's link state database. This allows the elimination of the
        periodic LSA refresh over demand circuits. See Section 2.1 2.2 for
        more information on processing the DoNotAge bit.

References

    [1]  Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994.

    [2]  Meyer, G., "Extensions to RIP to Support Demand Circuits", RFC
         1582, Spider Systems, February 1994.

    [3]  Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587,
         RainbowBridge Communications, Stanford University, March 1994.

    [4]  Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon,
         Inc., March 1994.

    [5]  Ferguson, D., "The OSPF External Attributes LSA", Internet
        Draft, draft-ietf-ospf-extattr-00.txt, March 1993. work in
         progress.

    [6]  Moy, J., editor, "OSPF protocol analysis", RFC 1245, Proteon,
         Inc., July 1991.

    [7]  Baker F. and R. Coltun, "OSPF Version 2 Management Information
         Base", RFC 1253, ACC, University of Maryland, August 1991.

    [8]  Baker F., "OSPF Point-to-MultiPoint Interface", Internet Draft,
        draft-ietf-ospf-pmp-if-00.txt, ACC, March 1994. work in
         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 issues are not discussed in this memo.

Author's Address

    John Moy
    Proteon, Inc.
    9 Technology Drive
    Westborough,
    Cascade Communications Corp.
    5 Carlisle Road
    Westford, MA 01581 01886

    Phone: 508-898-2800 508-692-2600 Ext. 394
    Fax:   508-898-3176   508-692-9214
    Email: jmoy@proteon.com jmoy@casc.com

    This document expires in November 1994. May 1995.