rfc1793.txt

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

RFC 1793               OSPF over Demand Circuits              April 1995


      self-originated LSAs should never have the DoNotAge bit set in its
      own database. This means that in any case the router's self-
      originated LSAs will be refreshed every LSRefreshInterval.  As
      this refresh is flooded throughout the OSPF routing domain, it
      will replace any LSA copies in other routers' databases whose
      DoNotAge bits were mistakenly set.

   2.3.  Removing stale DoNotAge LSAs

      Because LSAs with the DoNotAge bit set are never aged, they can
      stay in the link state database even when the originator of the
      LSA no longer exists. To ensure that these LSAs are eventually
      flushed from the routing domain, and that the size of the link
      state database doesn't grow without bound, routers are required to
      flush a DoNotAge LSA if BOTH of the following conditions are met:

        (1) The LSA has been in the router's database for at least
            MaxAge seconds.

        (2) The originator of the LSA has been unreachable (according to
            the routing calculations specified by Section 16 of [1]) for
            at least MaxAge seconds.

      For an example, see Time T8 in the example of Section 4.1. Note
      that the above functionality is an exception to the general OSPF
      rule that a router can only flush (i.e., prematurely age; see
      Section 14.1 of [1]) its own self-originated LSAs. The above
      functionality pertains only to DoNotAge LSAs. An LSA having
      DoNotAge clear still can be prematurely aged only by its
      originator; otherwise, the LSA must age naturally to MaxAge before
      being removed from the routing domain.

      An interval as long as MaxAge has been chosen to avoid any
      possibility of thrashing (i.e., flushing an LSA only to have it
      reoriginated soon afterwards). Note that by the above rules, a
      DoNotAge LSA will be removed from the routing domain no faster
      than if it were being aged naturally (i.e., if DoNotAge were not
      set).

2.4.  A change to the flooding algorithm

      The following change is made to the OSPF flooding algorithm.  When
      a Link State Update Packet is received that contains an LSA
      instance which is actually less recent than the the router's
      current database copy, the router must now process the LSA as
      follows (modifying Step 8 of Section 13 in [1] accordingly):





Moy                                                             [Page 6]

