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

Versions: 00 01

Network Working Group                                          P. Murphy
Internet Draft                                      US Geological Survey
Expiration Date: June 2001                                 December 2000
File name: draft-ietf-ospf-floodgates-01.txt


                            OSPF Floodgates

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.












Murphy                                                          [Page i]


Internet Draft              OSPF Floodgates                December 2000


Table Of Contents

   1.0   Abstract .................................................  1
   2.0   Overview .................................................  2
   2.1   Requirement for OSPF Floodgates ..........................  2
   2.2   Proposed Solution ........................................  3
   2.2.1 2-Way Floodgates .........................................  4
   2.2.2 1-Way Floodgates .........................................  5
   2.3   Application ..............................................  6
   3.0   Floodgate Implementation Details .........................  6
   3.1   Interface Data Structure .................................  6
   3.2   Neighbor Data Structure ..................................  6
   3.3   Floodgate States .........................................  7
   3.4   Floodgate Events .........................................  8
   3.5   Floodgate State Transitions ..............................  9
   3.6   Receiving Floodgate Type 9 LSAs........................... 11
   3.7   Originating Floodgate Type 10 LSAs ....................... 11
   3.8   Link State Acknowledgment and Retransmission ............. 12
   4.0   2-Way Floodgate Implementation Details ................... 12
   4.1   2-Way Floodgate State Transitions ........................ 13
   4.2   Originating 2-Way Floodgate Type 9 LSAs .................. 13
   5.0   1-Way Floodgate Implementation Details ................... 13
   5.1   1-Way Floodgate State Transitions ........................ 14
   5.2   Originating 1-Way Floodgate Type 9 LSAs .................. 15
   6.0   Floodgate Extensions .............. ...................... 16
   7.0   Security Considerations .................................. 16
   8.0   Acknowledgments .......................................... 17
   9.0   References ............................................... 17
   10.0  Author's Address ......................................... 17
   Appendix A: Floodgate Type 9 LSAs .............................. 18
   Appendix B: Floodgate Type 10 LSAs ............................. 20
   Appendix C: Configuration Parameters ........................... 22

1.0  Abstract

   This memo describes an option to the OSPF Version 2 specification
   which allows the partial suppression of flooding between neighboring
   routers. This suppression acts much like a floodgate, opening and
   closing automatically when triggered by the proper conditions. Two
   types of flooding suppression are described, 1-Way and 2-Way. The
   option applies to standard areas, stub areas, and NSSAs. It works
   over any OSPF interface. Routers with this option configured are
   backward compatible with routers running an OSPFv2 compliant
   implementation as defined in RFC 2328, and can be restricted to a
   subset of the OSPF routing domain. This option is applied only
   between neighboring OSPF routers.

   Please send comments to ospf@discuss.microsoft.com.



Murphy                                                          [Page 1]


Internet Draft              OSPF Floodgates                December 2000


2.0  Overview

2.1  Requirement for OSPF Floodgates

   Corporate networks in todays modern Internet require a low cost means
   for maintaining a fault tolerant network. Many of the smaller sites
   in a corporate network connect via dedicated service which is backed
   up via traditional analog dialup service or digital ISDN service.
   These backup links are normally metered for billing purposes.
   Excessive charges may be incurred when a flapping OSPF area topology
   activates every one of these backup links for link state update each
   time the area's topology changes.

   Consider the following typical OSPF example:

                                      (1)
                   A0-----------------------------------D1
                  /|\            Area 1 link           /|\
                 / | \                                / | \
     Area 1     /  |  \                              /  |  \
   Dedicated   /   |   \(4)                         /   |   \
     links    /    |    \                          /    |    \
             / (4) | (4) \           (56)         /     |     \
            A1     B1    C1----------------------+      |      \
            |      |         Area 1 dialup links   (56) |      |
            |      +------------------------------------+ (56) |
            +--------------------------------------------------+


   where A0 is a border router attached to Area 1. A1, B1, C1, and D1
   are Area 1 internal routers. D1 is also an Area 1 access router which
   is attached to A0 via a dedicated circuit and which is connected to
   A1, B1, and C1 via dialup links. A0 connects to A1, B1, and C1 via
   dedicated circuits. OSPF costs are shown in ()s. If the dedicated
   link between A0 and C1 is flapping up and down frequently, the
   current OSPF demand circuit specification, [DC], requires link state
   update across the adjacencies from A1 and B1 to D1 for each flap,
   even though D1 learns about the link state change across its
   adjacency to A0. When there are 50 routers like A1 and B1 with dialup
   links to D1, activating their dial-up links just for link state
   update can be very expensive. Indeed it is enough of a reason not to
   use the OSPF demand circuit specification.

   What is needed is a tool which suppresses the link state update of
   the flapping circuit between A0 and C1 over the links from A1 and B1
   to D1 as long as A1 and B1 see a flooding path to D1 other than their
   dialup links to D1. However C1 still needs to raise its dialup link
   to D1 when its link to A0 fails, as its only path to the rest of Area



Murphy                                                          [Page 2]


