Extending OSPF to Support Demand Circuits
RFC 1793
Document | Type |
RFC - Proposed Standard
(April 1995; No errata)
Updated by RFC 3883
|
|
---|---|---|---|
Author | John Moy | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1793 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 5. Topology recommendations .............................. 25 6. Lost functionality .................................... 25 7. Future work: Oversubscription ......................... 26Show full document text