Network Working Group                                             J. Moy
Internet Draft                                             Proteon, Inc.
Expiration Date: November 1994                                  May 1994
File name: draft-ietf-ospf-demand-00.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 may be updated, replaced, or obsoleted by
    other documents at any time.  It is not appropriate to use
    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 listing contained in the Internet-Drafts Shadow
    Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
    munnari.oz.au.

Abstract

    This memo defines enhancements to the OSPF protocol that allow
    efficient operation over "demand circuits". Demand circuits are
    those whose costs vary with usage; charges can be based both on
    connect time and on bytes/packets transmitted. Examples of such
    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 to be open constantly, resulting in unwanted usage
    charges. With the modifications described herein, OSPF Hellos and
    the refresh of OSPF routing information are suppressed, allowing
    demand circuits 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,



Moy                                                             [Page 1]


Internet Draft         OSPF over Demand Circuits                May 1994


    which in effect still requires that the data-link circuits 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 link-state routing protocol
    rather than a Distance Vector protocol, the mechanisms used to
    achieve that 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, Gerry Meyer, and Tom Pusateri. This memo is a
    product of the OSPF Working Group.


























Moy                                                             [Page 2]


Internet Draft         OSPF over Demand Circuits                May 1994


Table of Contents

    1       Model for demand circuits .............................. 4
    2       Modifications to all OSPF routers ...................... 4
    2.1     The LS age field ....................................... 5
    2.2     Removing old, non-aging LSAs ........................... 6
    2.3     Interoperability with unmodified OSPF routers .......... 6
    3       Modifications to demand circuit endpoints .............. 7
    3.1     Configuring demand circuits ............................ 7
    3.2     Sending and Receiving OSPF Hellos ...................... 8
    3.3     Interface State machine modifications .................. 8
    3.4     Flooding over demand circuits .......................... 9
    4       Examples .............................................. 10
    4.1     Example 1: Sole connectivity through demand circuits .. 10
    4.2     Example 2: Demand and non-demand circuits in parallel . 14
    4.3     Example 3: Operation when suffering SVC shortage ...... 18
    5       Topology recommendations .............................. 20
    6       Lost functionality .................................... 20
    A       The Options field ..................................... 22
    B       Configurable Parameters ............................... 23
    C       Architectural Constants ............................... 23
            References ............................................ 24
            Security Considerations ............................... 24
            Author's Address ...................................... 24



























Moy                                                             [Page 3]


Internet Draft         OSPF over Demand Circuits                May 1994


1.  Model for demand circuits

    In this memo, demand circuits refer to those network segments whose
    cost depends on either connect time or on 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 the connection is successful, the data is sent, and the
    circuit 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 data-link connection may be closed at any particular
    time, it is assumed by the routing layer that it 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 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. In these cases, datagrams to be
    forwarded out these (temporarily unopenable) data-link connections
    are discarded, instead of queued. Note also that this temporary
    inability to open data-link connections is NOT reported by the OSPF
    routing system as unreachability; see Section 4.3 for more
    information.

2.  Modifications to all OSPF routers

    While most of the modifications to support demand circuits are
    isolated to the demand circuit endpoints, 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 the
    options field of their router-LSA (see Section 2.3 and Appendix A),



Moy                                                             [Page 4]


Internet Draft         OSPF over Demand Circuits                May 1994


    even if they do not implement the more substantial modifications
    required of demand circuit endpoints that are described in Section
    3.

    2.1.  The LS age field

        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. 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 have the DoNotAge bit
        set.

        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
        have their DoNotAge bits masked off.  For example, in
        determining which LSA is more recent, LS ages of 1 and
        DoNotAge+1 should be 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, DoNotAge+MaxAge is equivalent to MaxAge, and
        either form can be used to flush LSAs from the routing domain
        (see Section 14.1 of [1]).

        When an LSA is flooded out a non-demand interface, the constant
        InfTransDelay is added to the LSA's LS age field. This happens
        even if the DoNotAge bit is set; in this case the LS age field
        is not allowed to exceed DoNotAge+MaxAge, at which time the LSA
        is flushed from the routing domain. This preserves the
        protection in [1] afforded against flooding loops. Flooding out
        demand interfaces is covered in Section 3.4.

        Thus, the set of allowable values for the LS age field fall into
        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



Moy                                                             [Page 5]


