rfc1765.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                             J. Moy
Request for Comments: 1765                                       Cascade
Category: Experimental                                        March 1995


                         OSPF Database Overflow

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   Proper operation of the OSPF protocol requires that all OSPF routers
   maintain an identical copy of the OSPF link-state database.  However,
   when the size of the link-state database becomes very large, some
   routers may be unable to keep the entire database due to resource
   shortages; we term this "database overflow". When database overflow
   is anticipated, the routers with limited resources can be
   accommodated by configuring OSPF stub areas and NSSAs. This memo
   details a way of gracefully handling unanticipated database
   overflows.

   This memo is a product of the OSPF Working Group. Please send
   comments to [e-mail].

Table of Contents

   1.       Overview ............................................... 2
   2.       Implementation details ................................. 3
   2.1      Configuration .......................................... 3
   2.2      Entering OverflowState ................................. 4
   2.3      Operation while in OverflowState ....................... 5
   2.3.1    Modifications to Flooding .............................. 5
   2.3.2    Originating AS-external-LSAs ........................... 6
   2.3.3    Receiving self-originated LSAs ......................... 6
   2.4      Leaving OverflowState .................................. 6
   3.       An example ............................................. 6
   4.       Administrative response to database overflow ........... 7
   5.       Operational experience ................................. 8
   6.       Possible enhancements .................................. 8
   A.       Related MIB parameters ................................  8
            References ............................................  9
            Security Considerations ...............................  9
            Author's Address ......................................  9



Moy                                                             [Page 1]

RFC 1765                 OSPF Database Overflow               March 1995


1.  Overview

   OSPF requires that all OSPF routers within a single area maintain an
   identical copy of the OSPF link-state database.  However, when the
   size of the link-state database becomes very large, some routers may
   be unable to keep the entire database due to resource shortages; we
   term this "database overflow". For example, a regional network may
   have a very large OSPF database because it is importing a large
   number of external routes into OSPF. Unless database overflow is
   handled correctly, routers will end up with inconsistent views of the
   network, possibly leading to incorrect routing.

   One way of handling database overflow is to encase routers having
   limited resources within OSPF stub areas (see Section 3.6 of [1]) or
   NSSAs ([2]).  AS-external-LSAs are omitted from these areas' link-
   state databases, thereby controlling database size.

   However, unexpected database overflows cannot be handled in the above
   manner.  This memo describes a way of dynamically limiting database
   size under overflow conditions. The basic mechanism is as follows:

    (1) A parameter, ospfExtLsdbLimit, is configured in each router
        indicating the maximum number of AS-external-LSAs (excluding
        those describing the default route) that are allowed in the
        link-state database. This parameter must be the same in all
        routers in the routing domain (see Section 2.1); synchronization
        of the parameter is achieved via network management.

    (2) In any router's database, the number of AS-external-LSAs
        (excluding default) is never allowed to exceed ospfExtLsdbLimit.
        If a router receives a non-default AS-external-LSA that would
        cause the limit of ospfExtLsdbLimit to be exceeded, it drops the
        LSA and does NOT acknowledge it.

    (3) If the number of non-default AS-external-LSAs in a router's
        database hits ospfExtLsdbLimit, the router a) flushes all non-
        default AS-external-LSAs that it has itself originated (see
        Section 2.2) and b) goes into "OverflowState".

    (4) While in OverflowState, the router refuses to originate any
        non-default AS-external-LSAs (see Section 2.3.2).

    (5) Optionally, the router can attempt to leave OverflowState after
        the configurable parameter ospfExitOverflowInterval has elapsed
        since entering OverflowState (see Section 2.4). Only at this
        point can the router resume originating non-default AS-
        external-LSAs.




Moy                                                             [Page 2]

