idnits 2.17.1 draft-ietf-ospf-floodgates-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 836 has weird spacing: '...has the flood...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2000) is 8526 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'OPAQ' is defined on line 784, but no explicit reference was found in the text == Unused Reference: '1583' is defined on line 790, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'OPAQ' ** Obsolete normative reference: RFC 1583 (Obsoleted by RFC 2178) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Murphy 2 Internet Draft US Geological Survey 3 Expiration Date: June 2001 December 2000 4 File name: draft-ietf-ospf-floodgates-01.txt 6 OSPF Floodgates 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Table Of Contents 29 1.0 Abstract ................................................. 1 30 2.0 Overview ................................................. 2 31 2.1 Requirement for OSPF Floodgates .......................... 2 32 2.2 Proposed Solution ........................................ 3 33 2.2.1 2-Way Floodgates ......................................... 4 34 2.2.2 1-Way Floodgates ......................................... 5 35 2.3 Application .............................................. 6 36 3.0 Floodgate Implementation Details ......................... 6 37 3.1 Interface Data Structure ................................. 6 38 3.2 Neighbor Data Structure .................................. 6 39 3.3 Floodgate States ......................................... 7 40 3.4 Floodgate Events ......................................... 8 41 3.5 Floodgate State Transitions .............................. 9 42 3.6 Receiving Floodgate Type 9 LSAs........................... 11 43 3.7 Originating Floodgate Type 10 LSAs ....................... 11 44 3.8 Link State Acknowledgment and Retransmission ............. 12 45 4.0 2-Way Floodgate Implementation Details ................... 12 46 4.1 2-Way Floodgate State Transitions ........................ 13 47 4.2 Originating 2-Way Floodgate Type 9 LSAs .................. 13 48 5.0 1-Way Floodgate Implementation Details ................... 13 49 5.1 1-Way Floodgate State Transitions ........................ 14 50 5.2 Originating 1-Way Floodgate Type 9 LSAs .................. 15 51 6.0 Floodgate Extensions .............. ...................... 16 52 7.0 Security Considerations .................................. 16 53 8.0 Acknowledgments .......................................... 17 54 9.0 References ............................................... 17 55 10.0 Author's Address ......................................... 17 56 Appendix A: Floodgate Type 9 LSAs .............................. 18 57 Appendix B: Floodgate Type 10 LSAs ............................. 20 58 Appendix C: Configuration Parameters ........................... 22 60 1.0 Abstract 62 This memo describes an option to the OSPF Version 2 specification 63 which allows the partial suppression of flooding between neighboring 64 routers. This suppression acts much like a floodgate, opening and 65 closing automatically when triggered by the proper conditions. Two 66 types of flooding suppression are described, 1-Way and 2-Way. The 67 option applies to standard areas, stub areas, and NSSAs. It works 68 over any OSPF interface. Routers with this option configured are 69 backward compatible with routers running an OSPFv2 compliant 70 implementation as defined in RFC 2328, and can be restricted to a 71 subset of the OSPF routing domain. This option is applied only 72 between neighboring OSPF routers. 74 Please send comments to ospf@discuss.microsoft.com. 76 2.0 Overview 78 2.1 Requirement for OSPF Floodgates 80 Corporate networks in todays modern Internet require a low cost means 81 for maintaining a fault tolerant network. Many of the smaller sites 82 in a corporate network connect via dedicated service which is backed 83 up via traditional analog dialup service or digital ISDN service. 84 These backup links are normally metered for billing purposes. 85 Excessive charges may be incurred when a flapping OSPF area topology 86 activates every one of these backup links for link state update each 87 time the area's topology changes. 89 Consider the following typical OSPF example: 91 (1) 92 A0-----------------------------------D1 93 /|\ Area 1 link /|\ 94 / | \ / | \ 95 Area 1 / | \ / | \ 96 Dedicated / | \(4) / | \ 97 links / | \ / | \ 98 / (4) | (4) \ (56) / | \ 99 A1 B1 C1----------------------+ | \ 100 | | Area 1 dialup links (56) | | 101 | +------------------------------------+ (56) | 102 +--------------------------------------------------+ 104 where A0 is a border router attached to Area 1. A1, B1, C1, and D1 105 are Area 1 internal routers. D1 is also an Area 1 access router which 106 is attached to A0 via a dedicated circuit and which is connected to 107 A1, B1, and C1 via dialup links. A0 connects to A1, B1, and C1 via 108 dedicated circuits. OSPF costs are shown in ()s. If the dedicated 109 link between A0 and C1 is flapping up and down frequently, the 110 current OSPF demand circuit specification, [DC], requires link state 111 update across the adjacencies from A1 and B1 to D1 for each flap, 112 even though D1 learns about the link state change across its 113 adjacency to A0. When there are 50 routers like A1 and B1 with dialup 114 links to D1, activating their dial-up links just for link state 115 update can be very expensive. Indeed it is enough of a reason not to 116 use the OSPF demand circuit specification. 118 What is needed is a tool which suppresses the link state update of 119 the flapping circuit between A0 and C1 over the links from A1 and B1 120 to D1 as long as A1 and B1 see a flooding path to D1 other than their 121 dialup links to D1. However C1 still needs to raise its dialup link 122 to D1 when its link to A0 fails, as its only path to the rest of Area 123 1 would be through D1. 125 Consider another example: 127 A0----------------------D1 128 | Dedicated link /|\ 129 | / | \ 130 Dedicated | / | \ Dial up links 131 link | / | \ 132 | / | \ 133 | / | \ 134 B1 L1 L2 L3 135 | | | 136 N1 N2 N3 138 where again A0 is a border router; B1 is an Area 1 internal router; 139 and D1 is an Area 1 internal access router. L1, L2, and L3 are Area 1 140 leaf internal routers linking stub networks N1, N2, and N3 to Area 1. 141 The OSPF demand circuit specification provides a vehicle whereby the 142 dialup links from D1 to the leaf sites L1/N1, L2/N2, and L3/N3 are 143 used only as required. However should the link between A0 and B1 flap 144 up and down frequently, D1's dialup links to L1, L2, and L3 would 145 activate with each change for no purpose other than needless link 146 state update. In this example a default path though D1 is normally 147 sufficient to meet the basic routing requirements of L1, L2, and L3. 148 In an OSPF area where there are dozens of these leaf sites, such 149 anomalous behavior could be very expensive, making the use of OSPF 150 demand circuit impractical. 152 What is needed here is a means of filtering a portion of the link 153 state database maintenance between D1 and L1, L2, and L3. L1, L2, and 154 L3 need to advertise their router LSAs to D1, but only need receive 155 LSA updates from D1 when their default path through D1 is impacted. 156 This would provide L1, L2, and L3 with sufficient link state 157 information to compute default through D1. 159 2.2 Proposed Solution 161 The OSPF floodgates option provides a vehicle whereby neighboring 162 routers can control the amount of link state information which is 163 exchanged across their adjacencies. In all cases opaque Type 9 LSAs 164 are always synchronized across a floodgated adjacency. Thus all 165 flooding suppression between neighbors is partial. The effect of 166 flooding an opaque Type 9 LSA can be minimized by setting its 167 DoNotAge bit, providing DoNotAging is enable on all routers connected 168 to its link-local network. What is presented here are two floodgate 169 tools. The first one opens its LSA floodgates fully during times of 170 topological need and then thins the LSA flow to a trickle during 171 times of topological plenty. The second floodgate tool thins LSA flow 172 in only one floodgated direction so that dynamic update in this 173 direction happens only when absolutely necessary or during periods of 174 normal application based traffic flow. Both floodgates are fully open 175 during adjacency formation, and close only after the adjacency 176 reaches Full state. 178 Partial floodgating is triggered between neighbors via Type 9 opaque 179 LSAs exchanged across their adjacent link. Each opaque LSA requires a 180 unique opaque type. Currently the floodgate option uses experimental 181 opaque type 225 until one is assigned. Opaque type 225 is referred to 182 as the floodgate opaque type in this document (See Appendix A). 184 Floodgating is enabled via a new interface configuration parameter 185 called FoodgateType (See Appendix A). This parameter defines the type 186 of floodgating which is performed across the interface. When set to 187 "1-Way", 1-Way floodgating is configured. When set to "2-Way", 2-Way 188 floodgating is configured. Both 1-Way and 2-Way floodgates work best 189 with the demand circuit processing of Hello packets, as defined in 190 [DC] Section 3.2, and the DoNotAge processing of LSAs, as defined in 191 [DC] Section 3.3. The requirements of Section 2.1's examples are only 192 met when floodgates, demand circuits, and DoNotAge processing are all 193 used. However, without demand circuit and DoNotAge processing, OSPF 194 floodgates still perform flooding optimization. 196 The base topology of an area is defined as all its network links plus 197 those router links which have no configured floodgate (1-Way or 2- 198 Way). In order for the area's routers to compute link state paths 199 through it's base topology, any router which has links with 200 floodgating configured must originate a floodgate Type 10 opaque LSA 201 into the area listing those links (See Appendix B). All routers along 202 the area's paths between routers with configured floodgated links 203 should be opaque capable. This guarantees router LSAs and floodgate 204 Type 10 opaque LSAs will be synchronized. As a precaution 205 implementations may choose to disable floodgating in an area when any 206 of the area's routers are not opaque capable. 208 2.2.1 2-Way Floodgates 210 2-Way floodgates partially suppress flooding in both directions. Both 211 routers must agree on the floodgate type (either 1-Way or 2-Way) and 212 meet each other's floodgate activation criteria (See Sections 4.1 and 213 5.1) before floodgating may occur. 2-Way floodgating is enabled via 214 transmitted and received floodgate Type 9 LSAs (See Appendix A). When 215 performing SPF calculations, routers with configured 2-way floodgates 216 must confirm the reachability across the area's base topology of 217 their neighboring routers on the other side of their 2-Way 218 floodgates. 220 If an adjacent neighbor on the other side of a 2-Way floodgate 221 becomes unreachable across the area's base topology, then the 222 floodgate is opened for normal link state update. When the floodgate 223 initially opens, the neighbor state machine drops to ExStart state 224 forcing the link state database to resynchronize (See Section 3.5). 226 2.2.2 1-Way Floodgates 228 1-Way floodgates allow full updating in one direction and suppress 229 updating in the other floodgated direction. Both routers must agree 230 on the floodgate type before 1-Way floodgating may occur. 1-Way 231 floodgating is activated via a floodgate Type 9 LSA (See Appendix A). 232 This is necessary to provide a vehicle by which each neighbor may 233 open the floodgate. 235 The implementation of 1-Way Floodgates is facilitated by partitioning 236 an area into sub-areas. By default a router belongs to sub-area 0, 237 but may be configured to belong to a distinct non-zero sub-area. A 238 1-Way floodgate is always configured between a sub-area 0 router and 239 a non-zero sub-area router. The direction of the partial flow is 240 always from sub-area 0 to the non-zero sub-area. A transit network 241 belongs to each sub-area of any router which connects to it. Area 242 border routers will always belong to sub-area 0. When a 1-Way 243 floodgate is configured on a non-zero sub-area router, in addition to 244 listing its 1-Way and 2-Way floodgated links in its floodgate Type 10 245 LSA, the router must also define its non-zero sub-area ID (See 246 Appendix B). 248 A router with a configured floodgate (either 1-Way or 2-Way) is 249 called a gatekeeper. Each floodgate has two gatekeepers, one on each 250 side of the floodgate. A gatekeeper always opens its 1-Way floodgates 251 when it receives a default advertisement from a reachable non-zero 252 sub-area router. Furthermore it keeps its 1-Way floodgates open as 253 long as there exists a default advertisement from a reachable non- 254 zero sub-area router. All of an area's default advertisements must 255 originate either from a sub-area 0 router or from outside the area 256 before any of the area's 1-Way floodgates will close. If there is no 257 installed default through sub-area 0 then a gatekeeper's 1-Way 258 floodgates are opened and remain open until default is restored 259 through sub-area 0. 261 Since flooding is suppressed across 1-Way floodgates, sub-area 262 routers should have a SPF tree which ensures a stable flooding and 263 forwarding path within each sub-area. During the Shortest Path First 264 (SPF) calculation a gatekeeper should verify that the SPF Tree's 265 branches which leave the local router's sub-area never return as they 266 grow toward the extremities of the area. This check need only be 267 performed by the gatekeepers. If a gatekeeper fails to meet this 268 criteria it opens all of its floodgates. 270 2.3 Application 272 Consider now the first example mentioned in Section 2.1 and assume 273 2-Way floodgates are configured over the dialup links from D1 to A1, 274 B1, and C1. Furthermore assume DoNotAge processing is in effect 275 within Area 1 and that the dialup links from D1 to A1, B1, and C1 276 have Demand Circuit enabled. Since a full flooding path exists from 277 A1 and B1 to D1 through A0 the floodgates between D1 and its 278 neighbors, A1 and B1, remain closed and the flapping of the dedicated 279 link between A0 and C1 only effects the floodgate between D1 and C1. 280 The dialup backup links from D1 to A1 and B1 are unaffected and no 281 link state update occurs over these links during this outage. 283 In the second example we again assume DoNotAge processing is in 284 effect within Area 1 and that the dialup links from D1 to L1, L2, and 285 L3 have Demand Circuit enabled. The L1/N1, L2/N2, and L3/N3 286 topologies are configured in sub-areas 1, 2 and 3 respectively, while 287 the remaining Area 1 routers are left in sub-area 0. 1-Way floodgates 288 are configured between D1 and L1, L2 and L3. Assume the default path 289 for Area 1 is through A0. When the link between B1 and A0 flaps up 290 and down, the 1-Way floodgates between D1 and L1, L2 and L3 remain 291 closed since the default path of their respective sub-areas has not 292 changed. No link state update occurs over these links during this 293 outage. 295 3.0 Floodgate Implementation Details 297 3.1 Interface Data Structure 299 Floodgating is enabled via a new interface configuration parameter 300 called FoodgateType (See Appendix A). This parameter defines the type 301 of floodgating which is performed across the interface. When set to 302 "None", there is no floodgate configured for the interface. When set 303 to "1-Way", 1-Way floodgating is configured. When set to "2-Way", 2- 304 Way floodgating is configured. The default setting of FloodgateType 305 for any interface is "None". Floodgates are activated on a per 306 neighbor basis. Only neighbors at Full state may have active 307 floodgates. 309 3.2 Neighbor Data Structure 311 Floodgate state transition is added to the neighbor state machine. In 312 support of floodgate state transition, three new elements are added 313 to the neighbor data structure: the Floodgate Delay Timer, the 314 Floodgate State, and the UpdateLinkState flag. The Floodgate State 315 parameter shows the current state of the floodgate. When the neighbor 316 data structure is first created, its Floodgate State parameter is 317 initialized to either "Disabled" or "InActive" depending on whether 318 the interface FloodgateType parameter is respectively "None" or 319 either "1-Way" or "2-Way". As a floodgate transitions from InActive 320 to Active state it assumes intermediate values of Init, 1-Way, and 321 Waiting (See Section 3.3 below). 323 When a floodgate transitions out of Active state, the link state data 324 base must be resynchronized with that of its adjacent neighbor. This 325 is accomplished by dropping the neighbor to ExchangeStart state. The 326 UpdateLinkState parameter is set to "disabled" so that a new router- 327 LSA and possible network-LSA is not reoriginated. All other events 328 which drop a neighbor out of full state set the UpdateLinkState 329 parameter to "enabled". 331 A floodgate's gatekeeper resets and starts the single shot Floodgate 332 Delay Timer of one its floodgated neighbors's when all of the 333 following conditions are all met: 335 o the neighbor meets the gatekeeper's floodgate activation 336 criteria (See Sections 4.1 and 5.1). 338 o the neighbor's signals that the gatekeeper meets its floodgate 339 activation criteria by listing it as opaque data in its Type 9 340 LSA (See Sections 4.2 and 5.2). 342 o the neighbor has reached Full state. 344 See Sections 3.4 and 3.5 below for details. Normal flooding continues 345 until the timer fires, at which time the floodgate closes and starts 346 suppressing flooding across the link. This ensures a stable flooding 347 path within the area. The current value of the Floodgate Delay Timer 348 is 300 seconds. 350 When a lower layer protocol activity timer is in effect for the 351 floodgated link, non-OSPF traffic over the link should reset the 352 Floodgate Delay Timer using the ResetFloodgate event (See Section 3.4 353 and Appendix C). When a floodgate is closed lower layer activity may 354 also open a floodgate by triggering the ResetFloodgate event (See 355 Section 3.4). While the Floodgate Delay Timer is counting down, the 356 floodgate is still open. 358 3.3 Floodgate States 360 The various states that OSPF floodgates may attain is documented in 361 this section. These states are listed in order of progressing 362 functionality. For example, the inoperative state, InActive, is 363 listed before the intermediate states Init, 1-Way, and Waiting. The 364 last state, Active, is the fully operational floodgate state. The 365 specification makes use of this ordering by sometimes making 366 references such as "in state greater than X". During all floodgate 367 states less than Active full link state update with the neighbor is 368 in effect and the floodgate is said to be fully open. 370 Disabled 371 This state indicates no floodgate is configured. 373 InActive 374 This state indicates the floodgated neighbor does not meet the 375 local router's floodgate activation criteria (See Sections 4.1 376 and 5.1). 378 Init 379 This state indicates the floodgated neighbor meets the local 380 router's floodgate activation criteria but a floodgate Type 9 381 LSA with matching floodgate type has not been received from the 382 neighbor. 384 1-Way 385 This state indicates the neighbor's floodgate Type 9 LSA was 386 received with matching floodgate type but the local router is 387 not listed in the LSA's opaque data, implicating the local 388 router does not yet meet the neighbor's floodgate activation 389 criteria. 391 Waiting 392 This state indicates the neighbor's floodgate Type 9 LSA has 393 been received with matching floodgate type and it lists the 394 local router in the LSA's opaque data, implying the local 395 router does meet the neighbor's floodgate activation criteria. 397 Active 398 In this state, the floodgate between the neighbor has closed 399 and it is actively suppressing link state update. 401 3.4 Floodgate Events 403 The following new events are defined in support of floodgates. 405 OpenFloodgate 406 Both 1-Way and 2-Way floodgates have floodgate activation 407 criteria which must be met for these floodgates to remain 408 closed. When a gatekeeper observes that the floodgate 409 activation criteria of its floodgated neighbor is no longer 410 met, this event is triggered (See Sections 4.1 and 5.1). 411 Following this event the floodgate transitions from closed to 412 open. Floodgates may also be opened by lower layer protocols 413 when dial-up links are active. 415 ReleaseFloodgate 416 When a gatekeeper observes the floodgate activation criteria of 417 its floodgated neighbor is now met, whereas before it was not, 418 then this event is triggered, releasing the floodgate for 419 closure process. (See Sections 4.1 and 5.1). 421 FloodgateDelayTimer 422 When this timer fires, it signals the fact that the neighbor's 423 floodgated has been in Waiting state for the full duration of 424 the timer during which all necessary criteria for closing the 425 floodgate have been met. Its firing causes the floodgate to 426 close and flooding suppression to begin. 428 ResetFloodgate 429 Lower layer protocols have indicated the floodgate should be 430 opened due to non-OSPF traffic flow. 432 1-Way9Received 433 A floodgate Type 9 LSA has been received in which the local 434 router is not mentioned. Either the floodgated neighbor has not 435 received a floodgate Type 9 LSA from the local router, or the 436 local router no longer meets the neighbor's floodgate 437 activation criteria. 439 2-Way9Received 440 A floodgate Type 9 LSA has been received in which the local 441 router is listed. Thus the neighbor has received the local 442 router's floodgate Type 9 LSA and the local router meets the 443 neighbor's floodgate activation criteria. 445 3.5 Floodgate State Transitions 447 Several neighbor state machine events effect floodgate state. If the 448 floodgate's state is greater than InActive, any change in the 449 floodgated neighbor's Full state results in the floodgate's state 450 dropping to Init state. If the floodgate's state is Waiting when the 451 neighbor event LoadingDone is triggered, the Floodgate Delay Timer is 452 reset and started. Otherwise no action is taken. All neighbor state 453 machine events which drop a neighbor out of full state must set the 454 UpdateLinkState parameter to "enabled". 456 When an OpenFloodgate event occurs and the floodgate's state is 457 greater than InActive then the new state is set to InActive and a new 458 floodgate Type 9 LSA is originated omitting the neighbor from its 459 opaque data. If the floodgate's old state is Active it sets the 460 UpdateLinkState to disabled and triggers the neighbor's state machine 461 to perform the same action as a SeqNumMismatch event, thus dropping 462 the neighbor's state to ExStart. No new router-LSA or network-LSA is 463 generated during the data base resynchronization unless problems 464 occur. 466 When a ResetFloodgate event occurs and the floodgate's state is 467 Active then set the UpdateLinkState to "disabled" and trigger the 468 neighbor's state machine to perform the same action as a 469 SeqNumMismatch event, thus dropping the neighbor's state to ExStart. 471 Following any ResetFloodgate event where the floodgate state is 472 greater than InActive then 474 (1) If there does not exist an acknowledged floodgate Type 9 LSA 475 for the neighbor set the floodgate state to Init, 477 (2) Else if an acknowledged floodgate Type 9 LSA exists but it 478 does not list the local router then set the floodgate state to 479 1-Way, 481 (3) Else the acknowledged floodgate Type 9 LSA does list the local 482 router, so set the floodgate state to Waiting. If the 483 floodgated neighbor's state machine is in Full state, start 484 the Floodgate Delay Timer. 486 When a ReleaseFloodgate event occurs and the Floodgate state is 487 InActive then 489 (1) If there does not exist an acknowledged floodgate Type 9 LSA 490 for the neighbor set the floodgate state to Init, 492 (2) Else if an acknowledged floodgate Type 9 LSA exists but it 493 does not list the local router, then set the floodgate state 494 to 1-Way, 496 (3) Else the acknowledged floodgate Type 9 LSA does list the local 497 router, so set the floodgate state to Waiting. If the 498 floodgated neighbor's state machine is in Full state, start 499 the Floodgate Delay Timer. 501 Once a floodgate is released it may transition between the Init, 1- 502 Way and Waiting states toward activation and closure. The events 503 which effect these state transitions are described below. 505 When a 1-Way9Received event occurs and the floodgate's state is 506 Active, set the UpdateLinkState to disabled and trigger the 507 neighbor's state machine to perform the same action as a 508 SeqNumMismatch event, thus dropping the neighbor's state to ExStart. 510 When a 1-Way9Received event occurs and the floodgate's state is 511 Waiting, stop a running Floodgate Delay Timer. 513 Following any 1-Way9Received event where the floodgate's state is 514 greater than InActive, set the floodgate's state to 1-Way. 516 When a 2-Way9Received event occurs, if the floodgate's state is Init 517 or 1-Way then set the floodgate's state to Waiting and, if the 518 floodgated neighbor's state machine is in Full state, reset and start 519 the Floodgate Delay Timer. 521 When the Floodgate Delay Timer fires it triggers the 522 FloodgateDelayTimer event. If the Floodgate state is Waiting then the 523 Floodgate is closed and flooding suppression begins. 525 3.6 Receiving Floodgate Type 9 LSAs 527 When a new functionally different floodgate Type 9 LSA is received or 528 acknowledged across a floodgated interface during link state update 529 or database exchange, its floodgate type is compared with that of the 530 receiving interface. If they do not match then any existing neighbor 531 state machine for the neighbor is executed with the OpenFloodgate 532 event, and processing of this received floodgate Type 9 LSA 533 terminates. 535 Otherwise the opaque data of the floodgate Type 9 LSA is checked to 536 see if the local router is listed. If it is not, then the neighbor's 537 state machine is executed with the event 1-Way9Received. If it is 538 listed, then the neighbor state machine is executed with the event 539 2-Way9Received. 541 3.7 Originating Floodgate Type 10 LSAs 543 In order to compute link state paths through an area's base topology, 544 all of the area's routers with configured floodgates (1-Way and 2- 545 Way) must originate a floodgate Type 10 LSA which lists those links 546 (See Appendix B). In addition a router advertises its sub-area ID in 547 its floodgate Type 10 LSA. By default a router's sub-area ID is set 548 to 0. only routers with a non-zero sub-area ID in their area data 549 structures must originate a Type 10 LSA specifying its value in the 550 Sub-area ID field and must do so even when they do not have any 551 configured floodgates. All routers in an area with configured 552 floodgates should be opaque capable, otherwise the flooding of 553 floodgate Type 10 LSAs may be incomplete and some floodgates may 554 close inappropriately. When a new router LSA is originated by a 555 router for a area in which the router has configured floodgates, the 556 router should also originate a new floodgate Type 10 LSA into the 557 area. This keeps router LSAs and floodgate Type 10 LSAs closely 558 synchronized. As a precaution implementations may choose to disable 559 floodgating in an area when any of the area's routers are not opaque 560 capable. 562 3.8 Link State Acknowledgment and Retransmission 564 It is entirely possible that two gatekeepers on each side of a 565 floodgate may close their side of the floodgate asynchronously. Any 566 received link state update packets must still be properly received 567 and acknowledged. Any link state requests or non-empty link state 568 retransmission list must still be processed. Thus residual link state 569 update may continue for a while following the closure of a floodgate. 570 Floodgate closure simply means any newly received or originated LSAs, 571 except for Type 9 LSAs, are not flooded out an interface with a 572 closed floodgate unless requested. Note that 1-Way floodgates are 573 only closed in one direction. Full flooding occurs in the other 574 direction. 576 This fact has a direct impact on interfaces of broadcast type. 577 Floodgates do work over these types of interfaces, but functionality 578 is impacted by the multicasting of link state update. For the most 579 part floodgates over broadcast networks are only effective when there 580 are closed foodgates between the DR and Backup DR, plus all of their 581 adjacent neighbors. These floodgates will still eventually close as 582 the closure of floodgates is not effected by current link state 583 update once two neighbors have reached Full state. 585 4.0 2-Way Floodgate Implementation Details 587 While floodgate state transition is basically the same for both 2-Way 588 and 1-Way floodgates, floodgate activation criteria are notably 589 different. When a 2-Way Floodgate is active, it is assumed that an 590 interface's floodgated neighbors are reachable via the area's base 591 topology. Every router with configured floodgates (1-Way and 2-Way) 592 must originate a Type 10 LSA specifying their floodgated links. These 593 links are removed from the area's link state data base to form the 594 base topology. The base topology provides a flooding path between the 595 two neighbors which avoids any floodgated links. When two floodgated 596 neighbors are reachable across the base topology, the flooding of all 597 LSAs, except for Type 9 LSAs, may be suppressed across an active 2- 598 Way floodgate. The effects of Type 9 LSA flooding and Hello packet 599 exchange can be further mitigated with demand circuit and DoNotAge 600 processing. 602 4.1 2-Way Floodgate State Transitions 604 When the link state data base of an area changes, each of its routers 605 with configured 2-Way floodgates must recheck the reachability of 606 it's floodgated neighbors across the area's base topology. If a 2-Way 607 floodgated neighbor becomes newly unreachable across the area's base 608 topology, then the OpenFloodgate event should be triggered. This 609 causes the neighbor's 2-Way floodgate to fully open and its floodgate 610 state to transition to InActive. A new floodgate Type 9 LSA is 611 originated at the floodgated interface with the neighbor omitted from 612 its opaque data. If a 2-Way floodgated neighbor becomes newly 613 reachable across the area's base topology, then the ReleaseFloodgate 614 event should be triggered. This causes the 2-Way floodgate to 615 transition out of InActive state and to begin the process of swinging 616 shut. 618 Lower layer protocols may open a 2-Way floodgate with the 619 ResetFloodgate event. Non-OSPF traffic in either direction may 620 trigger this event and will keep the floodgate in Waiting state until 621 a lower layer protocol inactivity timer fires. Lower layer protocol 622 inactivity timers need to be modified to ignore OSPF protocol 89 in 623 both directions across 2-Way floodgated links. Note that floodgates 624 do not stop the normal exchange of Hello packets. Only OSPF DDR 625 suppresses Hello packets. 627 4.2 Originating 2-Way Floodgate Type 9 LSAs 629 Floodgate Type 9 LSAs are originated across every 2-Way floodgated 630 interface with their Floodgate Type set to 2-Way. In addition those 631 neighbors which are reachable across the area's base topology and 632 from whom acknowledged floodgate Type 9 LSAs have been received (or 633 acknowledged during database exchange) with matching floodgate type, 634 are listed in the LSAs opaque data (See Appendix A). 636 5.0 1-Way Floodgate Implementation Details 638 For a 1-Way Floodgate to be active in an area, the area must be 639 partitioned into sub-areas. A router may belong to only one sub-area. 640 Each router of a non-zero sub-area must declare its Sub-area ID even 641 when it has no configured floodgates. This is done via a floodgate 642 Type 10 LSA. By default a router belongs to sub-area 0. Thus routers 643 in sub-area 0 only need originate a floodgate Type 10 LSA if they 644 have configured floodgates (See Section 3.7). A new area 645 configuration parameter called Sub-area ID is used to set the sub- 646 area ID of an area's internal routers. Border routers are always in 647 sub-area 0. 649 Like a stub area, a non-zero sub-area uses OSPF's classless default 650 to forward traffic destined outside its borders. Default forwarding 651 is not always optimum when there are multiple floodgates bordering a 652 non-zero sub-area, as the part of the areas's LSDB which is external 653 to the non-zero sub-area may age out or become obsolete. The non-zero 654 sub-area side of a 1-Way floodgate always performs dynamic link state 655 update with the sub-area 0 side of the floodgate. Thus sub-area 0 has 656 a full link state database of the area's entire topology. When a 1- 657 Way floodgate is closed, the sub-area 0 side of a floodgate 658 suppresses all LSA updates, except for Type 9 LSAs, to the non-zero 659 sub-area side of the floodgate. 661 5.1 1-Way Floodgate State Transitions 663 Maintaining a default path and border router reachability are very 664 important floodgate activation criteria to the health of a 1-Way 665 floodgate. A sub-area 0 router will keep its 1-Way floodgates closed 666 only when all of its default next-hops are over non-floodgated sub- 667 area 0 links. If a sub-area 0 router's new default installation has a 668 next-hop in a non-zero sub-area, whereas its old default next hop was 669 in sub-area 0, the OpenFloodgate event is triggered for all of the 670 router's 1-Way floodgated neighbors. This causes these neighbors' 671 floodgates to fully open and their floodgate states to transition to 672 InActive. If a sub-area 0 router looses its default through sub-area 673 0 it triggers the OpenFloodgate event for all of its 1-Way floodgated 674 neighbors. 676 A non-zero sub-area router must install a default next-hop from an 677 advertisement originating outside the area's non-zero sub-areas. 678 Unfortunately a non-zero sub-area router with a configured 1-Way 679 floodgate has no easy way of knowing what default path(s) the other 680 routers in its sub-area install. To circumvent this problem, a non- 681 zero sub-area router should trigger an OpenFloodgate event for any 682 1-Way floodgated neighbor when it receives a default advertisement 683 from any reachable non-zero sub-area router, even ones from a 684 different non-zero sub-area. This rule ensures that a default path 685 will eventually trail out of the area through sub-area 0. It even 686 allows for the unwise case when two non-zero sub-areas neighbor each 687 other. In configuration terms, a non-zero sub-area router should 688 never originate a default advertisement, as that may disable 1-Way 689 floodgating throughout the entire area. Since a non-zero sub-area 690 router performs full flooding over all of its interfaces, even those 691 with configured 1-Way floodgates, it has no other floodgate 692 activation criteria. Note that non-zero sub-areas may even partition 693 with no effect, as they simply become separate non-zero sub-areas. 695 Even though the link state database of a non-zero sub-area is 696 synchronized within the sub-area, because of its 1-Way floodgates it 697 is highly unlikely a non-zero sub-area will have sufficient link 698 state information to transit the rest of the area's traffic through 699 its topology unless its floodgates are open. Hence any sub-area 0 700 router with configured 1-Way floodgates should ensure during the 701 Shortest Path First calculation that no sub-area 0 router is directly 702 below a non-zero sub-area router on its Shortest Path First tree. 703 When this is the case sub-area 0 is said to be topologically concave. 704 When a sub-area 0 router's Shortest Path First calculation indicates 705 sub-area 0 is no longer topologically concave, it should trigger an 706 OpenFloodgate event for all of its 1-Way floodgates. 708 If, as a result of a sub-area 0 router's Shortest Path First 709 calculation, the router determines that all of its installed defaults 710 have next hop in sub-area 0 and that sub-area 0 is topologically 711 concave, then the ReleaseFoodgate event is triggered for all of its 712 1-Way floodgated neighbors. If on a non-zero sub-area router the last 713 advertisement for default originating from a non-zero sub-area router 714 ages out or is flushed, or the router which originated this default 715 advertisement becomes unreachable and there still exists an installed 716 SPF default, then the ReleaseFloodgate event should be triggered for 717 all of its 1-Way floodgated neighbors. These conditions cause a 1-Way 718 floodgate to transition out of InActive state and to begin the 719 process of swinging shut. 721 5.2 Originating 1-Way Floodgate Type 9 LSAs 723 Floodgate Type 9 LSAs are originated across every 1-Way floodgated 724 interface with the Floodgate Type set to 1-Way. Furthermore a 1-Way 725 floodgated neighbor is listed in the LSA's opaque data when 727 o a floodgate Type 9 LSA has been received from the neighbor with 728 matching 1-Way Floodgate Type, 730 o a floodgate Type 10 LSA has been received from the neighbor with 731 the appropriate Sub-area ID, and 733 o the neighbor meets the local router's floodgate activation 734 criteria. 736 Two non-zero sub-area routers may never form a 1-Way floodgate, even 737 though they can still be neighbors. In practice two distinct non-zero 738 sub-areas which have mutually adjacent neighbors simply form a single 739 non-zero sub-area even though they have different non-zero Sub-area 740 IDs. While the Sub-area ID is a good mental tool for keeping tract of 741 sub-areas, the boundaries of a non-zero sub-area are determined by 742 where it meets sub-area 0, and not by the sub-area ID sameness or 743 difference of its router members. 745 6.0 Floodgate Extensions 747 The floodgate machinery defined in Section 3.0 through Section 3.7 748 provides the necessary tools for adding additional floodgate 749 extensions. The Floodgate Type field in the floodgate Type 9 LSA 750 reserves values 0 through 127 for future floodgate extensions. Values 751 128 through 255 may be used for experimentation or implementation 752 specific value added features. Currently only three values are 753 assigned, 0 for no floodgating, 1 for 1-Way floodgating and, 2 for 754 2-Way floodgating. 756 A notable floodgate extension omission is a floodgate which 757 suppresses the flooding of summary-LSAs and AS-external-LSAs from a 758 sub-area 0 router to a non-zero sub-area router. It would function 759 much like a 1-Way floodgate but its floodgate activation criteria is 760 much simpler. 762 7.0 Security Considerations 764 Security issues are not discussed in this memo. 766 8.0 Acknowledgments 768 This document was produced by the OSPF Working Group, chaired by John 769 Moy. In addition, comments from the following individuals are also 770 acknowledged: 772 Acee Lindem IBM 774 9.0 References 776 [DC] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 777 1793, Cascade Communication Corp., April 1995. 779 [MIB] McCloghrie, K., and M. Rose, "Management Information Base for 780 network management of TCP/IP-based internets: MIB-II", STD 781 17, RFC 1213, Hughes LAN Systems, Performance Systems 782 International, March 1991. 784 [OPAQ] Coltun, Rob, "The OSPF Opaque LSA Option", FORE Systems, 785 August 1998. 787 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, Ascend Communications, 788 Inc., April 1998. 790 [1583] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 791 1994. 793 10.0 Author's Address 795 Pat Murphy 796 US Geological Survey 797 345 Middlefield Road, Mail Stop 870 798 Menlo Park, California 94560 800 Phone: (650)329-4044 801 EMail: pmurphy@noc.doi.net 803 Appendix A. Floodgate Type 9 LSAs 805 Floodgate Type 9 LSAs are used directly by OSPF to synchronize floodgate 806 state between neighboring routers over links. These LSAs are flooded across 807 the floodgated link. The flooding scope of floodgate type 9 LSAs is 808 link-local, which means floodgate Type 9 LSAs are never forwarded beyond the 809 local (sub)network which contains their floodgates. 811 Section 3.5 of this document describes the purpose of this floodgate opaque 812 LSA in more detail. 814 0 1 2 3 815 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 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | LS age | Options | LSA Type 9 | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Opaque Type | Opaque ID | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Advertising Router | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | LS Sequence Number | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | LS checksum | Length | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 |Floodgate type | 0 | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Observed Floodgate Ready Neighbor | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | ... | 833 Syntax of the floodgate Type 9 LSA's Link State ID 835 The link-state ID of the floodgate Type 9 LSA is divided into an 836 Opaque Type field (the first 8 bits), which has the floodgate 837 opaque type (225) value, and the Opaque ID (the remaining 24 838 bits). The floodgate Type 9 LSA's Opaque ID is set to the last 24 839 bits of the interface's IP address, if it has one. In the case of 840 unnumbered point-to-point connections, the floodgate Type 9 LSA's 841 Opaque ID is set to the last 24 bits of the interface's MIB-II 842 [MIB] ifIndex value. The most significant bits may be changed to 843 ensure uniqueness. 845 Floodgate Type 846 This parameter is set to 0 when no floodgates are configured 847 for this link. It is set to 1 when 1-Way floodgating is 848 configured for the link and it is set to 2 when 2-way 849 floodgating is configured for the link. 851 Observed Floodgate Ready Neighbor 853 All neighbors from whom Floodgate Type 9 opaque LSAs have been 854 received and who meet the local router's floodgate activation 855 criteria are listed in at the end of Floodgate Type 9 LSA (See 856 Section 4.2. and 5.2). 858 Appendix B. Floodgate Type 10 LSAs 860 Floodgate Type 10 LSAs are used directly by OSPF to advertise inside 861 an area a router's list of floodgated links. The flooding scope of 862 floodgate Type 10 LSAs is areawide, which means floodgate Type 10 863 LSAs are never forwarded beyond the area border. A router which has 864 floodgated links must originate a floodgate Type 10 LSA listing those 865 links. If a router belongs to a non-zero sub-area, it must also 866 originate a floodgate Type 10 LSA which specifies its sub-area in the 867 Sub-area ID field. If a router has no floodgated links and belongs to 868 sub-area 0, it need not originate a floodgate Type 10 LSA. 870 Section 3.7 of this document describes the purpose of the floodgate 871 Type 10 LSA in more detail. 873 0 1 2 3 874 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 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | LS age | Options | LSA Type 10 | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | Opaque Type | Opaque ID | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Advertising Router | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | LS Sequence Number | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | LS checksum | Length | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Sub-area ID | # links | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Link ID | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Link Data | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | ... | 894 Syntax Of The Opaque LSA's Link State ID 896 The link-state ID of the floodgate Type 10 LSA is divided into an 897 Opaque Type field (the first 8 bits), which has value floodgate 898 (currently 224), and the Opaque ID (the remaining 24 bits). The 899 floodgate Type 10 Opaque ID is set to the last 24 bits of the OSPF 900 interface's IP address, if it has one. In the case of unnumbered 901 point-to-point connections, the floodgate Type 10 opaque ID is set 902 to the last 24 bits of the interface's MIB-II [MIB] ifIndex value. 903 The most significant bits may be changed to ensure uniqueness. 905 # links 906 The number of floodgated links listed in this LSA. This must be 907 the local router's total collection of floodgated links with 908 flooding suppression configured for the area. 910 Sub-area ID 911 An OSPF area with configured 1-Way floodgates must be broken 912 into OSPF sub-areas. 1-Way floodgates are configured between 913 routers in sub-area 0 and routers in non-zero sub-areas. By 914 default the Sub-area ID field is set to 0. A router specifies 915 its non-zero sub-area in the the Sub-area ID field. 917 The following fields are used to describe each of the router's 918 links. They must match their counterparts in the router's Type 1 919 (router) LSA for this area. 921 Link ID 922 The Router ID of the neighboring router that this router 923 connects to via a link. This provides the key for looking up 924 the neighboring LSA in the link state database during the 925 routing table calculation. See [OSPF] Section 12.2 for more 926 details. 928 Link Data 929 For unnumbered point-to-point connections, it specifies the 930 interface's MIB-II [MIB] ifIndex value. For the other link 931 types it specifies the router interface's IP address. This 932 latter piece of information is needed during the routing table 933 build process, when calculating the IP address of the next 934 hop. See [OSPF] Section 16.1.1 for more details. 936 Appendix C. Configuration Parameters 938 Floodgating is enabled via a new interface configuration parameter 939 called FoodgateType. When set to "None", there is no floodgate 940 configured for the interface. When set to "1-Way", 1-Way floodgating 941 is configured. When set to "2-Way", 2-Way floodgating is configured. 942 The default setting of FloodgateType for any interface is "None". A 943 maximum of 255 different floodgate types may be defined. Currently 944 only these three are defined. The first 128 floodgate types are 945 reserved for future additions to this specification. The remaining 946 128 floodgate types are available for experimentation and 947 implementation specific value added features (See Section 3.1). 949 A new area configuration parameter called Sub-area ID is used to set 950 the sub-area of an area's internal routers. It should not be possible 951 to set this parameter on a border router, as the border routers of an 952 area are always in sub-area 0. 954 A new interface configuration parameter called the ActivityTrigger 955 has been added. Its function is implemented by lower level protocols. 956 When set to enabled, non-OSPF IP traffic between two floodgated 957 neighbors may open a floodgate. When set to disabled, non-OSPF IP 958 traffic has no effect on the state of a floodgate.