Internet Draft         OSPF over Demand Circuits                May 1994


        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 whose DoNotAge bits were
        mistakenly set.

    2.2.  Removing old, non-aging 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 LSA if the originator of the LSA has been
        unreachable (according to the routing calculations specified by
        Section 16 of [1]) for the time MaxAge. For an example, see Time
        T8 in Section 4.1. This is an exception to the general OSPF rule
        that a router can only flush its own self-originated LSAs.

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

    2.3.  Interoperability with unmodified OSPF routers

        Unmodified OSPF routers will probably treat LSAs with the
        DoNotAge bit set as if they had LS age of MaxAge. At the very
        worst, this will cause continual retransmissions of LSAs with
        the DoNotAge bit set.

        However, 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 is not required that
        the LSAs' Advertising Router is reachable; if any LSA is found
        not having its DC-bit set (regardless of reachability), then the
        router should flush from the area all advertisements having
        DoNotAge set; this is an exception to the general OSPF rule that
        a router can only flush its own self-originated LSAs. When
        flushing, the LSAs' LS age field should be set to MaxAge and not
        DoNotAge+MaxAge.

        (As an implementation suggestion, a new variable "DCBitLessLSAs"
        could be added to the OSPF area data structure in Section 6 of
        [1]. This variable would count the number of the area's router-
        LSAs and type-4-summary-LSAs that do not have the DC-bit set.



Moy                                                             [Page 6]


Internet Draft         OSPF over Demand Circuits                May 1994


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

        In particular, AS-external-LSAs with the DoNotAge bit set cannot
        exist in the routing domain unless all routers in all "regular
        OSPF areas" (all areas that are neither stub areas nor NSSAs)
        are capable of processing DoNotAge. In order to convey this
        information across area boundaries, area border routers must set
        the DC-bit in a type-4-summary-LSA that they originate if and
        only if the described ASBR has the DC-bit set in its original
        router-LSA.  Additionally, sometimes in may be necessary to
        convey across areas the the existence of a non-ASBR that cannot
        process DoNotAge. In this case, a type-4-summary-LSA should be
        originated with cost of LSInfinity and DC-bit clear.

3.  Modifications to demand circuit endpoints

    The following subsections detail the modifications required of the
    routers at the endpoints of demand circuits. This consists of
    modifications to two main pieces 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 the DC-bit in OSPF Hellos
        (and Database Description Packets) sent out the demand
        interface. Receiving an Hello or a Database Description Packet
        with the DC-bit set indicates agreement. Receiving an Hello with
        the DC-bit clear and also listing the router's Router ID in the
        body of the Hello message, or a Database Description Packet with
        the DC-bit clear (either one indicating bidirectional
        connectivity) indicates that the other end refuses to treat the
        link as a demand circuit. In these cases, the router reverts to
        treating the link as a leased line.

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

        If the negotiation fails, and the router is forced to treat the
        line as a leased line, the router can always renegotiate the
        link's demand status whenever the link goes down. For example,



Moy                                                             [Page 7]


Internet Draft         OSPF over Demand Circuits                May 1994


        if the neighboring router is rebooted with software that is
        capable of operating over demand circuits, a future negotiation
        will succeed.

        For more information on sending OSPF Hellos over demand
        circuits, see Section 3.2.

    3.2.  Sending 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., the state of the neighbor
        connection reaches "Full", as defined in Section 10.1 of [1]).
        After this, Hellos are suppressed and the data-link connection
        to the neighbor is assumed available until evidence is received
        to the contrary. When the router finds that the neighbor is no
        longer available, presumably from something like a diagnostic
        code contained in a response to a failed call request, the
        neighbor connection transitions back to "Down" and Hellos are
        sent periodically (at Intervals of PollInterval) in an attempt
        to restart synchronization with the neighbor.

        This requires changes to the OSPF Neighbor State Machine (see
        Section 10.3 of [1]). The receipt of Hellos from neighbors in
        state "Loading" or higher cannot be required. In other words,
        the InactivityTimer event defined in Section 10.2 of [1] has no
        effect on neighbors in state "Loading" or higher.  An additional
        clarification is needed in the Neighbor State Machine's LLDown
        event. This event should be mapped into the "discouraging
        diagnostic code" discussed above in Section 1, and should not be
        generated when the data-link connection has been closed simply
        to save resources.

        For OSPF broadcast and NBMA networks that have been configured
        as demand circuits, there is no change to the sending and
        receiving of Hellos, nor are there any changes to the Neighbor
        State Machine. This is because the proper operation of the
        Designated Router election algorithm requires periodic exchange
        of Hello Packets.

    3.3.  Interface State machine modifications

        OSPF interfaces to point-to-point demand circuits are considered
        to be in "Point-to-point" state if and only if they have a
        neighbor in state "1-Way" or greater, otherwise they are
        considered to be in state "Down". However, as discussed above in
        Section 3.2, Hellos are sent out interfaces in "Down" state, at
        the reduced interval of PollInterval.  Hellos cease to be sent