RFC 1793               OSPF over Demand Circuits              April 1995


        o   If the database copy has LS age equal to MaxAge and LS
            sequence number equal to MaxSequenceNumber, simply discard
            the received LSA without acknowledging it. (In this case,
            the LSA's sequence number is wrapping, and the
            MaxSequenceNumber LSA must be completely flushed before any
            new LSAs can be introduced). This is identical to the
            behavior specified by Step 8 of Section 13 in [1].

        o   Otherwise, send the database copy back to the sending
            neighbor, encapsulated within a Link State Update Packet. In
            so doing, do not put the database copy of the LSA on the
            neighbor's link state retransmission list, and do not
            acknowledge the received (less recent) LSA instance.

      This change is necessary to support flooding over demand circuits.
      For example, see Time T4 in the example of Section 4.2.

      However, this change is beneficial when flooding over non-demand
      interfaces as well. For this reason, the flooding change pertains
      to all interfaces, not just interfaces to demand circuits. The
      main example involves MaxAge LSAs. There are times when MaxAge
      LSAs stay in a router's database for extended intervals: 1) when
      they are stuck in a retransmission queue on a slow link or 2) when
      a router is not properly flushing them from its database, due to
      software bugs. The prolonged existence of these MaxAge LSAs can
      inhibit the flooding of new instances of the LSA. New instances
      typically start with the initial LS sequence number, and are
      treated as less recent (and hence discarded) by routers still
      holding MaxAge instances. However, with the above change to
      flooding, a router with a MaxAge instance will respond back with
      the MaxAge instance. This will get back to the LSA's originator,
      which will then pick the next highest LS sequence number and
      reflood, overwriting the MaxAge instance.

      This change will be included in future revisions of the base OSPF
      specification [1].

   2.5.  Interoperability with unmodified OSPF routers

      Unmodified OSPF routers will probably treat DoNotAge LSAs as if
      they had LS age of MaxAge. At the very worst, this will cause
      continual retransmissions of the DoNotAge LSAs. (An example
      scenario follows. Suppose Routers A and B are connected by a
      point-to-point link. Router A implements the demand circuit
      extensions, Router B does not. Neither one treats their connecting
      link as a demand circuit. At some point in time, Router A receives
      from another neighbor via flooding a DoNotAge LSA. The DoNotAge
      LSA is then flooded by Router A to Router B.  Router B, not



Moy                                                             [Page 7]

RFC 1793               OSPF over Demand Circuits              April 1995


      understanding DoNotAge LSAs, treats it as a MaxAge LSA and
      acknowledges it as such to Router A. Router A receives the
      acknowledgment, but notices that the acknowledgment is for a
      different instance, and so starts retransmitting the LSA.)

      However, to avoid this confusion, DoNotAge LSAs will be allowed in
      an OSPF area if and only if, in the area's link state database,
      all LSAs have the DC-bit set in their Options field (see Section
      2.1). Note that it is not required that the LSAs' Advertising
      Router be reachable; if any LSA is found not having its DC-bit set
      (regardless of reachability), then the router should flush (i.e.,
      prematurely age; see Section 14.1 of [1]) from the area all
      DoNotAge LSAs. These LSAs will then be reoriginated at their
      sources, this time with DoNotAge clear.  Like the change in
      Section 2.3, this change is an exception to the general OSPF rule
      that a router can only flush its own self-originated LSAs. Both
      changes pertain only to DoNotAge LSAs, and in both cases a flushed
      LSA's LS age field should be set to MaxAge and not
      DoNotAge+MaxAge.

      2.5.1.  Indicating across area boundaries

         AS-external-LSAs are flooded throughout the entire OSPF routing
         domain, excepting only OSPF stub areas and NSSAs.  For that
         reason, if an OSPF router that is incapable of DoNotAge
         processing exists in any "regular" area (i.e., an area that is
         not a stub nor an NSSA), no AS-external-LSA can have DoNotAge
         set. This memo simplifies that requirement by broadening it to
         the following rule: LSAs in regular OSPF areas are allowed to
         have DoNotAge set if and only if every router in the OSPF
         domain (excepting those in stub areas and NSSAs) is capable of
         DoNotAge processing. The rest of this section describes how the
         rule is implemented.

         As described above in Sections 2.1 and 2.5, a router indicates
         that it is capable of DoNotAge processing by setting the DC-bit
         in the LSAs that it originates. However, there is a problem. It
         is possible that, in all areas to which Router X directly
         attaches, all the routers are capable of DoNotAge processing,
         yet there is some router in a remote "regular" area that cannot
         process DoNotAge LSAs.  This information must then be conveyed
         to Router X, so that it does not mistakenly flood/create
         DoNotAge LSAs.

         The solution is as follows. Area border routers transmit the
         existence of DoNotAge-incapable routers across area boundaries,
         using "indication-LSAs". Indication-LSAs are type-4-summary
         LSAs (also called ASBR-summary-LSAs), listing the area border



Moy                                                             [Page 8]