Internet Draft              OSPF Floodgates                December 2000


   1 would be through D1.

   Consider another example:


                   A0----------------------D1
                   |     Dedicated link    /|\
                   |                      / | \
        Dedicated  |                     /  |  \  Dial up links
          link     |                    /   |   \
                   |                   /    |    \
                   |                  /     |     \
                   B1                L1     L2     L3
                                     |      |      |
                                     N1     N2     N3

   where again A0 is a border router; B1 is an Area 1 internal router;
   and D1 is an Area 1 internal access router. L1, L2, and L3 are Area 1
   leaf internal routers linking stub networks N1, N2, and N3 to Area 1.
   The OSPF demand circuit specification provides a vehicle whereby the
   dialup links from D1 to the leaf sites L1/N1, L2/N2, and L3/N3 are
   used only as required. However should the link between A0 and B1 flap
   up and down frequently, D1's dialup links to L1, L2, and L3 would
   activate with each change for no purpose other than needless link
   state update. In this example a default path though D1 is normally
   sufficient to meet the basic routing requirements of L1, L2, and L3.
   In an OSPF area where there are dozens of these leaf sites, such
   anomalous behavior could be very expensive, making the use of OSPF
   demand circuit impractical.

   What is needed here is a means of filtering a portion of the link
   state database maintenance between D1 and L1, L2, and L3. L1, L2, and
   L3 need to advertise their router LSAs to D1, but only need receive
   LSA updates from D1 when their default path through D1 is impacted.
   This would provide L1, L2, and L3 with sufficient link state
   information to compute default through D1.

2.2 Proposed Solution

   The OSPF floodgates option provides a vehicle whereby neighboring
   routers can control the amount of link state information which is
   exchanged across their adjacencies. In all cases opaque Type 9 LSAs
   are always synchronized across a floodgated adjacency. Thus all
   flooding suppression between neighbors is partial. The effect of
   flooding an opaque Type 9 LSA can be minimized by setting its
   DoNotAge bit, providing DoNotAging is enable on all routers connected
   to its link-local network. What is presented here are two floodgate
   tools. The first one opens its LSA floodgates fully during times of



Murphy                                                          [Page 3]


Internet Draft              OSPF Floodgates                December 2000


   topological need and then thins the LSA flow to a trickle during
   times of topological plenty. The second floodgate tool thins LSA flow
   in only one floodgated direction so that dynamic update in this
   direction happens only when absolutely necessary or during periods of
   normal application based traffic flow. Both floodgates are fully open
   during adjacency formation, and close only after the adjacency
   reaches Full state.

   Partial floodgating is triggered between neighbors via Type 9 opaque
   LSAs exchanged across their adjacent link. Each opaque LSA requires a
   unique opaque type. Currently the floodgate option uses experimental
   opaque type 225 until one is assigned. Opaque type 225 is referred to
   as the floodgate opaque type in this document (See Appendix A).

   Floodgating is enabled via a new interface configuration parameter
   called FoodgateType (See Appendix A). This parameter defines the type
   of floodgating which is performed across the interface. When set to
   "1-Way", 1-Way floodgating is configured. When set to "2-Way", 2-Way
   floodgating is configured. Both 1-Way and 2-Way floodgates work best
   with the demand circuit processing of Hello packets, as defined in
   [DC] Section 3.2, and the DoNotAge processing of LSAs, as defined in
   [DC] Section 3.3. The requirements of Section 2.1's examples are only
   met when floodgates, demand circuits, and DoNotAge processing are all
   used. However, without demand circuit and DoNotAge processing, OSPF
   floodgates still perform flooding optimization.

   The base topology of an area is defined as all its network links plus
   those router links which have no configured floodgate (1-Way or 2-
   Way). In order for the area's routers to compute link state paths
   through it's base topology, any router which has links with
   floodgating configured must originate a floodgate Type 10 opaque LSA
   into the area listing those links (See Appendix B). All routers along
   the area's paths between routers with configured floodgated links
   should be opaque capable. This guarantees router LSAs and floodgate
   Type 10 opaque LSAs will be synchronized. As a precaution
   implementations may choose to disable floodgating in an area when any
   of the area's routers are not opaque capable.

2.2.1 2-Way Floodgates

   2-Way floodgates partially suppress flooding in both directions. Both
   routers must agree on the floodgate type (either 1-Way or 2-Way) and
   meet each other's floodgate activation criteria (See Sections 4.1 and
   5.1) before floodgating may occur. 2-Way floodgating is enabled via
   transmitted and received floodgate Type 9 LSAs (See Appendix A). When
   performing SPF calculations, routers with configured 2-way floodgates
   must confirm the reachability across the area's base topology of
   their neighboring routers on the other side of their 2-Way



Murphy                                                          [Page 4]


Internet Draft              OSPF Floodgates                December 2000


   floodgates.

   If an adjacent neighbor on the other side of a 2-Way floodgate
   becomes unreachable across the area's base topology, then the
   floodgate is opened for normal link state update. When the floodgate
   initially opens, the neighbor state machine drops to ExStart state
   forcing the link state database to resynchronize (See Section 3.5).