Moy                                                             [Page 8]


Internet Draft         OSPF over Demand Circuits                May 1994


        out the interface whenever the associated neighbor reaches state
        "Full".

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

        For OSPF broadcast and NBMA networks that have been configured
        as demand circuits, there are no changes to the Interface State
        Machine.

    3.4.  Flooding over demand circuits

        Flooding over demand circuits (point-to-point or otherwise) is
        modified if and only if all routers have indicated that they can
        process LSAs having DoNotAge set. This is determined by
        examining the link state database of the OSPF area containing
        the demand circuit.  All the router-LSAs and type-4-summary-LSAs
        must have the DC-bit set.  If one or more LSAs have the DC-bit
        clear, flooding over demand circuits is unchanged from [1]. (In
        particular, router-LSAs or type-4-summary-LSAs that do not have
        the DC-bit set are flooded unchanged from [1], because their
        reception inhibits the flooding behavior defined below).
        Otherwise, flooding is changed as follows.

        First, only truly changed LSAs are flooded over demand circuits.
        When a router receives a new LSA instance, it checks first to
        see whether the contents have changed. If not, the new LSA is
        simply a periodic refresh and it is not flooded out attached
        demand circuits (it is still flooded out other interfaces
        however).  This check should be performed in Step 5b of Section
        13 in [1]. When comparing an LSA to its previous instance, the
        following are all considered to be changes in contents:

        o   The LSA's Options field has changed.

        o   One of the LSA instances has LS age set to MaxAge (or
            DoNotAge+MaxAge).

        o   The length field in the LSA header has changed.

        o   The contents of the LSA, excluding the 20-byte link state
            header, have changed. Note that this excludes changes in LS
            Sequence Number and LS Checksum.

        Second, when it has been decided to flood an LSA over a demand
        circuit, DoNotAge should be set in the LSA's LS age field before
        flooding. This will cause the routers on the other side of the



Moy                                                             [Page 9]


Internet Draft         OSPF over Demand Circuits                May 1994


        demand circuit 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 the LSA has already been flooded over
        demand circuits. In any case, the LS age field must also be
        incremented by InfTransDelay before flooding (see Step 5 of
        Section 13.3 in [1]), as protection against flooding loops.

        The above paragraph also pertains to LSAs flooded over demand
        circuits in response to Link State Requests.

        Third, when receiving a Link State Update from 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 to the neighbor (without
        putting the LSA on the neighbor's Link State retransmission
        list). This is instead of the behavior specified in Step 8 of
        Section 13 in [1], which would effectively ignore the flood of
        the older advertisement. To see the necessity of responding to
        old LSAs, see Time T4 in Section 4.2.

4.  Examples

    This section gives three examples of the operation over demand
    circuits. The first example is probably the most common and
    certainly the most basic. It shows a single point-to-point demand
    circuit connecting two routers.  The second illustrates what happens
    when demand circuits and leased lines are used in parallel. The
    third explains what happens when a router has multiple demand
    circuits and cannot keep them all open (for resource reasons) at the
    same time.

    4.1.  Example 1: Sole connectivity through demand circuits

        Figure 1 shows a sample internetwork with a single demand
        circuit providing connectivity to the LAN containing Host H2.
        Assume that all three routers (RTA, RTB and RTC) have
        implemented the functionality in Section 2 of this memo, and
        thus will be setting the DC-bit in their router-LSAs.
        Furthermore assume that Router RTB has been configured to treat
        the link to Router RTC as a demand circuit, but Router RTC has
        not been so configured. Finally assume that the LAN interface
        connecting Router RTA to Host H1 is initially down.

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





Moy                                                            [Page 10]


