Network Working Group                              Padma Pillay-Esnault
Internet Draft                                         Juniper Networks
Expiration Date:June 2001                                  December 2000

         
OSPF Refresh and flooding reduction in stable topologies


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

Status

   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.



1. Abstract


   This document describes extension to the OSPF protocol [1] to
   optimize flooding of Link State Advertisements (LSA) in stable
   topologies.

   The current behavior of OSPF requires that all LSA be refreshed
   every 30 minutes regardless of the stability of the network except
   for Do Not Age (DNA) LSA [2]. This document proposes to generalize
   the use of DNA LSA so as to reduce protocol traffic in stable
   networks.














Pillay-Esnault                                                 [Page 1]
Internet Draft   draft-pillay-esnault-ospf-flooding-03.txt  November 1999



2. Motivation


   The explosive growth of IP based networks has placed the focus on the
   scalability of the Interior Gateway Protocols such as OSPF. The
   networks using OSPF are larger everyday and will continue to expand
   to accommodate the demand to connect to the Internet or intra nets.

   Internet Service Providers and users having large networks have
   noticed of a non negligible protocol traffic even when their network
   topology was stable.

   By design OSPF requires LSA to be refreshed as they expire after
   3600 seconds. Some implementations have tried to improve the flooding
   by reducing its frequency to refresh from 30 minutes to around 50 minutes
   or so. This solution presents the advantage of cutting down the amount
   of refresh traffic but will require at least one refresh before the LSA
   expires.

   This document proposes to overcome the LSA expiration by implementing
   the generalization of DO NOT AGE LSA use. By reducing considerably the
   traffic overhead in stable topologies OSPF will scale better.



3. Changes in the existing implementation.


   The existing OSPF Demand Circuit feature [2] provides the premise of the
   Do Not Age LSA implementation.

   The goal here is to reduce refreshing and flooding of already known
   and unchanged information. To achieve this, the Link State Advertisements
   will now be flooded over all interfaces with the higher bit set thus
   making them DO NOT AGE LSAs.

   The LSA originator can then set the refresh rate to what ever it
   is configured to. It can be configured for periodic refresh over
   extended periods (days, weeks or months) or even never at all.

   All the routers should implement the DoNotAge bit as defined by
   Section 2 of RFC 1793.



4. 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 [Ref1].

   The enhancement rely heavily on the Demand Circuit mechanism and come at
   the same costs as described in [2] section 6.


Pillay-Esnault                                                  [Page 2]
Internet Draft   draft-pillay-esnault-ospf-flooding-03.txt  November 1999




5. Acknowledgments


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


6. References


   [1] RFC 2328 OSPF Version 2. J. Moy. April 1998. (Format: TXT=447367
   bytes) (Obsoletes RFC2178) (Also STD0054) (Status: STANDARD)

   [2] RFC 1793 Extending OSPF to Support Demand Circuits. J. Moy.
   April 1995. (Format: TXT=78728 bytes) (Status: PROPOSED STANDARD)



7. Authors' Addresses


   Padma Pillay-Esnault
   Juniper Networks
   1194 N, Mathilda Avenue
   Sunnyvale, CA 94089-1206
   Email: padma@juniper.net



























Pillay-Esnault                                                  [Page 3]