[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 RFC 4136

Network Working Group                               Padma Pillay-Esnault
Internet Draft                                          Juniper Networks
                                                              March 2003

Expires: October 2003


         OSPF Refresh and Flooding Reduction in Stable Topologies

                draft-pillay-esnault-ospf-flooding-05.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
   eliminate or reduce periodic flooding of Link State Advertisements
   in stable topologies.

   The current behavior of OSPF requires that all LSAs be refreshed
   every 30 minutes regardless of the stability of the network except
   for DoNotAge LSAs. 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 heavily on the OSPF Demand Circuit extension.
   The details of the implementation of the DC-bit, DoNotAge bit and
   the Indication-LSA are specified in "Extending OSPF to Support
   Demand Circuits" [2].

   The flooding reduction capable routers will continue to send hellos
   to their neighbors and keep their aging self-originated LSAs in
   their database. However, they will flood their self-originated LSAs
   with the DoNotAge bit set. Hence, self-originated LSAs need not be
   reflooded unless there is change in the contents of the LSA. This
   will reduce the protocol traffic overhead while allowing changes to
   be flooded immediately.

















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 DoNotLSAs 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. Configuration of the flooding reduction capable routers

   Implementations of this flooding reduction capability must provide a
   knob to activate/deactivate the feature and by default it should be
   disabled. The flooding reduction capability can be enabled globally
   or on selected interfaces. It should be also possible to specify a
   forced flooding interval of unchanged self-originated LSAs.


6. 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].














Pillay-Esnault                                                  [Page 3]

Internet Draft       OSPF Refresh and Flooding Reduction      March 2003


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.


9. Authors' Addresses

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

   Email: padma@juniper.net


























Pillay-Esnault                                                  [Page 4]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/