Internet Draft         OSPF over Demand Circuits                May 1994




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


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


        Time T0: RTB negotiates demand circuit status

            Router RTB will start sending Hellos over the demand circuit
            with the DC-bit set in the Hello's Options field. Because
            RTC is not configured to treat the link as a demand circuit,
            the first Hello received from RTC may not have the DC-bit
            set. However, subsequent Hellos and Database Description
            Packets received from RTC will have the DC-bit set,
            indicating that the two routers have agreed that the link
            will be treated as a demand circuit. The entire negotiation
            is pictured in Figure 2. Note that if RTC were unable or
            unwilling to treat the link as a demand circuit, the initial
            Database Description sent from Router RTC to RTB would have
            the DC-bit clear, forcing treatment of the link as a leased
            line.

            +---+                                        +---+
            |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 a link's
                          demand circuit status.





Moy                                                            [Page 11]


Internet Draft         OSPF over Demand Circuits                May 1994


        Time T1: Database exchange over demand circuit

            The initial synchronization of link state databases (the
            Database Exchange Process) over the demand circuit then
            occurs as over any point-to-point link, with one exception.
            LSAs included in Link state updates sent over the demand
            circuit (in response to Link State Request Packets), will
            have the DoNotAge bit set in their LS age field. So, after
            the Database Exchange Process is finished, all routers will
            have 3 LSAs in their link state databases (router-LSAs for
            Routers RTA, RTB and RTC), but the LS age fields belonging
            to the LSAs will vary depending on which side of the demand
            circuit they were originated from (see Table 1). For
            example, all routers other than Router RTC have the DoNotAge
            bit set in Router RTC's router-LSA; this removes the need
            for Router RTC to refresh its router-LSA over the demand
            circuit.

        Time T2: Hello traffic ceases

            After the Database Exchange Process has completed, no Hellos
            are sent over the demand circuit. If there is no application
            data to be sent over the demand circuit, the circuit will be
            idle.

        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 will be
            cleared) in order to save connect charges. This will be
            transparent to the OSPF routing; no LSAs or routing table
            entries will change as a result.




                                          LS age
             LSA                in RTB        in RTC
             ______________________________________________
             RTA's Router-LSA   1000          DoNotAge+1001
             RTB's Router-LSA   10            DoNotAge+11
             RTC's Router-LSA   DoNotAge+11   10


                    Table 1: LS age fields on either
                       side of the demand circuit





Moy                                                            [Page 12]


Internet Draft         OSPF over Demand Circuits                May 1994


        Time T4: Router RTA's LSA is refreshed

            At some point Router RTA will refresh its own router-LSA
            (i.e., when the LSA's LS age hits LSRefreshInterval). This
            refresh will be flooded to Router RTB, who will look at it
            and decide NOT to flood it over the demand circuit to Router
            RTC, because the LSA's contents have not really changed
            (only the LS Sequence Number). At this point, the LS
            sequence numbers that the routers have for RTA's router-LSA
            differ depending on which side of the demand circuit the
            routers lie. Because there is still no application traffic,
            the underlying data-link connection remains disconnected.

        Time T5: Router RTA's LAN interface comes up

            When Router RTA's LAN interface (connecting to Host H1)
            comes up, RTA will originate a new router-LSA. This router-
            LSA WILL be flooded over the demand circuit because its
            contents have now changed. The underlying data-link
            connection will have to be brought up to flood the LSA.
            After flooding, routers on both sides of the demand circuit
            will again agree on the LS Sequence Number for RTA's
            router-LSA.

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

            Assuming that there is still no application traffic
            transiting the demand circuit, the underlying data-link
            connection will again be torn down after some period of
            inactivity.

        Time T7: File transfer started between Hosts H1 and H2

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

        Time T8: Physical link becomes inoperative

            If an indication is received from the data-link or physical
            layers indicating that the demand circuit can no longer be
            established, Routers RTB and RTC declare their point-to-
            point interfaces down, and originate new router-LSAs. Both
            routers will attempt to bring the connection back up by
            sending Hellos at the reduced rate of PollInterval. Note
            that while the connection is inoperative, Routers RTA and
            RTB will continue to have an old router-LSA for RTC in their
            link state database, and this LSA will not age out because



Moy                                                            [Page 13]


Internet Draft         OSPF over Demand Circuits                May 1994


            it has the DoNotAge bit set. However, according to Section
            2.2 they will flush Router RTC's router-LSA if the demand
            circuit remains inoperative for longer than MaxAge.

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

        This example demonstrates the demand circuit functionality when
        both demand circuits and non-demand circuits (e.g., leased
        lines) are used to interconnect regions of an internetwork. Such
        an internetwork is shown in Figure 3. Host H1 can communicate
        with Host H2 either over the demand link between Routers RTB and
        RTC, or over the leased line between Routers RTB and RTD.

        Because the basic properties of the demand circuit functionality
        were presented in the previous example, this example will only
        address the unique issues involved when using both demand and
        non-demand circuits in parallel.

        Assume that Routers RTB and RTY are powered off, but that all
        other routers and their attached links are both operational and
        implement the demand circuit modifications to OSPF. Throughout
        the example, a TCP connection between Hosts H1 and H2 is
        transmitting data. Furthermore, assume that the cost of the
        demand circuit from RTB to RTC has been set considerably higher
        than the cost of the leased line between RTB and RTD; for this
        reason traffic between Hosts H1 and H2 will always be sent over
        the leased line when it is operational.

        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 the copies of the RTA
            and RTB router-LSAs contained in their database. This
            depends on whether the LSAs sent over the demand link reach
            the routers before those sent over the leased line. One
            possibility is pictured in Table 2.





Moy                                                            [Page 14]


Internet Draft         OSPF over Demand Circuits                May 1994




                                             +
                                      +---+  |
                                      |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 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.
























Moy                                                            [Page 15]


Internet Draft         OSPF over Demand Circuits                May 1994


                                          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, 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, 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, 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, LS age fields
                    on the right side of Router RTB.

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




Moy                                                            [Page 16]


Internet Draft         OSPF over Demand Circuits                May 1994


            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 operational, 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. At this point, 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 flushed
            (by router RTE in our example).  Because this flushed LSA
            constitutes a real change (see Section 3.4), it is flooded
            over the demand circuit from Router RTC to RTB. There are
            then two possible scenarios. First, the LS Sequence numbers
            for RTA's router-LSA may have diverged on either 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 3.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 advertisement.





Moy                                                            [Page 17]


Internet Draft         OSPF over Demand Circuits                May 1994


            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 does 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).

    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 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.

        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