2.2.2 1-Way Floodgates

   1-Way floodgates allow full updating in one direction and suppress
   updating in the other floodgated direction. Both routers must agree
   on the floodgate type before 1-Way floodgating may occur. 1-Way
   floodgating is activated via a floodgate Type 9 LSA (See Appendix A).
   This is necessary to provide a vehicle by which each neighbor may
   open the floodgate.

   The implementation of 1-Way Floodgates is facilitated by partitioning
   an area into sub-areas. By default a router belongs to sub-area 0,
   but may be configured to belong to a distinct non-zero sub-area. A
   1-Way floodgate is always configured between a sub-area 0 router and
   a non-zero sub-area router. The direction of the partial flow is
   always from sub-area 0 to the non-zero sub-area. A transit network
   belongs to each sub-area of any router which connects to it. Area
   border routers will always belong to sub-area 0.  When a 1-Way
   floodgate is configured on a non-zero sub-area router, in addition to
   listing its 1-Way and 2-Way floodgated links in its floodgate Type 10
   LSA, the router must also define its non-zero sub-area ID (See
   Appendix B).

   A router with a configured floodgate (either 1-Way or 2-Way) is
   called a gatekeeper. Each floodgate has two gatekeepers, one on each
   side of the floodgate. A gatekeeper always opens its 1-Way floodgates
   when it receives a default advertisement from a reachable non-zero
   sub-area router. Furthermore it keeps its 1-Way floodgates open as
   long as there exists a default advertisement from a reachable non-
   zero sub-area router. All of an area's default advertisements must
   originate either from a sub-area 0 router or from outside the area
   before any of the area's 1-Way floodgates will close.  If there is no
   installed default through sub-area 0 then a gatekeeper's 1-Way
   floodgates are opened and remain open until default is restored
   through sub-area 0.

   Since flooding is suppressed across 1-Way floodgates, sub-area
   routers should have a SPF tree which ensures a stable flooding and
   forwarding path within each sub-area. During the Shortest Path First
   (SPF) calculation a gatekeeper should verify that the SPF Tree's
   branches which leave the local router's sub-area never return as they



Murphy                                                          [Page 5]


Internet Draft              OSPF Floodgates                December 2000


   grow toward the extremities of the area. This check need only be
   performed by the gatekeepers. If a gatekeeper fails to meet this
   criteria it opens all of its floodgates.

   2.3 Application

   Consider now the first example mentioned in Section 2.1 and assume
   2-Way floodgates are configured over the dialup links from D1 to A1,
   B1, and C1.  Furthermore assume DoNotAge processing is in effect
   within Area 1 and that the dialup links from D1 to A1, B1, and C1
   have Demand Circuit enabled.  Since a full flooding path exists from
   A1 and B1 to D1 through A0 the floodgates between D1 and its
   neighbors, A1 and B1, remain closed and the flapping of the dedicated
   link between A0 and C1 only effects the floodgate between D1 and C1.
   The dialup backup links from D1 to A1 and B1 are unaffected and no
   link state update occurs over these links during this outage.

   In the second example we again assume DoNotAge processing is in
   effect within Area 1 and that the dialup links from D1 to L1, L2, and
   L3 have Demand Circuit enabled. The L1/N1, L2/N2, and L3/N3
   topologies are configured in sub-areas 1, 2 and 3 respectively, while
   the remaining Area 1 routers are left in sub-area 0. 1-Way floodgates
   are configured between D1 and L1, L2 and L3. Assume the default path
   for Area 1 is through A0. When the link between B1 and A0 flaps up
   and down, the 1-Way floodgates between D1 and L1, L2 and L3 remain
   closed since the default path of their respective sub-areas has not
   changed. No link state update occurs over these links during this
   outage.

3.0 Floodgate Implementation Details

3.1 Interface Data Structure

   Floodgating is enabled via a new interface configuration parameter
   called FoodgateType (See Appendix A). This parameter defines the type
   of floodgating which is performed across the interface. When set to
   "None", there is no floodgate configured for the interface. When set
   to "1-Way", 1-Way floodgating is configured. When set to "2-Way", 2-
   Way floodgating is configured. The default setting of FloodgateType
   for any interface is "None". Floodgates are activated on a per
   neighbor basis. Only neighbors at Full state may have active
   floodgates.

3.2 Neighbor Data Structure

   Floodgate state transition is added to the neighbor state machine. In
   support of floodgate state transition, three new elements are added
   to the neighbor data structure: the Floodgate Delay Timer, the



Murphy                                                          [Page 6]


Internet Draft              OSPF Floodgates                December 2000


   Floodgate State, and the UpdateLinkState flag. The Floodgate State
   parameter shows the current state of the floodgate. When the neighbor
   data structure is first created, its Floodgate State parameter is
   initialized to either "Disabled" or "InActive" depending on whether
   the interface FloodgateType parameter is respectively "None" or
   either "1-Way" or "2-Way". As a floodgate transitions from InActive
   to Active state it assumes intermediate values of Init, 1-Way, and
   Waiting (See Section 3.3 below).

   When a floodgate transitions out of Active state, the link state data
   base must be resynchronized with that of its adjacent neighbor. This
   is accomplished by dropping the neighbor to ExchangeStart state. The
   UpdateLinkState parameter is set to "disabled" so that a new router-
   LSA and possible network-LSA is not reoriginated. All other events
   which drop a neighbor out of full state set the UpdateLinkState
   parameter to "enabled".

   A floodgate's gatekeeper resets and starts the single shot Floodgate
   Delay Timer of one its floodgated neighbors's when all of the
   following conditions are all met:

      o the neighbor meets the gatekeeper's floodgate activation
        criteria (See Sections 4.1 and 5.1).

      o the neighbor's signals that the gatekeeper meets its floodgate
        activation criteria by listing it as opaque data in its Type 9
        LSA (See Sections 4.2 and 5.2).

      o the neighbor has reached Full state.

   See Sections 3.4 and 3.5 below for details. Normal flooding continues
   until the timer fires, at which time the floodgate closes and starts
   suppressing flooding across the link. This ensures a stable flooding
   path within the area. The current value of the Floodgate Delay Timer
   is 300 seconds.

   When a lower layer protocol activity timer is in effect for the
   floodgated link, non-OSPF traffic over the link should reset the
   Floodgate Delay Timer using the ResetFloodgate event (See Section 3.4
   and Appendix C). When a floodgate is closed lower layer activity may
   also open a floodgate by triggering the ResetFloodgate event (See
   Section 3.4). While the Floodgate Delay Timer is counting down, the
   floodgate is still open.