RFC 1765                 OSPF Database Overflow               March 1995


   The reason for limiting non-default AS-external-LSAs, but not other
   LSA types, is twofold. First of all, the non-default AS-external LSAs
   are the most likely to dominate database size in those networks with
   huge databases (e.g., regional networks; see [5]). Second, the non-
   default AS-external-LSAs can be viewed as "optional" in the following
   sense: the router can probably be monitored/reconfigured without
   them. (However, using similar strategies, other LSA types can also be
   limited; see Section 5.)

   The method of dealing with database overflow described herein has the
   following desirable properties:

    o   After a short period of convergence, all routers will have
        identical link-state databases. This database will contain less
        than ospfExtLsdbLimit non-default AS-external-LSAs.

    o   At all times, routing WITHIN the OSPF Autonomous System will
        remain intact. Among other things, this means that the routers
        will continue to be manageable.

    o   Default routing to external destinations will also remain
        intact. This hopefully will mean that a large amount of external
        connectivity will be preserved, although possibly taking less
        efficient routes.

    o   If parameter ospfExitOverflowInterval is configured, the OSPF
        system will recover fully and automatically (i.e., without
        network management intervention) from transient database
        overflow conditions (see Section 2.4).

2.  Implementation details

   This section describes the mechanism for dealing with database
   overflow in more detail. The section is organized around the concept
   OverflowState, describing how routers enter the OverflowState, the
   operation of the router while in OverflowState, and when the router
   leaves OverflowState.

   2.1.  Configuration

      The following configuration parameters are added to support the
      database overflow functionality. These parameters are set by
      network management.

        ospfExtLsdbLimit
            When the number of non-default AS-external-LSAs in a
            router's link-state database reaches ospfExtLsdbLimit, the
            router enters OverflowState. The router never holds more



Moy                                                             [Page 3]

RFC 1765                 OSPF Database Overflow               March 1995


            than ospfExtLsdbLimit non-default AS-external-LSAs in its
            database.

            ospfExtLsdbLimit MUST be set identically in all routers
            attached to the OSPF backbone and/or any "regular" OSPF
            area. (This memo does not pertain to routers contained
            within OSPF stub areas nor NSSAs, since such routers do not
            receive AS-external-LSAs.) If ospfExtLsdbLimit is not set
            identically in all routers, then when the database
            overflows: 1) the routers will NOT converge on a common
            link-state database, 2) incorrect routing, possibly
            including routing loops, will result and 3) constant
            retransmission of AS-external-LSAs will occur. Identical
            setting of ospfExtLsdbLimit is achieved/ensured by network
            management.

            When ospfExtLsdbLimit is set in a router, the router must
            have some way to guarantee that it can hold that many non-
            default AS-external-LSAs in its link-state database. One way
            of doing this is to preallocate resources (e.g., memory) for
            the configured number of LSAs.

        ospfExitOverflowInterval
            The number of seconds that, after entering OverflowState, a
            router will attempt to leave OverflowState. This allows the
            router to again originate non-default AS-external-LSAs. When
            set to 0, the router will not leave OverflowState until
            restarted. The default setting for ospfExitOverflowInterval
            is 0.

            It is not necessary for ospfExitOverflowInterval to be
            configured the same in all routers. A smaller value may be
            configured in those routers that originate the "more
            important" AS-external-LSAs. In fact, setting
            ospfExitOverflowInterval the same may cause problems, as
            multiple routers attempt to leave OverflowState
            simultaneously. For this reason, the value of
            ospfExitOverflowInterval must be "jittered" by randomly
            varying its value within the range of plus or minus 10
            percent before using.

   2.2.  Entering OverflowState

      The router enters OverflowState when the number of non-default
      AS-external-LSAs in the database hits ospfExtLsdbLimit. There are
      two cases when this can occur. First, when receiving an LSA during
      flooding. In this case, an LSA which does not already have a
      database instance is added in Step 5 of Section 13 of [1].  The



Moy                                                             [Page 4]

RFC 1765                 OSPF Database Overflow               March 1995


      second case is when the router originates a non-default AS-
      external-LSA itself.

      Whenever the router enters OverflowState it flushes all non-
      default AS-external-LSAs that it itself had originated. Flushing
      is accomplished through the premature aging scheme described in
      Section 14.1 of [1].  Only self-originated LSAs are flushed; those
      originated by other routers are kept in the link-state database.

   2.3.  Operation while in OverflowState

      While in OverflowState, the flooding and origination of non-
      default AS-external-LSAs are modified in the following fashion.

      2.3.1.  Modifications to Flooding

         Flooding while in OverflowState is modified as follows. If in
         Step 5 of Section 13 of [1], a non-default AS-external-LSA has
         been received that a) has no current database instance and b)
         would cause the count of non-default AS-external-LSAs to exceed
         ospfExtLsdbLimit, then that LSA is discarded. Such an LSA is
         not installed in the link-state database, nor is it
         acknowledged.