RFC 1793               OSPF over Demand Circuits              April 1995


         router itself as the described ASBR, with the LSA's cost set to
         LSInfinity and the DC-bit clear. Note that indication-LSAs
         convey no additional information; in particular, they are used
         even if the area border router is not really an AS boundary
         router (ASBR).

         Taking indication-LSAs into account, the rule as to whether
         DoNotAge LSAs are allowed in any particular area is EXACTLY the
         same as given previously in Section 2.5, namely: DoNotAge LSAs
         will be allowed in an OSPF area if and only if, in the area's
         link state database, all LSAs have the DC-bit set in their
         Options field.

         Through origination of indication-LSAs, the existence of
         DoNotAge-incapable routers can be viewed as going from non-
         backbone regular areas, to the backbone area and from there to
         all other regular areas. The following two cases summarize the
         requirements for an area border router to originate
         indication-LSAs:

            (1) Suppose an area border router (Router X) is connected to
                a regular non-backbone OSPF area (Area A). Furthermore,
                assume that Area A has LSAs with the DC-bit clear, other
                than indication-LSAs. Then Router X should originate
                indication-LSAs into all other directly-connected
                "regular" areas, including the backbone area, keeping
                the guidelines of Section 2.5.1.1 in mind.

            (2) Suppose an area border router (Router X) is connected to
                the backbone OSPF area (Area 0.0.0.0). Furthermore,
                assume that the backbone has LSAs with the DC-bit clear
                that are either a) not indication-LSAs or b)
                indication-LSAs that have been originated by routers
                other than Router X itself. Then Router X should
                originate indication-LSAs into all other directly-
                connected "regular" non-backbone areas, keeping the
                guidelines of Section 2.5.1.1 in mind.

         2.5.1.1.  Limiting indication-LSA origination

            To limit the number of indication-LSAs originated, the
            following guidelines should be observed by an area border
            router (Router X) when originating indication-LSAs. First,
            indication-LSAs are not originated into an Area A when A
            already has LSAs with DC-bit clear other than indication-
            LSAs. Second, if another area border router has originated a
            indication-LSA into Area A, and that area border router has
            a higher OSPF Router ID than Router X (same tie-breaker as



Moy                                                             [Page 9]

RFC 1793               OSPF over Demand Circuits              April 1995


            for forwarding address origination; see Section 12.4.5 of
            [1]), then Router X should not originate an indication-LSA
            into Area A.

            As an example, suppose that three regular OSPF areas (Areas
            A, B and C) are connected by routers X, Y and Z
            (respectively) to the backbone area.  Furthermore, suppose
            that all routers are capable of DoNotAge processing, except
            for routers in Areas A and B.  Finally, suppose that Router
            Z has a higher Router ID than Y, which in turn has a higher
            Router ID than X.  In this case, two indication-LSAs will be
            generated (if the rules of Section 2.5.1 and the guidelines
            of the preceding paragraph are followed): Router Y will
            originate an indication-LSA into the backbone, and Router Z
            will originate an indication-LSA into Area C.

3.  Modifications to demand circuit endpoints

   The following subsections detail the modifications required of the
   routers at the endpoints of demand circuits. These consist of
   modifications to two main pieces of OSPF: 1) sending and receiving
   Hello Packets over demand circuits and 2) flooding LSAs over demand
   circuits.

   An additional OSPF interface configuration parameter, ospfIfDemand,
   is defined to indicate whether an OSPF interface connects to a demand
   circuit (see Appendix B). Two routers connecting to a common network
   segment need not agree on that segment's demand circuit status.
   However, to get full benefit of the demand circuit extensions, the
   two ends of a point-to-point link must both agree to treat the link
   as a demand circuit (see Section 3.2).

   3.1.  Interface State machine modifications

      An OSPF point-to-point interface connecting to a demand circuit is
      considered to be in state "Point-to-point" if and only if its
      associated neighbor is in state "1-Way" or greater; otherwise the
      interface is considered to be in state "Down". Hellos are sent out
      such an interface when it is in "Down" state, at the reduced
      interval of PollInterval. If the negotiation in Section 3.2.1
      succeeds, Hellos will cease to be sent out the interface whenever
      the associated neighbor reaches state "Full".

      Note that as a result, an "LLDown" event for the point-to-point
      demand circuit's neighbor forces both the neighbor and the
      interface into state "Down" (see Section 3.2.2).





Moy                                                            [Page 10]

RFC 1793               OSPF over Demand Circuits              April 1995