3.3 Floodgate States

   The various states that OSPF floodgates may attain is documented in
   this section. These states are listed in order of progressing



Murphy                                                          [Page 7]


Internet Draft              OSPF Floodgates                December 2000


   functionality. For example, the inoperative state, InActive, is
   listed before the intermediate states Init, 1-Way, and Waiting. The
   last state, Active, is the fully operational floodgate state. The
   specification makes use of this ordering by sometimes making
   references such as "in state greater than X". During all floodgate
   states less than Active full link state update with the neighbor is
   in effect and the floodgate is said to be fully open.

      Disabled
         This state indicates no floodgate is configured.

      InActive
         This state indicates the floodgated neighbor does not meet the
         local router's floodgate activation criteria (See Sections 4.1
         and 5.1).

      Init
         This state indicates the floodgated neighbor meets the local
         router's floodgate activation criteria but a floodgate Type 9
         LSA with matching floodgate type has not been received from the
         neighbor.

      1-Way
         This state indicates the neighbor's floodgate Type 9 LSA was
         received with matching floodgate type but the local router is
         not listed in the LSA's opaque data, implicating the local
         router does not yet meet the neighbor's floodgate activation
         criteria.

      Waiting
         This state indicates the neighbor's floodgate Type 9 LSA has
         been received with matching floodgate type and it lists the
         local router in the LSA's opaque data, implying the local
         router does meet the neighbor's floodgate activation criteria.

      Active
         In this state, the floodgate between the neighbor has closed
         and it is actively suppressing link state update.

3.4 Floodgate Events

   The following new events are defined in support of floodgates.

      OpenFloodgate
         Both 1-Way and 2-Way floodgates have floodgate activation
         criteria which must be met for these floodgates to remain
         closed. When a gatekeeper observes that the floodgate
         activation criteria of its floodgated neighbor is no longer



Murphy                                                          [Page 8]


Internet Draft              OSPF Floodgates                December 2000


         met, this event is triggered (See Sections 4.1 and 5.1).
         Following this event the floodgate transitions from closed to
         open.  Floodgates may also be opened by lower layer protocols
         when dial-up links are active.

      ReleaseFloodgate
         When a gatekeeper observes the floodgate activation criteria of
         its floodgated neighbor is now met, whereas before it was not,
         then this event is triggered, releasing the floodgate for
         closure process. (See Sections 4.1 and 5.1).

      FloodgateDelayTimer
         When this timer fires, it signals the fact that the neighbor's
         floodgated has been in Waiting state for the full duration of
         the timer during which all necessary criteria for closing the
         floodgate have been met. Its firing causes the floodgate to
         close and flooding suppression to begin.

      ResetFloodgate
         Lower layer protocols have indicated the floodgate should be
         opened due to non-OSPF traffic flow.

      1-Way9Received
         A floodgate Type 9 LSA has been received in which the local
         router is not mentioned. Either the floodgated neighbor has not
         received a floodgate Type 9 LSA from the local router, or the
         local router no longer meets the neighbor's floodgate
         activation criteria.

      2-Way9Received
         A floodgate Type 9 LSA has been received in which the local
         router is listed. Thus the neighbor has received the local
         router's floodgate Type 9 LSA and the local router meets the
         neighbor's floodgate activation criteria.

3.5 Floodgate State Transitions

   Several neighbor state machine events effect floodgate state. If the
   floodgate's state is greater than InActive, any change in the
   floodgated neighbor's Full state results in the floodgate's state
   dropping to Init state. If the floodgate's state is Waiting when the
   neighbor event LoadingDone is triggered, the Floodgate Delay Timer is
   reset and started.  Otherwise no action is taken. All neighbor state
   machine events which drop a neighbor out of full state must set the
   UpdateLinkState parameter to "enabled".

   When an OpenFloodgate event occurs and the floodgate's state is
   greater than InActive then the new state is set to InActive and a new



Murphy                                                          [Page 9]


