One document matched: draft-pillay-esnault-ospf-flooding-01.txt

Differences from draft-pillay-esnault-ospf-flooding-00.txt

Network Working Group                              Padma Pillay-Esnault
Internet Draft                                            Cisco Systems
Expiration Date:Nov 2000                                  November 1999

         OSPF Refresh and flooding reduction in stable topologies

                draft-pillay-esnault-ospf-flooding-01.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 behaviour 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-00.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 accomodate the demand to connect to the Internet or intranets.
   
   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 mins to around 50 mins 
   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 LSA will now be flooded
   with the higher bit set thus making them DO NOT AGE LSA. 

   Unlike in the implementation of DC, there is no suppression of hellos
   between adjacent neighbors. The objective being reduced overhead but fast
   convergence and recovery is primordial in case there is a change in the 
   topology.
   
   The suppression of hellos will delay the knowledge that the neighbor is 
   down. By keeping the hellos, the routers are fully aware of their neighbor
   states after the DEAD timer interval at the most.


   















Pillay-Esnault                                                  [Page 2]




Internet Draft   draft-pillay-esnault-ospf-flooding-00.txt  November 1999


4. Deployment

   All routers supporting OSPF Demand Circuit will be able to have no problem
   to interact with the routers supporting the flooding reduction. 

   There are two possibilities :

   (1) The routers supporting DC but do not have the Flooding Reduction 
   enhancement are NOT configured to run as DC on their links with 
   the routers supporting the Flooding Reduction Enhancement (FRE). In this
   case, the older implementation will send its LSA without the DNA bit
   set and will need to refresh its LSA periodically. It will however
   receive DNA LSA from the FRE routers and will keep them as such in its
   own database.
  
   (2) The routers supporting DC but do not have the Flooding Reduction 
   enhancement are configured to run as DC on their links with the routers 
   supporting the Flooding Reduction Enhancement (FRE). All peers will 
   set the DNA age on their own LSA and will suppression hellos. The FRE 
   routers will run as DC as well.

   
   All routers that do not support OSPF Demand Circuit Feature have no
   knowledge how to handle DNA LSA and these will appear as expired LSA
   in their own database. The DCbitless LSA will be used here to detect 
   the presence of routers not supporting the DC and indication LSA will be
   us in a similar manner as in [2] to inform other routers of the presence
   of routers incapable to handle DNA LSA. All the DNA LSA will be flushed
   and only aging LSA will then be sent.

   The interoperability with routers not supporting DNA LSA implies that
   they are in a stub area for the FRE routers to perform the flooding 
   Reduction. The flooding scope of the type 5 LSA introduces this 
   constraint.                .


5. Configuration of the FRE routers   
   
   
   The FRE routers will have the possibility either to act globally on all
   its OSPF interfaces or to implement flooding reduction only on some of its
   interfaces. This will give a greater ease in its deployment and a greater
   liberty as to how the user want to shape the refreshing its their topology.



6. Lost Functionality

   The enhancement rely heavily on the Demand Circuit mechanism and come at 
   the same costs. The reduction of OSPF traffic will have an impact on the 
   robustness and database checksum as described in [2] section 6.
   





Pillay-Esnault                                                  [Page 3]





Internet Draft   draft-pillay-esnault-ospf-flooding-00.txt  November 1999


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

8. 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)


9. Authors' Addresses

   Padma Pillay-Esnault
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   Email: ppe@cisco.com
   Voice: +1 408 526 6640



































Pillay-Esnault                                                  [Page 4]