Moy                                                            [Page 18]


Internet Draft         OSPF over Demand Circuits                May 1994




                                                 +  +--+
                                          +---+  |--|H3|
                                +---------|RT2|--|  +--+
                               /          +---+  |
                              / ODL              +
                +--+  +      /
                |H1|--|     /                    +
                +--+  |  +---+    ODL     +---+  |
                      |--|RT1|------------|RT3|--|
                      |  +---+            +---+  |
                      |      \                   +
                      +       \ODL
                               \                 +  +--+
                                \         +---+  |--|H2|
                                 +--------|RT4|--|  +--+
                                          +---+  |
                                                 +


                     Figure 4: Behavior when not all
                        of the demand circuits' data-
                        link connections can be opened
                                at once.


            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 opened 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 the
            last paragraph of Section 1). This means that the routing
            will not detect the unreachability of H4 until a data-link
            connection on RT1 becomes available.

        Increasing the OSPF cost of demand circuits that are currently
        discarding application packets, due to underlying data-link
        shortage, may help the routing find paths that can actually



Moy                                                            [Page 19]


Internet Draft         OSPF over Demand Circuits                May 1994


        deliver the packets. This however would create more routing
        traffic, and is an issue for future study.

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.3), 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,
        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



Moy                                                            [Page 20]


Internet Draft         OSPF over Demand Circuits                May 1994


        networks containing demand circuits.


















































Moy                                                            [Page 21]


Internet Draft         OSPF over Demand Circuits                May 1994


    A. The 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 if
    and only if it supports the functionality defined in Section 3 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 network as a demand circuit (see Section 3.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].



Moy                                                            [Page 22]


Internet Draft         OSPF over Demand Circuits                May 1994


    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. Its setting in LSAs is
        described in Section 2.3.

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).

    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 (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 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 for more
        information on processing the DoNotAge bit.
















Moy                                                            [Page 23]


Internet Draft         OSPF over Demand Circuits                May 1994


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.

    [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.

Security Considerations

    Security issues are not discussed in this memo.

Author's Address

    John Moy
    Proteon, Inc.
    9 Technology Drive
    Westborough, MA 01581

    Phone: 508-898-2800
    Fax:   508-898-3176
    Email: jmoy@proteon.com

    This document expires in November 1994.










Moy                                                            [Page 24]