Internet Draft              OSPF Floodgates                December 2000


   floodgate Type 9 LSA is originated omitting the neighbor from its
   opaque data. If the floodgate's old state is Active it sets the
   UpdateLinkState to disabled and triggers the neighbor's state machine
   to perform the same action as a SeqNumMismatch event, thus dropping
   the neighbor's state to ExStart. No new router-LSA or network-LSA is
   generated during the data base resynchronization unless problems
   occur.

   When a ResetFloodgate event occurs and the floodgate's state is
   Active then set the UpdateLinkState to "disabled" and trigger the
   neighbor's state machine to perform the same action as a
   SeqNumMismatch event, thus dropping the neighbor's state to ExStart.

   Following any ResetFloodgate event where the floodgate state is
   greater than InActive then

      (1) If there does not exist an acknowledged floodgate Type 9 LSA
          for the neighbor set the floodgate state to Init,

      (2) Else if an acknowledged floodgate Type 9 LSA exists but it
          does not list the local router then set the floodgate state to
          1-Way,

      (3) Else the acknowledged floodgate Type 9 LSA does list the local
          router, so set the floodgate state to Waiting. If the
          floodgated neighbor's state machine is in Full state, start
          the Floodgate Delay Timer.

   When a ReleaseFloodgate event occurs and the Floodgate state is
   InActive then

      (1) If there does not exist an acknowledged floodgate Type 9 LSA
          for the neighbor set the floodgate state to Init,

      (2) Else if an acknowledged floodgate Type 9 LSA exists but it
          does not list the local router, then set the floodgate state
          to 1-Way,

      (3) Else the acknowledged floodgate Type 9 LSA does list the local
          router, so set the floodgate state to Waiting. If the
          floodgated neighbor's state machine is in Full state, start
          the Floodgate Delay Timer.

   Once a floodgate is released it may transition between the Init, 1-
   Way and Waiting states toward activation and closure. The events
   which effect these state transitions are described below.

   When a 1-Way9Received event occurs and the floodgate's state is



Murphy                                                         [Page 10]


Internet Draft              OSPF Floodgates                December 2000


   Active, set the UpdateLinkState to disabled and trigger the
   neighbor's state machine to perform the same action as a
   SeqNumMismatch event, thus dropping the neighbor's state to ExStart.

   When a 1-Way9Received event occurs and the floodgate's state is
   Waiting, stop a running Floodgate Delay Timer.

   Following any 1-Way9Received event where the floodgate's state is
   greater than InActive, set the floodgate's state to 1-Way.

   When a 2-Way9Received event occurs, if the floodgate's state is Init
   or 1-Way then set the floodgate's state to Waiting and, if the
   floodgated neighbor's state machine is in Full state, reset and start
   the Floodgate Delay Timer.

   When the Floodgate Delay Timer fires it triggers the
   FloodgateDelayTimer event. If the Floodgate state is Waiting then the
   Floodgate is closed and flooding suppression begins.

3.6 Receiving Floodgate Type 9 LSAs

   When a new functionally different floodgate Type 9 LSA is received or
   acknowledged across a floodgated interface during link state update
   or database exchange, its floodgate type is compared with that of the
   receiving interface. If they do not match then any existing neighbor
   state machine for the neighbor is executed with the OpenFloodgate
   event, and processing of this received floodgate Type 9 LSA
   terminates.

   Otherwise the opaque data of the floodgate Type 9 LSA is checked to
   see if the local router is listed. If it is not, then the neighbor's
   state machine is executed with the event 1-Way9Received. If it is
   listed, then the neighbor state machine is executed with the event
   2-Way9Received.

3.7 Originating Floodgate Type 10 LSAs

   In order to compute link state paths through an area's base topology,
   all of the area's routers with configured floodgates (1-Way and 2-
   Way) must originate a floodgate Type 10 LSA which lists those links
   (See Appendix B).  In addition a router advertises its sub-area ID in
   its floodgate Type 10 LSA. By default a router's sub-area ID is set
   to 0. only routers with a non-zero sub-area ID in their area data
   structures must originate a Type 10 LSA specifying its value in the
   Sub-area ID field and must do so even when they do not have any
   configured floodgates. All routers in an area with configured
   floodgates should be opaque capable, otherwise the flooding of
   floodgate Type 10 LSAs may be incomplete and some floodgates may



Murphy                                                         [Page 11]


Internet Draft              OSPF Floodgates                December 2000


   close inappropriately. When a new router LSA is originated by a
   router for a area in which the router has configured floodgates, the
   router should also originate a new floodgate Type 10 LSA into the
   area. This keeps router LSAs and floodgate Type 10 LSAs closely
   synchronized. As a precaution implementations may choose to disable
   floodgating in an area when any of the area's routers are not opaque
   capable.

3.8 Link State Acknowledgment and Retransmission

   It is entirely possible that two gatekeepers on each side of a
   floodgate may close their side of the floodgate asynchronously. Any
   received link state update packets must still be properly received
   and acknowledged. Any link state requests or non-empty link state
   retransmission list must still be processed. Thus residual link state
   update may continue for a while following the closure of a floodgate.
   Floodgate closure simply means any newly received or originated LSAs,
   except for Type 9 LSAs, are not flooded out an interface with a
   closed floodgate unless requested. Note that 1-Way floodgates are
   only closed in one direction. Full flooding occurs in the other
   direction.

   This fact has a direct impact on interfaces of broadcast type.
   Floodgates do work over these types of interfaces, but functionality
   is impacted by the multicasting of link state update. For the most
   part floodgates over broadcast networks are only effective when there
   are closed foodgates between the DR and Backup DR, plus all of their
   adjacent neighbors. These floodgates will still eventually close as
   the closure of floodgates is not effected by current link state
   update once two neighbors have reached Full state.

4.0 2-Way Floodgate Implementation Details

   While floodgate state transition is basically the same for both 2-Way
   and 1-Way floodgates, floodgate activation criteria are notably
   different. When a 2-Way Floodgate is active, it is assumed that an
   interface's floodgated neighbors are reachable via the area's base
   topology. Every router with configured floodgates (1-Way and 2-Way)
   must originate a Type 10 LSA specifying their floodgated links. These
   links are removed from the area's link state data base to form the
   base topology. The base topology provides a flooding path between the
   two neighbors which avoids any floodgated links.  When two floodgated
   neighbors are reachable across the base topology, the flooding of all
   LSAs, except for Type 9 LSAs, may be suppressed across an active 2-
   Way floodgate. The effects of Type 9 LSA flooding and Hello packet
   exchange can be further mitigated with demand circuit and DoNotAge
   processing.




