rfc1793.txt

RFC 的详细文档！

Network Working Group                                             J. Moy
Request for Comments: 1793                                       Cascade
Category: Standards Track                                     April 1995


               Extending OSPF to Support Demand Circuits

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

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

   Demand circuits and regular network segments (e.g., leased lines) 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 connections remain
   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-



Moy                                                             [Page 1]

RFC 1793               OSPF over Demand Circuits              April 1995


   to-MultiPoint Interface).

   This memo provides functionality similar to that specified for RIP in
   [2], with the main difference being the way the two proposals handle
   oversubscription (see Sections 4.3 and 7 below).  However, because
   OSPF employs link-state routing technology as opposed to RIP's
   Distance Vector base, the mechanisms used to achieve the demand
   circuit functionality are quite different.

   Please send comments to [e-mail].

Acknowledgments

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

Table of Contents

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



Moy                                                             [Page 2]

RFC 1793               OSPF over Demand Circuits              April 1995


            Security Considerations ............................... 32
            Author's Address ...................................... 32

1.  Model for demand circuits

   In this memo, demand circuits refer to those network segments whose
   cost depends on either connect time 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). When/if the data-link connection is established, the data is
   sent, and the 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
   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 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 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.





Moy                                                             [Page 3]

RFC 1793               OSPF over Demand Circuits              April 1995


   Either end of a demand circuit may attempt to open the data-link
   connection. When both ends attempt to open the connection
   simultaneously, there is the possibility of call collision. Not all
   data-links specify how call collisions are handled. Also, while OSPF
   requires that all periodic timers be randomized to avoid
   synchronization (see Section 4.4 of [1]), if call attempts are
   strictly data-driven there may still be insufficient spacing of call
   attempts to avoid collisions on some data-links. For these reasons,
   for those data-links without collision detection/avoidance support,
   it is suggested (but not specified herein) that an exponential
   backoff scheme for call retries be employed at the data-link layer.
   Besides helping with call collisions, such a scheme could minimize
   charges (if they exist) for failed call attempts.

   As a result of the physical implementation of some demand circuits,
   only one end of the circuit may be capable of opening the data-link
   connection. For example, some async modems can initiate calls, but
   cannot accept incoming calls. In these cases, since connection
   initiation in this memo is data-driven, care must be taken to ensure
   that the initiating application party is located at the calling end
   of the demand circuit.

2.  Modifications to all OSPF routers

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

   2.1.  The OSPF Options field

      A new bit is added to the OSPF Options field to support the demand
      circuit extensions. This bit is called the "DC-bit". The resulting
      format of the Options field is described in Appendix A.

      A router implementing the functionality described in Section 2 of
      this memo sets the DC-bit in the Options field of all LSAs that it
      originates. This is regardless of the LSAs' LS type, and also
      regardless of whether the router implements the more substantial
      modifications required of demand circuit endpoints (see Section
      3).  Setting the DC-bit in self-originated LSAs tells the rest of
      the routing domain that the router can correctly process DoNotAge
      LSAs (see Sections 2.2, 2.3 and 2.5).

      There is a single exception to the above rule. A router
      implementing Section 2 of this memo may sometimes originate an
      "indication-LSA"; these LSAs always have the DC-bit clear.
      Indication-LSAs are used to convey across area boundaries the



Moy                                                             [Page 4]

RFC 1793               OSPF over Demand Circuits              April 1995


      existence of routers incapable of DoNotAge processing; see Section
      2.5.1 for details.

   2.2.  The LS age field

      The semantics of the LSA's LS age field are changed, allowing the
      high bit of the LS age field to be set. 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 bit set as "DoNotAge+x", while an LS
      age expressed as just "x" is assumed 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 must have their DoNotAge
      bits masked off.  For example, in determining which LSA is more
      recent, LS ages of 1 and DoNotAge+1 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. In
      particular, DoNotAge+MaxAge is equivalent to MaxAge; however for
      backward-compatibility the MaxAge form should always be used 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 an interface, the constant
      InfTransDelay is added to the LSA's LS age field. This happens
      even if the DoNotAge bit is set; in this case the LS age field is
      not allowed to exceed DoNotAge+MaxAge. If the LS age field reaches
      DoNotAge+MaxAge during flooding, the LSA is flushed from the
      routing domain. This preserves the protection in [1] afforded
      against flooding loops.