Skip to main content

OSPF Refresh and Flooding Reduction in Stable Topologies
draft-pillay-esnault-ospf-flooding-07

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4136.
Author Padma Pillay-Esnault
Last updated 2018-12-20 (Latest revision 2003-06-17)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4136 (Informational)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Bill Fenner (ˢˣˠ)
Send notices to <rohit@utstar.com>, <john.moy@sycamorenet.com>
draft-pillay-esnault-ospf-flooding-07
Network Working Group                               Padma Pillay-Esnault
Internet Draft                                          Juniper Networks
                                                               June 2003
Category: Informational
Expires: December 2003                                          

         OSPF Refresh and Flooding Reduction in Stable Topologies

                draft-pillay-esnault-ospf-flooding-07.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
              http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
              http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

1. Abstract

   This document describes an extension to the OSPF protocol to 
   reduce periodic flooding of Link State Advertisements in 
   stable topologies.

   The OSPF current behavior requires that all LSAs other than DoNotAge
   LSAs to be refreshed every 30 minutes. This document proposes to
   generalize the use of DoNotAge LSAs to reduce protocol traffic in
   stable topologies
   
Pillay-Esnault                                                  [Page 1]
Internet Draft       OSPF Refresh and Flooding Reduction      March 2003

2. Motivation

   The explosive growth of IP based networks has placed focus on the 
   scalability of Interior Gateway Protocols such as OSPF. Networks 
   using OSPF are growing every day and will continue to expand to 
   accommodate the demand for connections to the Internet or intranets.
  
   Internet Service Providers and users having large networks have 
   noticed non-negligible protocol traffic even when their network 
   topologies were stable.

   OSPF requires every LSA to be refreshed every 1800 seconds or else 
   they will expire when they reach 3600 seconds [1].

   This document proposes to overcome the LSA expiration by generalizing
   the use of DoNotAge LSAs. This technique will facilitate OSPF 
   scaling by reducing OSPF traffic overhead in stable topologies.
   
   
3. Changes in the existing implementation.
   
   This enhancement relies on the implementation of the DoNotAge bit
   and the Indication-LSA. The details of the implementation of 
   the DoNotAge bit and the Indication-LSA are specified in 
   "Extending OSPF to Support Demand Circuits" [2].
   
   Flooding reduction capable routers will continue to send hellos 
   to their neighbors and keep aging their self-originated LSAs in 
   their database. However, they will flood their self-originated LSAs
   with the DoNotAge bit set. Hence, self-originated LSAs do not
   have to be reflooded every 30 minutes and the reflooding interval
   can be extended to the configured forced flooding interval.
   As in normal OSPF operation, any change in the contents of the LSA
   will cause a reoriginated LSA to be flooded with the DoNotAge bit
   set. This will reduce protocol traffic overhead while allowing
   changes to be flooded immediately.

   Flooding reduction capable routers will flood received
   non-self-originated LSAs with the DoNotAge bit set on all normal
   or flooding-reduction only interfaces within the LSA's flooding 
   scope. If an interface is configured both as flooding-reduction 
   capable and Demand-Circuit then the flooding is done if and only if 
   the contents of the LSA have changed. This allows LSA flooding for 
   unchanged LSAs to be periodically forced by the originating router.

Pillay-Esnault                                                  [Page 2]
Internet Draft       OSPF Refresh and Flooding Reduction      March 2003

4. Backward Compatibility

   Routers supporting the demand circuit extensions [2] will be
   able to correctly process DoNotAge LSAs flooded by routers
   supporting the flooding reduction capability described herein.
   These routers will also suppress flooding DoNotAge LSAs on 
   interfaces configured as demand circuits. However, they will also
   flood DoNotAge LSAs on interfaces which are not configured as 
   demand circuits. 

   When there are routers in the OSPF routing domain, stub area,
   or NSSA area that do not support the demand circuit extensions [2]
   then the use of these flooding reduction capability will be 
   subject to the demand circuit interoperability constraints 
   articulated in section 2.5 of "Extending OSPF to Support Demand 
   Circuits" [2]. This implies that detection of an LSA with the DC 
   bit clear will result in the re-origination of self-originated 
   DoNotAge LSAs with the DoNotAge clear and purging of 
   non-self-originated DoNotAge LSAs.

5. Security Considerations

   This memo does not create any new security issues for the OSPF
   protocol. Security considerations for the base OSPF protocol are
   covered in [1].

   
6. Intellectual Property Considerations

   The IETF has been notified by Cisco Systems of intellectual property
   rights claimed in regard to some or all of the specifications 
   contained in this document. For more information please refer to the 
   IETF web page http://www.ietf.org/ietf/IPR/CISCO-OSPF-REFRESH.txt

7. Acknowledgments

   The author would like to thank Jean-Michel Esnault, Barry Friedman,
   Thomas Kramer, Acee Lindem, Peter Psenak, Henk Smit and Alex Zinin 
   for their helpful comments on this work.

8. Normative References

   [1] RFC 2328 OSPF Version 2. J. Moy. April 1998.
   [2] RFC 1793 Extending OSPF to Support Demand Circuits. J. Moy. 
   April 1995.

Pillay-Esnault                                                  [Page 3]
Internet Draft       OSPF Refresh and Flooding Reduction      March 2003

A. Configurable Parameters

   This memo defines new configuration parameters for the flooding 
   reduction feature. The feature must be enabled by configuration 
   on a router and is by default off.

    flooding-reduction <all | list of interfaces>
       Indicates that the router has flooding reduction feature
       enabled. By default, it applies to all interfaces running
       under the OSPF instance to which it applies. The feature
       can be enabled on a subset of explicitly specified interfaces.

    flooding-interval <n minutes>
       Indicates the interval in minutes for the periodic flooding
       of self-originated LSAs. By default this value is 
       30 minutes as per [1]. The minimum value is also 30 minutes. 
       A value of infinity will prevent reflooding of self-originated 
       LSAs that have not changed. 

Pillay-Esnault                                                  [Page 4]
Internet Draft       OSPF Refresh and Flooding Reduction      March 2003

9. Authors' Addresses

   Padma Pillay-Esnault
   Juniper Networks
   1194 N, Mathilda Avenue
   Sunnyvale, CA 94089-1206

   Email: padma@juniper.net

Pillay-Esnault                                                  [Page 5]