Murphy                                                         [Page 12]


Internet Draft              OSPF Floodgates                December 2000


4.1 2-Way Floodgate State Transitions

   When the link state data base of an area changes, each of its routers
   with configured 2-Way floodgates must recheck the reachability of
   it's floodgated neighbors across the area's base topology. If a 2-Way
   floodgated neighbor becomes newly unreachable across the area's base
   topology, then the OpenFloodgate event should be triggered. This
   causes the neighbor's 2-Way floodgate to fully open and its floodgate
   state to transition to InActive. A new floodgate Type 9 LSA is
   originated at the floodgated interface with the neighbor omitted from
   its opaque data. If a 2-Way floodgated neighbor becomes newly
   reachable across the area's base topology, then the ReleaseFloodgate
   event should be triggered. This causes the 2-Way floodgate to
   transition out of InActive state and to begin the process of swinging
   shut.

   Lower layer protocols may open a 2-Way floodgate with the
   ResetFloodgate event. Non-OSPF traffic in either direction may
   trigger this event and will keep the floodgate in Waiting state until
   a lower layer protocol inactivity timer fires. Lower layer protocol
   inactivity timers need to be modified to ignore OSPF protocol 89 in
   both directions across 2-Way floodgated links.  Note that floodgates
   do not stop the normal exchange of Hello packets. Only OSPF DDR
   suppresses Hello packets.

4.2 Originating 2-Way Floodgate Type 9 LSAs

   Floodgate Type 9 LSAs are originated across every 2-Way floodgated
   interface with their Floodgate Type set to 2-Way. In addition those
   neighbors which are reachable across the area's base topology and
   from whom acknowledged floodgate Type 9 LSAs have been received (or
   acknowledged during database exchange) with matching floodgate type,
   are listed in the LSAs opaque data (See Appendix A).

5.0 1-Way Floodgate Implementation Details

   For a 1-Way Floodgate to be active in an area, the area must be
   partitioned into sub-areas. A router may belong to only one sub-area.
   Each router of a non-zero sub-area must declare its Sub-area ID even
   when it has no configured floodgates. This is done via a floodgate
   Type 10 LSA. By default a router belongs to sub-area 0. Thus routers
   in sub-area 0 only need originate a floodgate Type 10 LSA if they
   have configured floodgates (See Section 3.7). A new area
   configuration parameter called Sub-area ID is used to set the sub-
   area ID of an area's internal routers. Border routers are always in
   sub-area 0.

   Like a stub area, a non-zero sub-area uses OSPF's classless default



Murphy                                                         [Page 13]


Internet Draft              OSPF Floodgates                December 2000


   to forward traffic destined outside its borders. Default forwarding
   is not always optimum when there are multiple floodgates bordering a
   non-zero sub-area, as the part of the areas's LSDB which is external
   to the non-zero sub-area may age out or become obsolete. The non-zero
   sub-area side of a 1-Way floodgate always performs dynamic link state
   update with the sub-area 0 side of the floodgate. Thus sub-area 0 has
   a full link state database of the area's entire topology. When a 1-
   Way floodgate is closed, the sub-area 0 side of a floodgate
   suppresses all LSA updates, except for Type 9 LSAs, to the non-zero
   sub-area side of the floodgate.

5.1 1-Way Floodgate State Transitions

   Maintaining a default path and border router reachability are very
   important floodgate activation criteria to the health of a 1-Way
   floodgate. A sub-area 0 router will keep its 1-Way floodgates closed
   only when all of its default next-hops are over non-floodgated sub-
   area 0 links. If a sub-area 0 router's new default installation has a
   next-hop in a non-zero sub-area, whereas its old default next hop was
   in sub-area 0, the OpenFloodgate event is triggered for all of the
   router's 1-Way floodgated neighbors. This causes these neighbors'
   floodgates to fully open and their floodgate states to transition to
   InActive. If a sub-area 0 router looses its default through sub-area
   0 it triggers the OpenFloodgate event for all of its 1-Way floodgated
   neighbors.

   A non-zero sub-area router must install a default next-hop from an
   advertisement originating outside the area's non-zero sub-areas.
   Unfortunately a non-zero sub-area router with a configured 1-Way
   floodgate has no easy way of knowing what default path(s) the other
   routers in its sub-area install. To circumvent this problem, a non-
   zero sub-area router should trigger an OpenFloodgate event for any
   1-Way floodgated neighbor when it receives a default advertisement
   from any reachable non-zero sub-area router, even ones from a
   different non-zero sub-area. This rule ensures that a default path
   will eventually trail out of the area through sub-area 0. It even
   allows for the unwise case when two non-zero sub-areas neighbor each
   other. In configuration terms, a non-zero sub-area router should
   never originate a default advertisement, as that may disable 1-Way
   floodgating throughout the entire area. Since a non-zero sub-area
   router performs full flooding over all of its interfaces, even those
   with configured 1-Way floodgates, it has no other floodgate
   activation criteria. Note that non-zero sub-areas may even partition
   with no effect, as they simply become separate non-zero sub-areas.

   Even though the link state database of a non-zero sub-area is
   synchronized within the sub-area, because of its 1-Way floodgates it
   is highly unlikely a non-zero sub-area will have sufficient link



