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