datatracker.ietf.org
Sign in
Version 5.6.4.p1, 2014-10-20
Report a bug

Extending OSPF to Support Demand Circuits
RFC 1793

Document type: RFC - Proposed Standard (April 1995; No errata)
Updated by RFC 3883
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Document shepherd: No shepherd assigned

IESG State: RFC 1793 (Proposed Standard)
Responsible AD: (None)
Send notices to: No addresses provided

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 ospf@gated.cornell.edu.

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

[include full document text]