Murphy                                                         [Page 14]


Internet Draft              OSPF Floodgates                December 2000


   state information to transit the rest of the area's traffic through
   its topology unless its floodgates are open. Hence any sub-area 0
   router with configured 1-Way floodgates should ensure during the
   Shortest Path First calculation that no sub-area 0 router is directly
   below a non-zero sub-area router on its Shortest Path First tree.
   When this is the case sub-area 0 is said to be topologically concave.
   When a sub-area 0 router's Shortest Path First calculation indicates
   sub-area 0 is no longer topologically concave, it should trigger an
   OpenFloodgate event for all of its 1-Way floodgates.

   If, as a result of a sub-area 0 router's Shortest Path First
   calculation, the router determines that all of its installed defaults
   have next hop in sub-area 0 and that sub-area 0 is topologically
   concave, then the ReleaseFoodgate event is triggered for all of its
   1-Way floodgated neighbors. If on a non-zero sub-area router the last
   advertisement for default originating from a non-zero sub-area router
   ages out or is flushed, or the router which originated this default
   advertisement becomes unreachable and there still exists an installed
   SPF default, then the ReleaseFloodgate event should be triggered for
   all of its 1-Way floodgated neighbors. These conditions cause a 1-Way
   floodgate to transition out of InActive state and to begin the
   process of swinging shut.

5.2 Originating 1-Way Floodgate Type 9 LSAs

   Floodgate Type 9 LSAs are originated across every 1-Way floodgated
   interface with the Floodgate Type set to 1-Way. Furthermore a 1-Way
   floodgated neighbor is listed in the LSA's opaque data when

      o a floodgate Type 9 LSA has been received from the neighbor with
        matching 1-Way Floodgate Type,

      o a floodgate Type 10 LSA has been received from the neighbor with
        the appropriate Sub-area ID, and

      o the neighbor meets the local router's floodgate activation
        criteria.

   Two non-zero sub-area routers may never form a 1-Way floodgate, even
   though they can still be neighbors. In practice two distinct non-zero
   sub-areas which have mutually adjacent neighbors simply form a single
   non-zero sub-area even though they have different non-zero Sub-area
   IDs. While the Sub-area ID is a good mental tool for keeping tract of
   sub-areas, the boundaries of a non-zero sub-area are determined by
   where it meets sub-area 0, and not by the sub-area ID sameness or
   difference of its router members.





Murphy                                                         [Page 15]


Internet Draft              OSPF Floodgates                December 2000


6.0 Floodgate Extensions

   The floodgate machinery defined in Section 3.0 through Section 3.7
   provides the necessary tools for adding additional floodgate
   extensions. The Floodgate Type field in the floodgate Type 9 LSA
   reserves values 0 through 127 for future floodgate extensions. Values
   128 through 255 may be used for experimentation or implementation
   specific value added features. Currently only three values are
   assigned, 0 for no floodgating, 1 for 1-Way floodgating and, 2 for
   2-Way floodgating.

   A notable floodgate extension omission is a floodgate which
   suppresses the flooding of summary-LSAs and AS-external-LSAs from a
   sub-area 0 router to a non-zero sub-area router. It would function
   much like a 1-Way floodgate but its floodgate activation criteria is
   much simpler.

7.0 Security Considerations

   Security issues are not discussed in this memo.































Murphy                                                         [Page 16]


Internet Draft              OSPF Floodgates                December 2000


8.0 Acknowledgments

   This document was produced by the OSPF Working Group, chaired by John
   Moy.  In addition, comments from the following individuals are also
   acknowledged:

   Acee Lindem        IBM

9.0 References

   [DC]    Moy, J., "Extending OSPF to Support Demand Circuits", RFC
           1793, Cascade Communication Corp., April 1995.

   [MIB]   McCloghrie, K., and M. Rose, "Management Information Base for
           network management of TCP/IP-based internets: MIB-II", STD
           17, RFC 1213, Hughes LAN Systems, Performance Systems
           International, March 1991.

   [OPAQ]  Coltun, Rob, "The OSPF Opaque LSA Option", FORE Systems,
           August 1998.

   [OSPF]  Moy, J., "OSPF Version 2", RFC 2328, Ascend Communications,
           Inc., April 1998.

   [1583]  Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March
           1994.

10.0 Author's Address

           Pat Murphy
           US Geological Survey
           345 Middlefield Road, Mail Stop 870
           Menlo Park, California 94560

           Phone: (650)329-4044
           EMail: pmurphy@noc.doi.net















Murphy                                                         [Page 17]


Internet Draft              OSPF Floodgates                December 2000


Appendix A. Floodgate Type 9 LSAs

   Floodgate Type 9 LSAs are used directly by OSPF to synchronize floodgate
   state between neighboring routers over links. These LSAs are flooded across
   the floodgated link. The flooding scope of floodgate type 9 LSAs is
   link-local, which means floodgate Type 9 LSAs are never forwarded beyond the
   local (sub)network which contains their floodgates.

   Section 3.5 of this document describes the purpose of this floodgate opaque
   LSA in more detail.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |    Options    |   LSA Type 9  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Opaque Type  |               Opaque ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Advertising Router                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      LS Sequence Number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Floodgate type |                     0                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Observed Floodgate Ready Neighbor                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            ...                                |

   Syntax of the floodgate Type 9 LSA's Link State ID

      The link-state ID of the floodgate Type 9 LSA is divided into an
      Opaque Type field (the first 8 bits), which has the  floodgate
      opaque type (225) value, and the Opaque ID (the remaining 24
      bits). The floodgate Type 9 LSA's Opaque ID is set to the last 24
      bits of the interface's IP address, if it has one.  In the case of
      unnumbered point-to-point connections, the floodgate Type 9 LSA's
      Opaque ID is set to the last 24 bits of the interface's MIB-II
      [MIB] ifIndex value.  The most significant bits may be changed to
      ensure uniqueness.

      Floodgate Type
         This parameter is set to 0 when no floodgates are configured
         for this link.  It is set to 1 when 1-Way floodgating is
         configured for the link and it is set to 2 when 2-way
         floodgating is configured for the link.




Murphy                                                         [Page 18]


Internet Draft              OSPF Floodgates                December 2000


      Observed Floodgate Ready Neighbor

         All neighbors from whom Floodgate Type 9 opaque LSAs have been
         received and who meet the local router's floodgate activation
         criteria are listed in at the end of Floodgate Type 9 LSA (See
         Section 4.2. and 5.2).













































Murphy                                                         [Page 19]


Internet Draft              OSPF Floodgates                December 2000


Appendix B. Floodgate Type 10 LSAs

   Floodgate Type 10 LSAs are used directly by OSPF to advertise inside
   an area a router's list of floodgated links. The flooding scope of
   floodgate Type 10 LSAs is areawide, which means floodgate Type 10
   LSAs are never forwarded beyond the area border. A router which has
   floodgated links must originate a floodgate Type 10 LSA listing those
   links. If a router belongs to a non-zero sub-area, it must also
   originate a floodgate Type 10 LSA which specifies its sub-area in the
   Sub-area ID field. If a router has no floodgated links and belongs to
   sub-area 0, it need not originate a floodgate Type 10 LSA.

   Section 3.7 of this document describes the purpose of the floodgate
   Type 10 LSA in more detail.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |     Options   |  LSA Type 10  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Opaque Type   |               Opaque ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Advertising Router                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      LS Sequence Number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Sub-area ID           |          #  links             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Link ID                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            Link Data                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |

   Syntax Of The Opaque LSA's Link State ID

      The link-state ID of the floodgate Type 10 LSA is divided into an
      Opaque Type field (the first 8 bits), which has value floodgate
      (currently 224), and the Opaque ID (the remaining 24 bits). The
      floodgate Type 10 Opaque ID is set to the last 24 bits of the OSPF
      interface's IP address, if it has one. In the case of unnumbered
      point-to-point connections, the floodgate Type 10 opaque ID is set
      to the last 24 bits of the interface's MIB-II [MIB] ifIndex value.
      The most significant bits may be changed to ensure uniqueness.





Murphy                                                         [Page 20]


Internet Draft              OSPF Floodgates                December 2000


      # links
         The number of floodgated links listed in this LSA. This must be
         the local router's total collection of floodgated links with
         flooding suppression configured for the area.

      Sub-area ID
         An OSPF area with configured 1-Way floodgates must be broken
         into OSPF sub-areas. 1-Way floodgates are configured between
         routers in sub-area 0 and routers in non-zero sub-areas. By
         default the Sub-area ID field is set to 0.  A router specifies
         its non-zero sub-area in the the Sub-area ID field.

   The following fields are used to describe each of the router's
   links. They must match their counterparts in the router's Type 1
   (router) LSA for this area.

      Link ID
          The Router ID of the neighboring router that this router
          connects to via a link. This provides the key for looking up
          the neighboring LSA in the link state database during the
          routing table calculation. See [OSPF] Section 12.2 for more
          details.

      Link Data
          For unnumbered point-to-point connections, it specifies the
          interface's MIB-II [MIB] ifIndex value. For the other link
          types it specifies the router interface's IP address. This
          latter piece of information is needed during the routing table
          build process, when calculating the IP address of the next
          hop. See [OSPF] Section 16.1.1 for more details.





















Murphy                                                         [Page 21]


Internet Draft              OSPF Floodgates                December 2000


Appendix C. Configuration Parameters

   Floodgating is enabled via a new interface configuration parameter
   called FoodgateType. When set to "None", there is no floodgate
   configured for the interface. When set to "1-Way", 1-Way floodgating
   is configured. When set to "2-Way", 2-Way floodgating is configured.
   The default setting of FloodgateType for any interface is "None". A
   maximum of 255 different floodgate types may be defined. Currently
   only these three are defined. The first 128 floodgate types are
   reserved for future additions to this specification. The remaining
   128 floodgate types are available for experimentation and
   implementation specific value added features (See Section 3.1).

   A new area configuration parameter called Sub-area ID is used to set
   the sub-area of an area's internal routers. It should not be possible
   to set this parameter on a border router, as the border routers of an
   area are always in sub-area 0.

   A new interface configuration parameter called the ActivityTrigger
   has been added. Its function is implemented by lower level protocols.
   When set to enabled, non-OSPF IP traffic between two floodgated
   neighbors may open a floodgate. When set to disabled, non-OSPF IP
   traffic has no effect on the state of a floodgate.




























Murphy                                                         [Page 22]


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