idnits 2.17.1 draft-ietf-ospf-version2-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 7593 instances of lines with control characters in the document. == There are 49 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1381 has weird spacing: '... dist from ...' == Line 1679 has weird spacing: '... Packet name ...' == Line 1681 has weird spacing: '...aintain neigh...' == Line 1712 has weird spacing: '... type name...' == Line 2436 has weird spacing: '...virtual link....' == (13 more instances...) -- 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 (September 1996) is 10084 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) -- Looks like a reference, but probably isn't: '1' on line 1561 -- Looks like a reference, but probably isn't: '2' on line 2405 -- Looks like a reference, but probably isn't: '3' on line 2436 -- Looks like a reference, but probably isn't: '4' on line 2746 -- Looks like a reference, but probably isn't: '5' on line 3049 -- Looks like a reference, but probably isn't: '6' on line 3104 -- Looks like a reference, but probably isn't: '7' on line 3963 -- Looks like a reference, but probably isn't: '8' on line 4036 -- Looks like a reference, but probably isn't: '9' on line 4297 -- Looks like a reference, but probably isn't: '10' on line 4417 -- Looks like a reference, but probably isn't: '11' on line 4446 -- Looks like a reference, but probably isn't: '12' on line 4660 -- Looks like a reference, but probably isn't: '13' on line 4854 -- Looks like a reference, but probably isn't: '14' on line 4878 -- Looks like a reference, but probably isn't: '15' on line 5228 -- Looks like a reference, but probably isn't: '16' on line 5235 -- Looks like a reference, but probably isn't: '17' on line 5490 -- Looks like a reference, but probably isn't: '18' on line 5494 -- Looks like a reference, but probably isn't: '19' on line 5998 -- Looks like a reference, but probably isn't: '20' on line 6081 -- Looks like a reference, but probably isn't: '21' on line 6337 -- Looks like a reference, but probably isn't: '22' on line 6426 -- Looks like a reference, but probably isn't: '23' on line 6537 -- Looks like a reference, but probably isn't: '24' on line 6551 -- Looks like a reference, but probably isn't: '25' on line 6640 -- Looks like a reference, but probably isn't: '26' on line 7064 == Missing Reference: 'NA' is mentioned on line 9340, but not defined == Missing Reference: 'NM1' is mentioned on line 9337, but not defined == Missing Reference: 'NM2' is mentioned on line 9340, but not defined == Unused Reference: 'Ref19' is defined on line 7703, but no explicit reference was found in the text == Unused Reference: 'NA,NM1' is defined on line 9331, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref1' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref2' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref3' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref4' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref5' ** Downref: Normative reference to an Unknown state RFC: RFC 905 (ref. 'Ref6') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref7' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref8' ** Obsolete normative reference: RFC 1583 (ref. 'Ref9') (Obsoleted by RFC 2178) ** Obsolete normative reference: RFC 1519 (ref. 'Ref10') (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1700 (ref. 'Ref11') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref12' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref13' ** Obsolete normative reference: RFC 1293 (ref. 'Ref14') (Obsoleted by RFC 2390) ** Downref: Normative reference to an Informational RFC: RFC 1586 (ref. 'Ref15') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref16' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref17' ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. 'Ref18') -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref19' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref20' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref22' ** Obsolete normative reference: RFC 1771 (ref. 'Ref23') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. 'NA,NM1' Summary: 17 errors (**), 0 flaws (~~), 14 warnings (==), 44 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Moy 3 Internet Draft Cascade Communications Corp. 4 Expiration Date: March 1997 September 1996 5 File name: draft-ietf-ospf-version2-07.txt 7 OSPF Version 2 9 Status of this Memo 11 This document is an Internet-Draft. 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 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet- Drafts as 19 reference material or to cite them other than as "work in progress". 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This memo documents version 2 of the OSPF protocol. OSPF is a 30 link-state routing protocol. It is designed to be run internal to a 31 single Autonomous System. Each OSPF router maintains an identical 32 database describing the Autonomous System's topology. From this 33 database, a routing table is calculated by constructing a shortest- 34 path tree. 36 OSPF recalculates routes quickly in the face of topological changes, 37 utilizing a minimum of routing protocol traffic. OSPF provides 38 support for equal-cost multipath. Separate routes can be calculated 39 for each IP Type of Service. An area routing capability is 40 provided, enabling an additional level of routing protection and a 41 reduction in routing protocol traffic. In addition, all OSPF 42 routing protocol exchanges are authenticated. 44 The differences between this memo and RFC 1583 are explained in 45 Appendix G. All differences are backward-compatible in nature. 46 Implementations of this memo and of RFC 1583 will interoperate. 48 Please send comments to ospf@gated.cornell.edu. 50 Table of Contents 52 1 Introduction ........................................... 7 53 1.1 Protocol Overview ...................................... 7 54 1.2 Definitions of commonly used terms ..................... 8 55 1.3 Brief history of link-state routing technology ........ 11 56 1.4 Organization of this document ......................... 12 57 1.5 Acknowledgments ....................................... 13 58 2 The link-state database: organization and calculations 13 59 2.1 Representation of routers and networks ................ 13 60 2.1.1 Representation of non-broadcast networks .............. 15 61 2.1.2 An example link-state database ........................ 16 62 2.2 The shortest-path tree ................................ 20 63 2.3 Use of external routing information ................... 22 64 2.4 Equal-cost multipath .................................. 24 65 2.5 TOS-based routing ..................................... 25 66 3 Splitting the AS into Areas ........................... 25 67 3.1 The backbone of the Autonomous System ................. 26 68 3.2 Inter-area routing .................................... 27 69 3.3 Classification of routers ............................. 27 70 3.4 A sample area configuration ........................... 28 71 3.5 IP subnetting support ................................. 34 72 3.6 Supporting stub areas ................................. 35 73 3.7 Partitions of areas ................................... 36 74 4 Functional Summary .................................... 38 75 4.1 Inter-area routing .................................... 38 76 4.2 AS external routes .................................... 39 77 4.3 Routing protocol packets .............................. 39 78 4.4 Basic implementation requirements ..................... 42 79 4.5 Optional OSPF capabilities ............................ 43 80 5 Protocol data structures .............................. 44 81 6 The Area Data Structure ............................... 46 82 7 Bringing Up Adjacencies ............................... 49 83 7.1 The Hello Protocol .................................... 49 84 7.2 The Synchronization of Databases ...................... 50 85 7.3 The Designated Router ................................. 51 86 7.4 The Backup Designated Router .......................... 52 87 7.5 The graph of adjacencies .............................. 53 88 8 Protocol Packet Processing ............................ 53 89 8.1 Sending protocol packets .............................. 54 90 8.2 Receiving protocol packets ............................ 56 91 9 The Interface Data Structure .......................... 59 92 9.1 Interface states ...................................... 62 93 9.2 Events causing interface state changes ................ 64 94 9.3 The Interface state machine ........................... 66 95 9.4 Electing the Designated Router ........................ 68 96 9.5 Sending Hello packets ................................. 71 97 9.5.1 Sending Hello packets on NBMA networks ................ 72 98 10 The Neighbor Data Structure ........................... 73 99 10.1 Neighbor states ....................................... 75 100 10.2 Events causing neighbor state changes ................. 79 101 10.3 The Neighbor state machine ............................ 80 102 10.4 Whether to become adjacent ............................ 86 103 10.5 Receiving Hello Packets ............................... 87 104 10.6 Receiving Database Description Packets ................ 89 105 10.7 Receiving Link State Request Packets .................. 92 106 10.8 Sending Database Description Packets .................. 92 107 10.9 Sending Link State Request Packets .................... 94 108 10.10 An Example ............................................ 94 109 11 The Routing Table Structure ........................... 96 110 11.1 Routing table lookup .................................. 99 111 11.2 Sample routing table, without areas .................. 101 112 11.3 Sample routing table, with areas ..................... 101 113 12 Link State Advertisements (LSAs) ..................... 103 114 12.1 The LSA Header ....................................... 104 115 12.1.1 LS age ............................................... 105 116 12.1.2 Options .............................................. 105 117 12.1.3 LS type .............................................. 106 118 12.1.4 Link State ID ........................................ 106 119 12.1.5 Advertising Router ................................... 108 120 12.1.6 LS sequence number ................................... 108 121 12.1.7 LS checksum .......................................... 109 122 12.2 The link state database .............................. 110 123 12.3 Representation of TOS ................................ 110 124 12.4 Originating LSAs ..................................... 111 125 12.4.1 Router-LSAs .......................................... 114 126 12.4.1.1 Describing point-to-point interfaces ................. 117 127 12.4.1.2 Describing broadcast and NBMA interfaces ............. 118 128 12.4.1.3 Describing virtual links ............................. 118 129 12.4.1.4 Describing Point-to-MultiPoint interfaces ............ 119 130 12.4.1.5 Examples of router-LSAs .............................. 119 131 12.4.2 Network-LSAs ......................................... 121 132 12.4.2.1 Examples of network-LSAs ............................. 122 133 12.4.3 Summary-LSAs ......................................... 123 134 12.4.3.1 Originating summary-LSAs into stub areas ............. 125 135 12.4.3.2 Examples of summary-LSAs ............................. 126 136 12.4.4 AS-external-LSAs ..................................... 127 137 12.4.4.1 Examples of AS-external-LSAs ......................... 128 138 13 The Flooding Procedure ............................... 129 139 13.1 Determining which LSA is newer ....................... 133 140 13.2 Installing LSAs in the database ...................... 133 141 13.3 Next step in the flooding procedure .................. 135 142 13.4 Receiving self-originated LSAs ....................... 137 143 13.5 Sending Link State Acknowledgment packets ............ 138 144 13.6 Retransmitting LSAs .................................. 139 145 13.7 Receiving link state acknowledgments ................. 141 146 14 Aging The Link State Database ........................ 141 147 14.1 Premature aging of LSAs .............................. 142 148 15 Virtual Links ........................................ 143 149 16 Calculation of the routing table ..................... 145 150 16.1 Calculating the shortest-path tree for an area ....... 146 151 16.1.1 The next hop calculation ............................. 151 152 16.2 Calculating the inter-area routes .................... 153 153 16.3 Examining transit areas' summary-LSAs ................ 154 154 16.4 Calculating AS external routes ....................... 156 155 16.4.1 External path preferences ............................ 158 156 16.5 Incremental updates -- summary-LSAs .................. 159 157 16.6 Incremental updates -- AS-external-LSAs .............. 160 158 16.7 Events generated as a result of routing table changes 160 159 16.8 Equal-cost multipath ................................. 161 160 16.9 Building the non-zero-TOS portion of the routing table 162 161 Footnotes ............................................ 164 162 References ........................................... 168 163 A OSPF data formats .................................... 170 164 A.1 Encapsulation of OSPF packets ........................ 170 165 A.2 The Options field .................................... 172 166 A.3 OSPF Packet Formats .................................. 174 167 A.3.1 The OSPF packet header ............................... 175 168 A.3.2 The Hello packet ..................................... 177 169 A.3.3 The Database Description packet ...................... 179 170 A.3.4 The Link State Request packet ........................ 181 171 A.3.5 The Link State Update packet ......................... 183 172 A.3.6 The Link State Acknowledgment packet ................. 185 173 A.4 LSA formats .......................................... 187 174 A.4.1 The LSA header ....................................... 188 175 A.4.2 Router-LSAs .......................................... 190 176 A.4.3 Network-LSAs ......................................... 194 177 A.4.4 Summary-LSAs ......................................... 195 178 A.4.5 AS-external-LSAs ..................................... 197 179 B Architectural Constants .............................. 199 180 C Configurable Constants ............................... 201 181 C.1 Global parameters .................................... 201 182 C.2 Area parameters ...................................... 202 183 C.3 Router interface parameters .......................... 203 184 C.4 Virtual link parameters .............................. 205 185 C.5 NBMA network parameters .............................. 206 186 C.6 Point-to-MultiPoint network parameters ............... 207 187 C.7 Host route parameters ................................ 207 188 D Authentication ....................................... 208 189 D.1 Null authentication .................................. 208 190 D.2 Simple password authentication ....................... 208 191 D.3 Cryptographic authentication ......................... 209 192 D.4 Message generation ................................... 211 193 D.4.1 Generating Null authentication ....................... 212 194 D.4.2 Generating Simple password authentication ............ 212 195 D.4.3 Generating Cryptographic authentication .............. 212 196 D.5 Message verification ................................. 214 197 D.5.1 Verifying Null authentication ........................ 214 198 D.5.2 Verifying Simple password authentication ............. 214 199 D.5.3 Verifying Cryptographic authentication ............... 214 200 E An algorithm for assigning Link State IDs ............ 216 201 F Multiple interfaces to the same network/subnet ....... 218 202 G Differences from RFC 1583 ............................ 219 203 G.1 Enhancements to OSPF authentication .................. 219 204 G.2 Addition of Point-to-MultiPoint interface ............ 219 205 G.3 Support for overlapping area ranges .................. 220 206 G.4 A modification to the flooding algorithm ............. 221 207 G.5 Introduction of the MinLSArrival constant ............ 221 208 G.6 Optionally advertising point-to-point links as subnets 222 209 G.7 Advertising same external route from multiple areas .. 222 210 Security Considerations .............................. 225 211 Author's Address ..................................... 225 212 1. Introduction 214 This document is a specification of the Open Shortest Path First 215 (OSPF) TCP/IP internet routing protocol. OSPF is classified as an 216 Interior Gateway Protocol (IGP). This means that it distributes 217 routing information between routers belonging to a single Autonomous 218 System. The OSPF protocol is based on link-state or SPF technology. 219 This is a departure from the Bellman-Ford base used by traditional 220 TCP/IP internet routing protocols. 222 The OSPF protocol was developed by the OSPF working group of the 223 Internet Engineering Task Force. It has been designed expressly for 224 the TCP/IP internet environment, including explicit support for IP 225 subnetting, TOS-based routing and the tagging of externally-derived 226 routing information. OSPF also provides for the authentication of 227 routing updates, and utilizes IP multicast when sending/receiving 228 the updates. In addition, much work has been done to produce a 229 protocol that responds quickly to topology changes, yet involves 230 small amounts of routing protocol traffic. 232 1.1. Protocol overview 234 OSPF routes IP packets based solely on the destination IP 235 address and IP Type of Service found in the IP packet header. 236 IP packets are routed "as is" -- they are not encapsulated in 237 any further protocol headers as they transit the Autonomous 238 System. OSPF is a dynamic routing protocol. It quickly detects 239 topological changes in the AS (such as router interface 240 failures) and calculates new loop-free routes after a period of 241 convergence. This period of convergence is short and involves a 242 minimum of routing traffic. 244 In a link-state routing protocol, each router maintains a 245 database describing the Autonomous System's topology. This 246 database is referred to as the link-state database. Each 247 participating router has an identical database. Each individual 248 piece of this database is a particular router's local state 249 (e.g., the router's usable interfaces and reachable neighbors). 250 The router distributes its local state throughout the Autonomous 251 System by flooding. 253 All routers run the exact same algorithm, in parallel. From the 254 link-state database, each router constructs a tree of shortest 255 paths with itself as root. This shortest-path tree gives the 256 route to each destination in the Autonomous System. Externally 257 derived routing information appears on the tree as leaves. 259 OSPF calculates separate routes for each Type of Service (TOS). 261 When several equal-cost routes to a destination exist, traffic 262 is distributed equally among them. The cost of a route is 263 described by a single dimensionless metric. 265 OSPF allows sets of networks to be grouped together. Such a 266 grouping is called an area. The topology of an area is hidden 267 from the rest of the Autonomous System. This information hiding 268 enables a significant reduction in routing traffic. Also, 269 routing within the area is determined only by the area's own 270 topology, lending the area protection from bad routing data. An 271 area is a generalization of an IP subnetted network. 273 OSPF enables the flexible configuration of IP subnets. Each 274 route distributed by OSPF has a destination and mask. Two 275 different subnets of the same IP network number may have 276 different sizes (i.e., different masks). This is commonly 277 referred to as variable length subnetting. A packet is routed 278 to the best (i.e., longest or most specific) match. Host routes 279 are considered to be subnets whose masks are "all ones" 280 (0xffffffff). 282 All OSPF protocol exchanges are authenticated. This means that 283 only trusted routers can participate in the Autonomous System's 284 routing. A variety of authentication schemes can be used; in 285 fact, separate authentication schemes can be configured for each 286 IP subnet. 288 Externally derived routing data (e.g., routes learned from an 289 Exterior Gateway Protocol such as BGP; see [Ref23]) is 290 advertised throughout the Autonomous System. This externally 291 derived data is kept separate from the OSPF protocol's link 292 state data. Each external route can also be tagged by the 293 advertising router, enabling the passing of additional 294 information between routers on the boundary of the Autonomous 295 System. 297 1.2. Definitions of commonly used terms 299 This section provides definitions for terms that have a specific 300 meaning to the OSPF protocol and that are used throughout the 301 text. The reader unfamiliar with the Internet Protocol Suite is 302 referred to [Ref13] for an introduction to IP. 304 Router 305 A level three Internet Protocol packet switch. Formerly 306 called a gateway in much of the IP literature. 308 Autonomous System 309 A group of routers exchanging routing information via a 310 common routing protocol. Abbreviated as AS. 312 Interior Gateway Protocol 313 The routing protocol spoken by the routers belonging to an 314 Autonomous system. Abbreviated as IGP. Each Autonomous 315 System has a single IGP. Separate Autonomous Systems may be 316 running different IGPs. 318 Router ID 319 A 32-bit number assigned to each router running the OSPF 320 protocol. This number uniquely identifies the router within 321 an Autonomous System. 323 Network 324 In this memo, an IP network/subnet/supernet. It is possible 325 for one physical network to be assigned multiple IP 326 network/subnet numbers. We consider these to be separate 327 networks. Point-to-point physical networks are an exception 328 - they are considered a single network no matter how many 329 (if any at all) IP network/subnet numbers are assigned to 330 them. 332 Network mask 333 A 32-bit number indicating the range of IP addresses 334 residing on a single IP network/subnet/supernet. This 335 specification displays network masks as hexadecimal numbers. 336 For example, the network mask for a class C IP network is 337 displayed as 0xffffff00. Such a mask is often displayed 338 elsewhere in the literature as 255.255.255.0. 340 Point-to-point networks 341 A network that joins a single pair of routers. A 56Kb 342 serial line is an example of a point-to-point network. 344 Broadcast networks 345 Networks supporting many (more than two) attached routers, 346 together with the capability to address a single physical 347 message to all of the attached routers (broadcast). 348 Neighboring routers are discovered dynamically on these nets 349 using OSPF's Hello Protocol. The Hello Protocol itself 350 takes advantage of the broadcast capability. The OSPF 351 protocol makes further use of multicast capabilities, if 352 they exist. Each pair of routers on a broadcast network is 353 assumed to be able to communicate directly. An ethernet is 354 an example of a broadcast network. 356 Non-broadcast networks 357 Networks supporting many (more than two) routers, but having 358 no broadcast capability. Neighboring routers are maintained 359 on these nets using OSPF's Hello Protocol. However, due to 360 the lack of broadcast capability, some configuration 361 information may be necessary to aid in the discovery of 362 neighbors. On non-broadcast networks, OSPF protocol packets 363 that are normally multicast need to be sent to each 364 neighboring router, in turn. An X.25 Public Data Network 365 (PDN) is an example of a non-broadcast network. 367 OSPF runs in one of two modes over non-broadcast networks. 368 The first mode, called non-broadcast multi-access or NBMA, 369 simulates the operation of OSPF on a broadcast network. The 370 second mode, called Point-to-MultiPoint, treats the non- 371 broadcast network as a collection of point-to-point links. 372 Non-broadcast networks are referred to as NBMA networks or 373 Point-to-MultiPoint networks, depending on OSPF's mode of 374 operation over the network. 376 Interface 377 The connection between a router and one of its attached 378 networks. An interface has state information associated 379 with it, which is obtained from the underlying lower level 380 protocols and the routing protocol itself. An interface to 381 a network has associated with it a single IP address and 382 mask (unless the network is an unnumbered point-to-point 383 network). An interface is sometimes also referred to as a 384 link. 386 Neighboring routers 387 Two routers that have interfaces to a common network. 388 Neighbor relationships are maintained by, and usually 389 dynamically discovered by, OSPF's Hello Protocol. 391 Adjacency 392 A relationship formed between selected neighboring routers 393 for the purpose of exchanging routing information. Not 394 every pair of neighboring routers become adjacent. 396 Link state advertisement 397 Unit of data describing the local state of a router or 398 network. For a router, this includes the state of the 399 router's interfaces and adjacencies. Each link state 400 advertisement is flooded throughout the routing domain. The 401 collected link state advertisements of all routers and 402 networks forms the protocol's link state database. 403 Throughout this memo, link state advertisement is 404 abbreviated as LSA. 406 Hello Protocol 407 The part of the OSPF protocol used to establish and maintain 408 neighbor relationships. On broadcast networks the Hello 409 Protocol can also dynamically discover neighboring routers. 411 Flooding 412 The part of the OSPF protocol that distributes and 413 synchronizes the link-state database between OSPF routers. 415 Designated Router 416 Each broadcast and NBMA network that has at least two 417 attached routers has a Designated Router. The Designated 418 Router generates an LSA for the network and has other 419 special responsibilities in the running of the protocol. 420 The Designated Router is elected by the Hello Protocol. 422 The Designated Router concept enables a reduction in the 423 number of adjacencies required on a broadcast or NBMA 424 network. This in turn reduces the amount of routing 425 protocol traffic and the size of the link-state database. 427 Lower-level protocols 428 The underlying network access protocols that provide 429 services to the Internet Protocol and in turn the OSPF 430 protocol. Examples of these are the X.25 packet and frame 431 levels for X.25 PDNs, and the ethernet data link layer for 432 ethernets. 434 1.3. Brief history of link-state routing technology 436 OSPF is a link state routing protocol. Such protocols are also 437 referred to in the literature as SPF-based or distributed- 438 database protocols. This section gives a brief description of 439 the developments in link-state technology that have influenced 440 the OSPF protocol. 442 The first link-state routing protocol was developed for use in 443 the ARPANET packet switching network. This protocol is 444 described in [Ref3]. It has formed the starting point for all 445 other link-state protocols. The homogeneous ARPANET 446 environment, i.e., single-vendor packet switches connected by 447 synchronous serial lines, simplified the design and 448 implementation of the original protocol. 450 Modifications to this protocol were proposed in [Ref4]. These 451 modifications dealt with increasing the fault tolerance of the 452 routing protocol through, among other things, adding a checksum 453 to the LSAs (thereby detecting database corruption). The paper 454 also included means for reducing the routing traffic overhead in 455 a link-state protocol. This was accomplished by introducing 456 mechanisms which enabled the interval between LSA originations 457 to be increased by an order of magnitude. 459 A link-state algorithm has also been proposed for use as an ISO 460 IS-IS routing protocol. This protocol is described in [Ref2]. 461 The protocol includes methods for data and routing traffic 462 reduction when operating over broadcast networks. This is 463 accomplished by election of a Designated Router for each 464 broadcast network, which then originates an LSA for the network. 466 The OSPF Working Group of the IETF has extended this work in 467 developing the OSPF protocol. The Designated Router concept has 468 been greatly enhanced to further reduce the amount of routing 469 traffic required. Multicast capabilities are utilized for 470 additional routing bandwidth reduction. An area routing scheme 471 has been developed enabling information 472 hiding/protection/reduction. Finally, the algorithms have been 473 tailored for efficient operation in TCP/IP internets. 475 1.4. Organization of this document 477 The first three sections of this specification give a general 478 overview of the protocol's capabilities and functions. Sections 479 4-16 explain the protocol's mechanisms in detail. Packet 480 formats, protocol constants and configuration items are 481 specified in the appendices. 483 Labels such as HelloInterval encountered in the text refer to 484 protocol constants. They may or may not be configurable. 485 Architectural constants are summarized in Appendix B. 486 Configurable constants are summarized in Appendix C. 488 The detailed specification of the protocol is presented in terms 489 of data structures. This is done in order to make the 490 explanation more precise. Implementations of the protocol are 491 required to support the functionality described, but need not 492 use the precise data structures that appear in this memo. 494 1.5. Acknowledgments 496 The author would like to thank Ran Atkinson, Fred Baker, Jeffrey 497 Burgan, Rob Coltun, Dino Farinacci, Vince Fuller, Phanindra 498 Jujjavarapu, Milo Medin, Tom Pusateri, Kannan Varadhan, Zhaohui 499 Zhang and the rest of the OSPF Working Group for the ideas and 500 support they have given to this project. 502 The OSPF Point-to-MultiPoint interface is based on work done by 503 Fred Baker. 505 The OSPF Cryptographic Authentication option was developed by 506 Fred Baker and Ran Atkinson. 508 2. The Link-state Database: organization and calculations 510 The following subsections describe the organization of OSPF's link- 511 state database, and the routing calculations that are performed on 512 the database in order to produce a router's routing table. 514 2.1. Representation of routers and networks 516 The Autonomous System's link-state database describes a directed 517 graph. The vertices of the graph consist of routers and 518 networks. A graph edge connects two routers when they are 519 attached via a physical point-to-point network. An edge 520 connecting a router to a network indicates that the router has 521 an interface on the network. Networks can be either transit or 522 stub networks. Transit networks are those capable of carrying 523 data traffic that is neither locally originated nor locally 524 destined. A transit network is represented by a graph vertex 525 having both incoming and outgoing edges. A stub network's vertex 526 has only incoming edges. 528 The neighborhood of each network node in the graph depends on 529 the network's type (point-to-point, broadcast, NBMA or Point- 530 to-MultiPoint) and the number of routers having an interface to 531 the network. Three cases are depicted in Figure 1a. Rectangles 532 indicate routers. Circles and oblongs indicate networks. 533 Router names are prefixed with the letters RT and network names 534 with the letter N. Router interface names are prefixed by the 535 letter I. Lines between routers indicate point-to-point 536 networks. The left side of the figure shows networks with their 537 connected routers, with the resulting graphs shown on the right. 539 **FROM** 541 * |RT1|RT2| 542 +---+Ia +---+ * ------------ 543 |RT1|------|RT2| T RT1| | X | 544 +---+ Ib+---+ O RT2| X | | 545 * Ia| | X | 546 * Ib| X | | 548 Physical point-to-point networks 550 **FROM** 551 +---+ * 552 |RT7| * |RT7| N3| 553 +---+ T ------------ 554 | O RT7| | | 555 +----------------------+ * N3| X | | 556 N3 * 558 Stub networks 560 **FROM** 561 +---+ +---+ 562 |RT3| |RT4| |RT3|RT4|RT5|RT6|N2 | 563 +---+ +---+ * ------------------------ 564 | N2 | * RT3| | | | | X | 565 +----------------------+ T RT4| | | | | X | 566 | | O RT5| | | | | X | 567 +---+ +---+ * RT6| | | | | X | 568 |RT5| |RT6| * N2| X | X | X | X | | 569 +---+ +---+ 571 Broadcast or NBMA networks 573 Figure 1a: Network map components 575 Networks and routers are represented by vertices. 576 An edge connects Vertex A to Vertex B iff the 577 intersection of Column A and Row B is marked with 578 an X. 580 The top of Figure 1a shows two routers connected by a point-to- 581 point link. In the resulting link-state database graph, the two 582 router vertices are directly connected by a pair of edges, one 583 in each direction. Interfaces to point-to-point networks need 584 not be assigned IP addresses. When interface addresses are 585 assigned, they are modelled as stub links, with each router 586 advertising a stub connection to the other router's interface 587 address. Optionally, an IP subnet can be assigned to the point- 588 to-point network. In this case, both routers advertise a stub 589 link to the IP subnet, instead of advertising each others' IP 590 interface addresses. 592 The middle of Figure 1a shows a network with only one attached 593 router (i.e., a stub network). In this case, the network appears 594 on the end of a stub connection in the link-state database's 595 graph. 597 When multiple routers are attached to a broadcast network, the 598 link-state database graph shows all routers bidirectionally 599 connected to the network vertex. This is pictured at the bottom 600 of Figure 1a. 602 Each network (stub or transit) in the graph has an IP address 603 and associated network mask. The mask indicates the number of 604 nodes on the network. Hosts attached directly to routers 605 (referred to as host routes) appear on the graph as stub 606 networks. The network mask for a host route is always 607 0xffffffff, which indicates the presence of a single node. 609 2.1.1. Representation of non-broadcast networks 611 As mentioned previously, OSPF can run over non-broadcast 612 networks in one of two modes: NBMA or Point-to-MultiPoint. 613 The choice of mode determines the way that the Hello 614 protocol and flooding work over the non-broadcast network, 615 and the way that the network is represented in the link- 616 state database. 618 In NBMA mode, OSPF emulates operation over a broadcast 619 network: a Designated Router is elected for the NBMA 620 network, and the Designated Router originates an LSA for the 621 network. The graph representation for broadcast networks and 622 NBMA networks is identical. This representation is pictured 623 in the middle of Figure 1a. 625 NBMA mode is the most efficient way to run OSPF over non- 626 broadcast networks, both in terms of link-state database 627 size and in terms of the amount of routing protocol traffic. 628 However, it has one significant restriction: it requires all 629 routers attached to the NBMA network to be able to 630 communicate directly. This restriction may be met on some 631 non-broadcast networks, such as an ATM subnet utilizing 632 SVCs. But it is often not met on other non-broadcast 633 networks, such as PVC-only Frame Relay networks. On non- 634 broadcast networks where not all routers can communicate 635 directly you can break the non-broadcast network into 636 logical subnets, with the routers on each subnet being able 637 to communicate directly, and then run each separate subnet 638 as an NBMA network (see [Ref15]). This however requires 639 quite a bit of administrative overhead, and is prone to 640 misconfiguration. It is probably better to run such a non- 641 broadcast network in Point-to-Multipoint mode. 643 In Point-to-MultiPoint mode, OSPF treats all router-to- 644 router connections over the non-broadcast network as if they 645 were point-to-point links. No Designated Router is elected 646 for the network, nor is there an LSA generated for the 647 network. In fact, a vertex for the Point-to-MultiPoint 648 network does not appear in the graph of the link-state 649 database. 651 Figure 1b illustrates the link-state database representation 652 of a Point-to-MultiPoint network. On the left side of the 653 figure, a Point-to-MultiPoint network is pictured. It is 654 assumed that all routers can communicate directly, except 655 for routers RT4 and RT5. I3 though I6 indicate the routers' 656 IP interface addresses on the Point-to-MultiPoint network. 657 In the graphical representation of the link-state database, 658 routers that can communicate directly over the Point-to- 659 MultiPoint network are joined by bidirectional edges, and 660 each router also has a stub connection to its own IP 661 interface address (which is in contrast to the 662 representation of real point-to-point links; see Figure 1a). 664 On some non-broadcast networks, use of Point-to-MultiPoint 665 mode and data-link protocols such as Inverse ARP (see 666 [Ref14]) will allow autodiscovery of OSPF neighbors even 667 though broadcast support is not available. 669 2.1.2. An example link-state database 671 Figure 2 shows a sample map of an Autonomous System. The 672 rectangle labelled H1 indicates a host, which has a SLIP 673 **FROM** 674 +---+ +---+ 675 |RT3| |RT4| |RT3|RT4|RT5|RT6| 676 +---+ +---+ * -------------------- 677 I3| N2 |I4 * RT3| | X | X | X | 678 +----------------------+ T RT4| X | | | X | 679 I5| |I6 O RT5| X | | | X | 680 +---+ +---+ * RT6| X | X | X | | 681 |RT5| |RT6| * I3| X | | | | 682 +---+ +---+ I4| | X | | | 683 I5| | | X | | 684 I6| | | | X | 686 Figure 1b: Network map components 687 Point-to-MultiPoint networks 689 All routers can communicate directly over N2, except 690 routers RT4 and RT5. I3 through I6 indicate IP 691 interface addresses 693 connection to Router RT12. Router RT12 is therefore 694 advertising a host route. Lines between routers indicate 695 physical point-to-point networks. The only point-to-point 696 network that has been assigned interface addresses is the 697 one joining Routers RT6 and RT10. Routers RT5 and RT7 have 698 BGP connections to other Autonomous Systems. A set of BGP- 699 learned routes have been displayed for both of these 700 routers. 702 A cost is associated with the output side of each router 703 interface. This cost is configurable by the system 704 administrator. The lower the cost, the more likely the 705 interface is to be used to forward data traffic. Costs are 706 also associated with the externally derived routing data 707 (e.g., the BGP-learned routes). 709 The directed graph resulting from the map in Figure 2 is 710 depicted in Figure 3. Arcs are labelled with the cost of 711 the corresponding router output interface. Arcs having no 712 labelled cost have a cost of 0. Note that arcs leading from 713 networks to routers always have cost 0; they are significant 714 nonetheless. Note also that the externally derived routing 715 data appears on the graph as stubs. 717 + 718 | 3+---+ N12 N14 719 N1|--|RT1|\ 1 \ N13 / 720 | +---+ \ 8\ |8/8 721 + \ ____ \|/ 722 / \ 1+---+8 8+---+6 723 * N3 *---|RT4|------|RT5|--------+ 724 \____/ +---+ +---+ | 725 + / | |7 | 726 | 3+---+ / | | | 727 N2|--|RT2|/1 |1 |6 | 728 | +---+ +---+8 6+---+ | 729 + |RT3|--------------|RT6| | 730 +---+ +---+ | 731 |2 Ia|7 | 732 | | | 733 +---------+ | | 734 N4 | | 735 | | 736 | | 737 N11 | | 738 +---------+ | | 739 | | | N12 740 |3 | |6 2/ 741 +---+ | +---+/ 742 |RT9| | |RT7|---N15 743 +---+ | +---+ 9 744 |1 + | |1 745 _|__ | Ib|5 __|_ 746 / \ 1+----+2 | 3+----+1 / \ 747 * N9 *------|RT11|----|---|RT10|---* N6 * 748 \____/ +----+ | +----+ \____/ 749 | | | 750 |1 + |1 751 +--+ 10+----+ N8 +---+ 752 |H1|-----|RT12| |RT8| 753 +--+SLIP +----+ +---+ 754 |2 |4 755 | | 756 +---------+ +--------+ 757 N10 N7 759 Figure 2: A sample Autonomous System 760 **FROM** 762 |RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| 763 |1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9| 764 ----- --------------------------------------------- 765 RT1| | | | | | | | | | | | |0 | | | | 766 RT2| | | | | | | | | | | | |0 | | | | 767 RT3| | | | | |6 | | | | | | |0 | | | | 768 RT4| | | | |8 | | | | | | | |0 | | | | 769 RT5| | | |8 | |6 |6 | | | | | | | | | | 770 RT6| | |8 | |7 | | | | |5 | | | | | | | 771 RT7| | | | |6 | | | | | | | | |0 | | | 772 * RT8| | | | | | | | | | | | | |0 | | | 773 * RT9| | | | | | | | | | | | | | | |0 | 774 T RT10| | | | | |7 | | | | | | | |0 |0 | | 775 O RT11| | | | | | | | | | | | | | |0 |0 | 776 * RT12| | | | | | | | | | | | | | | |0 | 777 * N1|3 | | | | | | | | | | | | | | | | 778 N2| |3 | | | | | | | | | | | | | | | 779 N3|1 |1 |1 |1 | | | | | | | | | | | | | 780 N4| | |2 | | | | | | | | | | | | | | 781 N6| | | | | | |1 |1 | |1 | | | | | | | 782 N7| | | | | | | |4 | | | | | | | | | 783 N8| | | | | | | | | |3 |2 | | | | | | 784 N9| | | | | | | | |1 | |1 |1 | | | | | 785 N10| | | | | | | | | | | |2 | | | | | 786 N11| | | | | | | | |3 | | | | | | | | 787 N12| | | | |8 | |2 | | | | | | | | | | 788 N13| | | | |8 | | | | | | | | | | | | 789 N14| | | | |8 | | | | | | | | | | | | 790 N15| | | | | | |9 | | | | | | | | | | 791 H1| | | | | | | | | | | |10| | | | | 793 Figure 3: The resulting directed graph 795 Networks and routers are represented by vertices. 796 An edge of cost X connects Vertex A to Vertex B iff 797 the intersection of Column A and Row B is marked 798 with an X. 800 The link-state database is pieced together from LSAs 801 generated by the routers. In the associated graphical 802 representation, the neighborhood of each router or transit 803 network is represented in a single, separate LSA. Figure 4 804 shows these LSAs graphically. Router RT12 has an interface 805 to two broadcast networks and a SLIP line to a host. 806 Network N6 is a broadcast network with three attached 807 routers. The cost of all links from Network N6 to its 808 attached routers is 0. Note that the LSA for Network N6 is 809 actually generated by one of the network's attached routers: 810 the router that has been elected Designated Router for the 811 network. 813 2.2. The shortest-path tree 815 When no OSPF areas are configured, each router in the Autonomous 816 System has an identical link-state database, leading to an 817 identical graphical representation. A router generates its 818 routing table from this graph by calculating a tree of shortest 819 paths with the router itself as root. Obviously, the shortest- 820 path tree depends on the router doing the calculation. The 821 shortest-path tree for Router RT6 in our example is depicted in 822 Figure 5. 824 The tree gives the entire path to any destination network or 825 host. However, only the next hop to the destination is used in 826 the forwarding process. Note also that the best route to any 827 router has also been calculated. For the processing of external 828 data, we note the next hop and distance to any router 829 advertising external routes. The resulting routing table for 830 Router RT6 is pictured in Table 2. Note that there is a 831 separate route for each end of a numbered point-to-point network 832 (in this case, the serial line between Routers RT6 and RT10). 834 **FROM** **FROM** 836 |RT12|N9|N10|H1| |RT9|RT11|RT12|N9| 837 * -------------------- * ---------------------- 838 * RT12| | | | | * RT9| | | |0 | 839 T N9|1 | | | | T RT11| | | |0 | 840 O N10|2 | | | | O RT12| | | |0 | 841 * H1|10 | | | | * N9| | | | | 842 * * 843 RT12's router-LSA N9's network-LSA 845 Figure 4: Individual link state components 847 Networks and routers are represented by vertices. 848 An edge of cost X connects Vertex A to Vertex B iff 849 the intersection of Column A and Row B is marked 850 with an X. 852 RT6(origin) 853 RT5 o------------o-----------o Ib 854 /|\ 6 |\ 7 855 8/8|8\ | \ 856 / | \ | \ 857 o | o | \7 858 N12 o N14 | \ 859 N13 2 | \ 860 N4 o-----o RT3 \ 861 / \ 5 862 1/ RT10 o-------o Ia 863 / |\ 864 RT4 o-----o N3 3| \1 865 /| | \ N6 RT7 866 / | N8 o o---------o 867 / | | | /| 868 RT2 o o RT1 | | 2/ |9 869 / | | |RT8 / | 870 /3 |3 RT11 o o o o 871 / | | | N12 N15 872 N2 o o N1 1| |4 873 | | 874 N9 o o N7 875 /| 876 / | 877 N11 RT9 / |RT12 878 o--------o-------o o--------o H1 879 3 | 10 880 |2 881 | 882 o N10 884 Figure 5: The SPF tree for Router RT6 886 Edges that are not marked with a cost have a cost of 887 of zero (these are network-to-router links). Routes 888 to networks N12-N15 are external information that is 889 considered in Section 2.3 890 Destination Next Hop Distance 891 __________________________________ 892 N1 RT3 10 893 N2 RT3 10 894 N3 RT3 7 895 N4 RT3 8 896 Ib * 7 897 Ia RT10 12 898 N6 RT10 8 899 N7 RT10 12 900 N8 RT10 10 901 N9 RT10 11 902 N10 RT10 13 903 N11 RT10 14 904 H1 RT10 21 905 __________________________________ 906 RT5 RT5 6 907 RT7 RT10 8 909 Table 2: The portion of Router RT6's routing table listing local 910 destinations. 912 Routes to networks belonging to other AS'es (such as N12) appear 913 as dashed lines on the shortest path tree in Figure 5. Use of 914 this externally derived routing information is considered in the 915 next section. 917 2.3. Use of external routing information 919 After the tree is created the external routing information is 920 examined. This external routing information may originate from 921 another routing protocol such as BGP, or be statically 922 configured (static routes). Default routes can also be included 923 as part of the Autonomous System's external routing information. 925 External routing information is flooded unaltered throughout the 926 AS. In our example, all the routers in the Autonomous System 927 know that Router RT7 has two external routes, with metrics 2 and 928 9. 930 OSPF supports two types of external metrics. Type 1 external 931 metrics are expressed in the same units as OSPF interface cost 932 (i.e., in terms of the link state metric). Type 2 external 933 metrics are an order of magnitude larger; any Type 2 metric is 934 considered greater than the cost of any path internal to the AS. 935 Use of Type 2 external metrics assumes that routing between 936 AS'es is the major cost of routing a packet, and eliminates the 937 need for conversion of external costs to internal link state 938 metrics. 940 As an example of Type 1 external metric processing, suppose that 941 the Routers RT7 and RT5 in Figure 2 are advertising Type 1 942 external metrics. For each advertised external route, the total 943 cost from Router RT6 is calculated as the sum of the external 944 route's advertised cost and the distance from Router RT6 to the 945 advertising router. When two routers are advertising the same 946 external destination, RT6 picks the advertising router providing 947 the minimum total cost. RT6 then sets the next hop to the 948 external destination equal to the next hop that would be used 949 when routing packets to the chosen advertising router. 951 In Figure 2, both Router RT5 and RT7 are advertising an external 952 route to destination Network N12. Router RT7 is preferred since 953 it is advertising N12 at a distance of 10 (8+2) to Router RT6, 954 which is better than Router RT5's 14 (6+8). Table 3 shows the 955 entries that are added to the routing table when external routes 956 are examined: 958 Destination Next Hop Distance 959 __________________________________ 960 N12 RT10 10 961 N13 RT5 14 962 N14 RT5 14 963 N15 RT10 17 965 Table 3: The portion of Router RT6's routing table 966 listing external destinations. 968 Processing of Type 2 external metrics is simpler. The AS 969 boundary router advertising the smallest external metric is 970 chosen, regardless of the internal distance to the AS boundary 971 router. Suppose in our example both Router RT5 and Router RT7 972 were advertising Type 2 external routes. Then all traffic 973 destined for Network N12 would be forwarded to Router RT7, since 974 2 < 8. When several equal-cost Type 2 routes exist, the 975 internal distance to the advertising routers is used to break 976 the tie. 978 Both Type 1 and Type 2 external metrics can be present in the AS 979 at the same time. In that event, Type 1 external metrics always 980 take precedence. 982 This section has assumed that packets destined for external 983 destinations are always routed through the advertising AS 984 boundary router. This is not always desirable. For example, 985 suppose in Figure 2 there is an additional router attached to 986 Network N6, called Router RTX. Suppose further that RTX does 987 not participate in OSPF routing, but does exchange BGP 988 information with the AS boundary router RT7. Then, Router RT7 989 would end up advertising OSPF external routes for all 990 destinations that should be routed to RTX. An extra hop will 991 sometimes be introduced if packets for these destinations need 992 always be routed first to Router RT7 (the advertising router). 994 To deal with this situation, the OSPF protocol allows an AS 995 boundary router to specify a "forwarding address" in its AS- 996 external-LSAs. In the above example, Router RT7 would specify 997 RTX's IP address as the "forwarding address" for all those 998 destinations whose packets should be routed directly to RTX. 1000 The "forwarding address" has one other application. It enables 1001 routers in the Autonomous System's interior to function as 1002 "route servers". For example, in Figure 2 the router RT6 could 1003 become a route server, gaining external routing information 1004 through a combination of static configuration and external 1005 routing protocols. RT6 would then start advertising itself as 1006 an AS boundary router, and would originate a collection of OSPF 1007 AS-external-LSAs. In each AS-external-LSA, Router RT6 would 1008 specify the correct Autonomous System exit point to use for the 1009 destination through appropriate setting of the LSA's "forwarding 1010 address" field. 1012 2.4. Equal-cost multipath 1014 The above discussion has been simplified by considering only a 1015 single route to any destination. In reality, if multiple 1016 equal-cost routes to a destination exist, they are all 1017 discovered and used. This requires no conceptual changes to the 1018 algorithm, and its discussion is postponed until we consider the 1019 tree-building process in more detail. 1021 With equal cost multipath, a router potentially has several 1022 available next hops towards any given destination. 1024 2.5. TOS-based routing 1026 OSPF can calculate a separate set of routes for each IP Type of 1027 Service. This means that, for any destination, there can 1028 potentially be multiple routing table entries, one for each IP 1029 TOS. The IP TOS values are represented in OSPF exactly as they 1030 appear in the IP packet header. 1032 Up to this point, all examples shown have assumed that routes do 1033 not vary on TOS. In order to differentiate routes based on TOS, 1034 separate interface costs can be configured for each TOS. For 1035 example, in Figure 2 there could be multiple costs (one for each 1036 TOS) listed for each interface. A cost for TOS 0 must always be 1037 specified. 1039 When interface costs vary based on TOS, a separate shortest path 1040 tree is calculated for each TOS (see Section 2.2). In addition, 1041 external costs can vary based on TOS. For example, in Figure 2 1042 Router RT7 could advertise a separate type 1 external metric for 1043 each TOS. Then, when calculating the TOS X distance to Network 1044 N15 the cost of the shortest TOS X path to RT7 would be added to 1045 the TOS X cost advertised by RT7 for Network N15 (see Section 1046 2.3). 1048 All OSPF implementations must be capable of calculating routes 1049 based on TOS. However, OSPF routers can be configured to route 1050 all packets on the TOS 0 path (see Appendix C), eliminating the 1051 need to calculate non-zero TOS paths. This can be used to 1052 conserve routing table space and processing resources in the 1053 router. These TOS-0-only routers can be mixed with routers that 1054 do route based on TOS. TOS-0-only routers will be avoided as 1055 much as possible when forwarding traffic requesting a non-zero 1056 TOS. 1058 It may be the case that no path exists for some non-zero TOS, 1059 even if the router is calculating non-zero TOS paths. In that 1060 case, packets requesting that non-zero TOS are routed along the 1061 TOS 0 path (see Section 11.1). 1063 3. Splitting the AS into Areas 1065 OSPF allows collections of contiguous networks and hosts to be 1066 grouped together. Such a group, together with the routers having 1067 interfaces to any one of the included networks, is called an area. 1068 Each area runs a separate copy of the basic link-state routing 1069 algorithm. This means that each area has its own link-state 1070 database and corresponding graph, as explained in the previous 1071 section. 1073 The topology of an area is invisible from the outside of the area. 1074 Conversely, routers internal to a given area know nothing of the 1075 detailed topology external to the area. This isolation of knowledge 1076 enables the protocol to effect a marked reduction in routing traffic 1077 as compared to treating the entire Autonomous System as a single 1078 link-state domain. 1080 With the introduction of areas, it is no longer true that all 1081 routers in the AS have an identical link-state database. A router 1082 actually has a separate link-state database for each area it is 1083 connected to. (Routers connected to multiple areas are called area 1084 border routers). Two routers belonging to the same area have, for 1085 that area, identical area link-state databases. 1087 Routing in the Autonomous System takes place on two levels, 1088 depending on whether the source and destination of a packet reside 1089 in the same area (intra-area routing is used) or different areas 1090 (inter-area routing is used). In intra-area routing, the packet is 1091 routed solely on information obtained within the area; no routing 1092 information obtained from outside the area can be used. This 1093 protects intra-area routing from the injection of bad routing 1094 information. We discuss inter-area routing in Section 3.2. 1096 3.1. The backbone of the Autonomous System 1098 The OSPF backbone is the special OSPF Area 0 (often written as 1099 Area 0.0.0.0, since OSPF Area ID's are typically formatted as IP 1100 addresses). The OSPF backbone always contains all area border 1101 routers. The backbone is responsible for distributing routing 1102 information between non-backbone areas. The backbone must be 1103 contiguous. However, it need not be physically contiguous; 1104 backbone connectivity can be established/maintained through the 1105 configuration of virtual links. 1107 Virtual links can be configured between any two backbone routers 1108 that have an interface to a common non-backbone area. Virtual 1109 links belong to the backbone. The protocol treats two routers 1110 joined by a virtual link as if they were connected by an 1111 unnumbered point-to-point backbone network. On the graph of the 1112 backbone, two such routers are joined by arcs whose costs are 1113 the intra-area distances between the two routers. The routing 1114 protocol traffic that flows along the virtual link uses intra- 1115 area routing only. 1117 3.2. Inter-area routing 1119 When routing a packet between two non-backbone areas the 1120 backbone is used. The path that the packet will travel can be 1121 broken up into three contiguous pieces: an intra-area path from 1122 the source to an area border router, a backbone path between the 1123 source and destination areas, and then another intra-area path 1124 to the destination. The algorithm finds the set of such paths 1125 that have the smallest cost. 1127 Looking at this another way, inter-area routing can be pictured 1128 as forcing a star configuration on the Autonomous System, with 1129 the backbone as hub and each of the non-backbone areas as 1130 spokes. 1132 The topology of the backbone dictates the backbone paths used 1133 between areas. The topology of the backbone can be enhanced by 1134 adding virtual links. This gives the system administrator some 1135 control over the routes taken by inter-area traffic. 1137 The correct area border router to use as the packet exits the 1138 source area is chosen in exactly the same way routers 1139 advertising external routes are chosen. Each area border router 1140 in an area summarizes for the area its cost to all networks 1141 external to the area. After the SPF tree is calculated for the 1142 area, routes to all inter-area destinations are calculated by 1143 examining the summaries of the area border routers. 1145 3.3. Classification of routers 1147 Before the introduction of areas, the only OSPF routers having a 1148 specialized function were those advertising external routing 1149 information, such as Router RT5 in Figure 2. When the AS is 1150 split into OSPF areas, the routers are further divided according 1151 to function into the following four overlapping categories: 1153 Internal routers 1154 A router with all directly connected networks belonging to 1155 the same area. These routers run a single copy of the basic 1156 routing algorithm. 1158 Area border routers 1159 A router that attaches to multiple areas. Area border 1160 routers run multiple copies of the basic algorithm, one copy 1161 for each attached area. Area border routers condense the 1162 topological information of their attached areas for 1163 distribution to the backbone. The backbone in turn 1164 distributes the information to the other areas. 1166 Backbone routers 1167 A router that has an interface to the backbone area. This 1168 includes all routers that interface to more than one area 1169 (i.e., area border routers). However, backbone routers do 1170 not have to be area border routers. Routers with all 1171 interfaces connecting to the backbone area are supported. 1173 AS boundary routers 1174 A router that exchanges routing information with routers 1175 belonging to other Autonomous Systems. Such a router 1176 advertises AS external routing information throughout the 1177 Autonomous System. The paths to each AS boundary router are 1178 known by every router in the AS. This classification is 1179 completely independent of the previous classifications: AS 1180 boundary routers may be internal or area border routers, and 1181 may or may not participate in the backbone. 1183 3.4. A sample area configuration 1185 Figure 6 shows a sample area configuration. The first area 1186 consists of networks N1-N4, along with their attached routers 1187 RT1-RT4. The second area consists of networks N6-N8, along with 1188 their attached routers RT7, RT8, RT10 and RT11. The third area 1189 consists of networks N9-N11 and Host H1, along with their 1190 attached routers RT9, RT11 and RT12. The third area has been 1191 configured so that networks N9-N11 and Host H1 will all be 1192 grouped into a single route, when advertised external to the 1193 area (see Section 3.5 for more details). 1195 In Figure 6, Routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are 1196 internal routers. Routers RT3, RT4, RT7, RT10 and RT11 are area 1197 border routers. Finally, as before, Routers RT5 and RT7 are AS 1198 boundary routers. 1200 Figure 7 shows the resulting link-state database for the Area 1. 1201 The figure completely describes that area's intra-area routing. 1202 It also shows the complete view of the internet for the two 1203 internal routers RT1 and RT2. It is the job of the area border 1204 routers, RT3 and RT4, to advertise into Area 1 the distances to 1205 all destinations external to the area. These are indicated in 1206 Figure 7 by the dashed stub routes. Also, RT3 and RT4 must 1207 advertise into Area 1 the location of the AS boundary routers 1208 RT5 and RT7. Finally, AS-external-LSAs from RT5 and RT7 are 1209 flooded throughout the entire AS, and in particular throughout 1210 ........................... 1211 . + . 1212 . | 3+---+ . N12 N14 1213 . N1|--|RT1|\ 1 . \ N13 / 1214 . | +---+ \ . 8\ |8/8 1215 . + \ ____ . \|/ 1216 . / \ 1+---+8 8+---+6 1217 . * N3 *---|RT4|------|RT5|--------+ 1218 . \____/ +---+ +---+ | 1219 . + / \ . |7 | 1220 . | 3+---+ / \ . | | 1221 . N2|--|RT2|/1 1\ . |6 | 1222 . | +---+ +---+8 6+---+ | 1223 . + |RT3|------|RT6| | 1224 . +---+ +---+ | 1225 . 2/ . Ia|7 | 1226 . / . | | 1227 . +---------+ . | | 1228 .Area 1 N4 . | | 1229 ........................... | | 1230 .......................... | | 1231 . N11 . | | 1232 . +---------+ . | | 1233 . | . | | N12 1234 . |3 . Ib|5 |6 2/ 1235 . +---+ . +----+ +---+/ 1236 . |RT9| . .........|RT10|.....|RT7|---N15. 1237 . +---+ . . +----+ +---+ 9 . 1238 . |1 . . + /3 1\ |1 . 1239 . _|__ . . | / \ __|_ . 1240 . / \ 1+----+2 |/ \ / \ . 1241 . * N9 *------|RT11|----| * N6 * . 1242 . \____/ +----+ | \____/ . 1243 . | . . | | . 1244 . |1 . . + |1 . 1245 . +--+ 10+----+ . . N8 +---+ . 1246 . |H1|-----|RT12| . . |RT8| . 1247 . +--+SLIP +----+ . . +---+ . 1248 . |2 . . |4 . 1249 . | . . | . 1250 . +---------+ . . +--------+ . 1251 . N10 . . N7 . 1252 . . .Area 2 . 1253 .Area 3 . ................................ 1254 .......................... 1256 Figure 6: A sample OSPF area configuration 1257 Area 1. These LSAs are included in Area 1's database, and yield 1258 routes to Networks N12-N15. 1260 Routers RT3 and RT4 must also summarize Area 1's topology for 1261 distribution to the backbone. Their backbone LSAs are shown in 1262 Table 4. These summaries show which networks are contained in 1263 Area 1 (i.e., Networks N1-N4), and the distance to these 1264 networks from the routers RT3 and RT4 respectively. 1266 The link-state database for the backbone is shown in Figure 8. 1267 The set of routers pictured are the backbone routers. Router 1268 RT11 is a backbone router because it belongs to two areas. In 1269 order to make the backbone connected, a virtual link has been 1270 configured between Routers R10 and R11. 1272 The area border routers RT3, RT4, RT7, RT10 and RT11 condense 1273 the routing information of their attached non-backbone areas for 1274 distribution via the backbone; these are the dashed stubs that 1275 appear in Figure 8. Remember that the third area has been 1276 configured to condense Networks N9-N11 and Host H1 into a single 1277 route. This yields a single dashed line for networks N9-N11 and 1278 Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary 1279 routers; their externally derived information also appears on 1280 the graph in Figure 8 as stubs. 1282 The backbone enables the exchange of summary information between 1283 area border routers. Every area border router hears the area 1284 summaries from all other area border routers. It then forms a 1285 picture of the distance to all networks outside of its area by 1286 examining the collected LSAs, and adding in the backbone 1287 distance to each advertising router. 1289 Again using Routers RT3 and RT4 as an example, the procedure 1290 goes as follows: They first calculate the SPF tree for the 1292 Network RT3 adv. RT4 adv. 1293 _____________________________ 1294 N1 4 4 1295 N2 4 4 1296 N3 1 1 1297 N4 2 3 1299 Table 4: Networks advertised to the backbone 1300 by Routers RT3 and RT4. 1302 **FROM** 1304 |RT|RT|RT|RT|RT|RT| 1305 |1 |2 |3 |4 |5 |7 |N3| 1306 ----- ------------------- 1307 RT1| | | | | | |0 | 1308 RT2| | | | | | |0 | 1309 RT3| | | | | | |0 | 1310 * RT4| | | | | | |0 | 1311 * RT5| | |14|8 | | | | 1312 T RT7| | |20|14| | | | 1313 O N1|3 | | | | | | | 1314 * N2| |3 | | | | | | 1315 * N3|1 |1 |1 |1 | | | | 1316 N4| | |2 | | | | | 1317 Ia,Ib| | |20|27| | | | 1318 N6| | |16|15| | | | 1319 N7| | |20|19| | | | 1320 N8| | |18|18| | | | 1321 N9-N11,H1| | |29|36| | | | 1322 N12| | | | |8 |2 | | 1323 N13| | | | |8 | | | 1324 N14| | | | |8 | | | 1325 N15| | | | | |9 | | 1327 Figure 7: Area 1's Database. 1329 Networks and routers are represented by vertices. 1330 An edge of cost X connects Vertex A to Vertex B iff 1331 the intersection of Column A and Row B is marked 1332 with an X. 1334 **FROM** 1336 |RT|RT|RT|RT|RT|RT|RT 1337 |3 |4 |5 |6 |7 |10|11| 1338 ------------------------ 1339 RT3| | | |6 | | | | 1340 RT4| | |8 | | | | | 1341 RT5| |8 | |6 |6 | | | 1342 RT6|8 | |7 | | |5 | | 1343 RT7| | |6 | | | | | 1344 * RT10| | | |7 | | |2 | 1345 * RT11| | | | | |3 | | 1346 T N1|4 |4 | | | | | | 1347 O N2|4 |4 | | | | | | 1348 * N3|1 |1 | | | | | | 1349 * N4|2 |3 | | | | | | 1350 Ia| | | | | |5 | | 1351 Ib| | | |7 | | | | 1352 N6| | | | |1 |1 |3 | 1353 N7| | | | |5 |5 |7 | 1354 N8| | | | |4 |3 |2 | 1355 N9-N11,H1| | | | | | |11| 1356 N12| | |8 | |2 | | | 1357 N13| | |8 | | | | | 1358 N14| | |8 | | | | | 1359 N15| | | | |9 | | | 1361 Figure 8: The backbone's database. 1363 Networks and routers are represented by vertices. 1364 An edge of cost X connects Vertex A to Vertex B iff 1365 the intersection of Column A and Row B is marked 1366 with an X. 1368 backbone. This gives the distances to all other area border 1369 routers. Also noted are the distances to networks (Ia and Ib) 1370 and AS boundary routers (RT5 and RT7) that belong to the 1371 backbone. This calculation is shown in Table 5. 1373 Next, by looking at the area summaries from these area border 1374 routers, RT3 and RT4 can determine the distance to all networks 1375 outside their area. These distances are then advertised 1376 internally to the area by RT3 and RT4. The advertisements that 1377 Router RT3 and RT4 will make into Area 1 are shown in Table 6. 1378 Note that Table 6 assumes that an area range has been configured 1379 for the backbone which groups Ia and Ib into a single LSA. 1381 dist from dist from 1382 RT3 RT4 1383 __________________________________ 1384 to RT3 * 21 1385 to RT4 22 * 1386 to RT7 20 14 1387 to RT10 15 22 1388 to RT11 18 25 1389 __________________________________ 1390 to Ia 20 27 1391 to Ib 15 22 1392 __________________________________ 1393 to RT5 14 8 1394 to RT7 20 14 1396 Table 5: Backbone distances calculated 1397 by Routers RT3 and RT4. 1399 The information imported into Area 1 by Routers RT3 and RT4 1400 enables an internal router, such as RT1, to choose an area 1401 border router intelligently. Router RT1 would use RT4 for 1402 traffic to Network N6, RT3 for traffic to Network N10, and would 1403 load share between the two for traffic to Network N8. 1405 Router RT1 can also determine in this manner the shortest path 1406 to the AS boundary routers RT5 and RT7. Then, by looking at RT5 1407 and RT7's AS-external-LSAs, Router RT1 can decide between RT5 or 1408 RT7 when sending to a destination in another Autonomous System 1409 (one of the networks N12-N15). 1411 Destination RT3 adv. RT4 adv. 1412 _________________________________ 1413 Ia,Ib 20 27 1414 N6 16 15 1415 N7 20 19 1416 N8 18 18 1417 N9-N11,H1 29 36 1418 _________________________________ 1419 RT5 14 8 1420 RT7 20 14 1422 Table 6: Destinations advertised into Area 1 1423 by Routers RT3 and RT4. 1425 Note that a failure of the line between Routers RT6 and RT10 1426 will cause the backbone to become disconnected. Configuring a 1427 virtual link between Routers RT7 and RT10 will give the backbone 1428 more connectivity and more resistance to such failures. 1430 3.5. IP subnetting support 1432 OSPF attaches an IP address mask to each advertised route. The 1433 mask indicates the range of addresses being described by the 1434 particular route. For example, a summary-LSA for the 1435 destination 128.185.0.0 with a mask of 0xffff0000 actually is 1436 describing a single route to the collection of destinations 1437 128.185.0.0 - 128.185.255.255. Similarly, host routes are 1438 always advertised with a mask of 0xffffffff, indicating the 1439 presence of only a single destination. 1441 Including the mask with each advertised destination enables the 1442 implementation of what is commonly referred to as variable- 1443 length subnetting. This means that a single IP class A, B, or C 1444 network number can be broken up into many subnets of various 1445 sizes. For example, the network 128.185.0.0 could be broken up 1446 into 62 variable-sized subnets: 15 subnets of size 4K, 15 1447 subnets of size 256, and 32 subnets of size 8. Table 7 shows 1448 some of the resulting network addresses together with their 1449 masks. 1451 Network address IP address mask Subnet size 1452 _______________________________________________ 1453 128.185.16.0 0xfffff000 4K 1454 128.185.1.0 0xffffff00 256 1455 128.185.0.8 0xfffffff8 8 1457 Table 7: Some sample subnet sizes. 1459 There are many possible ways of dividing up a class A, B, and C 1460 network into variable sized subnets. The precise procedure for 1461 doing so is beyond the scope of this specification. This 1462 specification however establishes the following guideline: When 1463 an IP packet is forwarded, it is always forwarded to the network 1464 that is the best match for the packet's destination. Here best 1465 match is synonymous with the longest or most specific match. 1466 For example, the default route with destination of 0.0.0.0 and 1467 mask 0x00000000 is always a match for every IP destination. Yet 1468 it is always less specific than any other match. Subnet masks 1469 must be assigned so that the best match for any IP destination 1470 is unambiguous. 1472 Attaching an address mask to each route also enables the support 1473 of IP supernetting. For example, a single physical network 1474 segment could be assigned the [address,mask] pair 1475 [192.9.4.0,0xfffffc00]. The segment would then be single IP 1476 network, containing addresses from the four consecutive class C 1477 network numbers 192.9.4.0 through 192.9.7.0. Such addressing is 1478 now becoming commonplace with the advent of CIDR (see [Ref10]). 1480 In order to get better aggregation at area boundaries, area 1481 address ranges can be employed (see Section C.2 for more 1482 details). Each address range is defined as an [address,mask] 1483 pair. Many separate networks may then be contained in a single 1484 address range, just as a subnetted network is composed of many 1485 separate subnets. Area border routers then summarize the area 1486 contents (for distribution to the backbone) by advertising a 1487 single route for each address range. The cost of the route is 1488 the maximum cost to any of the networks falling in the specified 1489 range. 1491 For example, an IP subnetted network might be configured as a 1492 single OSPF area. In that case, a single address range could be 1493 configured: a class A, B, or C network number along with its 1494 natural IP mask. Inside the area, any number of variable sized 1495 subnets could be defined. However, external to the area a 1496 single route for the entire subnetted network would be 1497 distributed, hiding even the fact that the network is subnetted 1498 at all. The cost of this route is the maximum of the set of 1499 costs to the component subnets. 1501 3.6. Supporting stub areas 1503 In some Autonomous Systems, the majority of the link-state 1504 database may consist of AS-external-LSAs. An OSPF AS-external- 1505 LSA is usually flooded throughout the entire AS. However, OSPF 1506 allows certain areas to be configured as "stub areas". AS- 1507 external-LSAs are not flooded into/throughout stub areas; 1508 routing to AS external destinations in these areas is based on a 1509 (per-area) default only. This reduces the link-state database 1510 size, and therefore the memory requirements, for a stub area's 1511 internal routers. 1513 In order to take advantage of the OSPF stub area support, 1514 default routing must be used in the stub area. This is 1515 accomplished as follows. One or more of the stub area's area 1516 border routers must advertise a default route into the stub area 1517 via summary-LSAs. These summary defaults are flooded throughout 1518 the stub area, but no further. (For this reason these defaults 1519 pertain only to the particular stub area). These summary 1520 default routes will be used for any destination that is not 1521 explicitly reachable by an intra-area or inter-area path (i.e., 1522 AS external destinations). 1524 An area can be configured as a stub when there is a single exit 1525 point from the area, or when the choice of exit point need not 1526 be made on a per-external-destination basis. For example, Area 1527 3 in Figure 6 could be configured as a stub area, because all 1528 external traffic must travel though its single area border 1529 router RT11. If Area 3 were configured as a stub, Router RT11 1530 would advertise a default route for distribution inside Area 3 1531 (in a summary-LSA), instead of flooding the AS-external-LSAs for 1532 Networks N12-N15 into/throughout the area. 1534 The OSPF protocol ensures that all routers belonging to an area 1535 agree on whether the area has been configured as a stub. This 1536 guarantees that no confusion will arise in the flooding of AS- 1537 external-LSAs. 1539 There are a couple of restrictions on the use of stub areas. 1540 Virtual links cannot be configured through stub areas. In 1541 addition, AS boundary routers cannot be placed internal to stub 1542 areas. 1544 3.7. Partitions of areas 1546 OSPF does not actively attempt to repair area partitions. When 1547 an area becomes partitioned, each component simply becomes a 1548 separate area. The backbone then performs routing between the 1549 new areas. Some destinations reachable via intra-area routing 1550 before the partition will now require inter-area routing. 1552 However, in order to maintain full routing after the partition, 1553 an address range must not be split across multiple components of 1554 the area partition. Also, the backbone itself must not 1555 partition. If it does, parts of the Autonomous System will 1556 become unreachable. Backbone partitions can be repaired by 1557 configuring virtual links (see Section 15). 1559 Another way to think about area partitions is to look at the 1560 Autonomous System graph that was introduced in Section 2. Area 1561 IDs can be viewed as colors for the graph's edges.[1] Each edge 1562 of the graph connects to a network, or is itself a point-to- 1563 point network. In either case, the edge is colored with the 1564 network's Area ID. 1566 A group of edges, all having the same color, and interconnected 1567 by vertices, represents an area. If the topology of the 1568 Autonomous System is intact, the graph will have several regions 1569 of color, each color being a distinct Area ID. 1571 When the AS topology changes, one of the areas may become 1572 partitioned. The graph of the AS will then have multiple 1573 regions of the same color (Area ID). The routing in the 1574 Autonomous System will continue to function as long as these 1575 regions of same color are connected by the single backbone 1576 region. 1578 4. Functional Summary 1580 A separate copy of OSPF's basic routing algorithm runs in each area. 1581 Routers having interfaces to multiple areas run multiple copies of 1582 the algorithm. A brief summary of the routing algorithm follows. 1584 When a router starts, it first initializes the routing protocol data 1585 structures. The router then waits for indications from the lower- 1586 level protocols that its interfaces are functional. 1588 A router then uses the OSPF's Hello Protocol to acquire neighbors. 1589 The router sends Hello packets to its neighbors, and in turn 1590 receives their Hello packets. On broadcast and point-to-point 1591 networks, the router dynamically detects its neighboring routers by 1592 sending its Hello packets to the multicast address AllSPFRouters. 1593 On non-broadcast networks, some configuration information may be 1594 necessary in order to discover neighbors. On broadcast and NBMA 1595 networks the Hello Protocol also elects a Designated router for the 1596 network. 1598 The router will attempt to form adjacencies with some of its newly 1599 acquired neighbors. Link-state databases are synchronized between 1600 pairs of adjacent routers. On broadcast and NBMA networks, the 1601 Designated Router determines which routers should become adjacent. 1603 Adjacencies control the distribution of routing information. 1604 Routing updates are sent and received only on adjacencies. 1606 A router periodically advertises its state, which is also called 1607 link state. Link state is also advertised when a router's state 1608 changes. A router's adjacencies are reflected in the contents of 1609 its LSAs. This relationship between adjacencies and link state 1610 allows the protocol to detect dead routers in a timely fashion. 1612 LSAs are flooded throughout the area. The flooding algorithm is 1613 reliable, ensuring that all routers in an area have exactly the same 1614 link-state database. This database consists of the collection of 1615 LSAs originated by each router belonging to the area. From this 1616 database each router calculates a shortest-path tree, with itself as 1617 root. This shortest-path tree in turn yields a routing table for 1618 the protocol. 1620 4.1. Inter-area routing 1622 The previous section described the operation of the protocol 1623 within a single area. For intra-area routing, no other routing 1624 information is pertinent. In order to be able to route to 1625 destinations outside of the area, the area border routers inject 1626 additional routing information into the area. This additional 1627 information is a distillation of the rest of the Autonomous 1628 System's topology. 1630 This distillation is accomplished as follows: Each area border 1631 router is by definition connected to the backbone. Each area 1632 border router summarizes the topology of its attached non- 1633 backbone areas for transmission on the backbone, and hence to 1634 all other area border routers. An area border router then has 1635 complete topological information concerning the backbone, and 1636 the area summaries from each of the other area border routers. 1637 From this information, the router calculates paths to all 1638 inter-area destinations. The router then advertises these paths 1639 into its attached areas. This enables the area's internal 1640 routers to pick the best exit router when forwarding traffic 1641 inter-area destinations. 1643 4.2. AS external routes 1645 Routers that have information regarding other Autonomous Systems 1646 can flood this information throughout the AS. This external 1647 routing information is distributed verbatim to every 1648 participating router. There is one exception: external routing 1649 information is not flooded into "stub" areas (see Section 3.6). 1651 To utilize external routing information, the path to all routers 1652 advertising external information must be known throughout the AS 1653 (excepting the stub areas). For that reason, the locations of 1654 these AS boundary routers are summarized by the (non-stub) area 1655 border routers. 1657 4.3. Routing protocol packets 1659 The OSPF protocol runs directly over IP, using IP protocol 89. 1660 OSPF does not provide any explicit fragmentation/reassembly 1661 support. When fragmentation is necessary, IP 1662 fragmentation/reassembly is used. OSPF protocol packets have 1663 been designed so that large protocol packets can generally be 1664 split into several smaller protocol packets. This practice is 1665 recommended; IP fragmentation should be avoided whenever 1666 possible. 1668 Routing protocol packets should always be sent with the IP TOS 1669 field set to 0. If at all possible, routing protocol packets 1670 should be given preference over regular IP data traffic, both 1671 when being sent and received. As an aid to accomplishing this, 1672 OSPF protocol packets should have their IP precedence field set 1673 to the value Internetwork Control (see [Ref5]). 1675 All OSPF protocol packets share a common protocol header that is 1676 described in Appendix A. The OSPF packet types are listed below 1677 in Table 8. Their formats are also described in Appendix A. 1679 Type Packet name Protocol function 1680 __________________________________________________________ 1681 1 Hello Discover/maintain neighbors 1682 2 Database Description Summarize database contents 1683 3 Link State Request Database download 1684 4 Link State Update Database update 1685 5 Link State Ack Flooding acknowledgment 1687 Table 8: OSPF packet types. 1689 OSPF's Hello protocol uses Hello packets to discover and 1690 maintain neighbor relationships. The Database Description and 1691 Link State Request packets are used in the forming of 1692 adjacencies. OSPF's reliable update mechanism is implemented by 1693 the Link State Update and Link State Acknowledgment packets. 1695 Each Link State Update packet carries a set of new link state 1696 advertisements (LSAs) one hop further away from their point of 1697 origination. A single Link State Update packet may contain the 1698 LSAs of several routers. Each LSA is tagged with the ID of the 1699 originating router and a checksum of its link state contents. 1700 Each LSA also has a type field; the different types of OSPF LSAs 1701 are listed below in Table 9. 1703 OSPF routing packets (with the exception of Hellos) are sent 1704 only over adjacencies. This means that all OSPF protocol 1705 packets travel a single IP hop, except those that are sent over 1706 virtual adjacencies. The IP source address of an OSPF protocol 1707 packet is one end of a router adjacency, and the IP destination 1708 address is either the other end of the adjacency or an IP 1709 multicast address. 1711 LS LSA LSA description 1712 type name 1713 ________________________________________________________ 1714 1 Router-LSAs Originated by all routers. 1715 This LSA describes 1716 the collected states of the 1717 router's interfaces to an 1718 area. Flooded throughout a 1719 single area only. 1720 ________________________________________________________ 1721 2 Network-LSAs Originated for broadcast 1722 and NBMA networks by 1723 the Designated Router. This 1724 LSA contains the 1725 list of routers connected 1726 to the network. Flooded 1727 throughout a single area only. 1728 ________________________________________________________ 1729 3,4 Summary-LSAs Originated by area border 1730 routers, and flooded through- 1731 out the LSA's associated 1732 area. Each summary-LSA 1733 describes a route to a 1734 destination outside the area, 1735 yet still inside the AS 1736 (i.e., an inter-area route). 1737 Type 3 summary-LSAs describe 1738 routes to networks. Type 4 1739 summary-LSAs describe 1740 routes to AS boundary routers. 1741 ________________________________________________________ 1742 5 AS-external-LSAs Originated by AS boundary 1743 routers, and flooded through- 1744 out the AS. Each 1745 AS-external-LSA describes 1746 a route to a destination in 1747 another Autonomous System. 1748 Default routes for the AS can 1749 also be described by 1750 AS-external-LSAs. 1752 Table 9: OSPF link state advertisements (LSAs). 1754 4.4. Basic implementation requirements 1756 An implementation of OSPF requires the following pieces of 1757 system support: 1759 Timers 1760 Two different kind of timers are required. The first kind, 1761 called "single shot timers", fire once and cause a protocol 1762 event to be processed. The second kind, called "interval 1763 timers", fire at continuous intervals. These are used for 1764 the sending of packets at regular intervals. A good example 1765 of this is the regular broadcast of Hello packets. The 1766 granularity of both kinds of timers is one second. 1768 Interval timers should be implemented to avoid drift. In 1769 some router implementations, packet processing can affect 1770 timer execution. When multiple routers are attached to a 1771 single network, all doing broadcasts, this can lead to the 1772 synchronization of routing packets (which should be 1773 avoided). If timers cannot be implemented to avoid drift, 1774 small random amounts should be added to/subtracted from the 1775 interval timer at each firing. 1777 IP multicast 1778 Certain OSPF packets take the form of IP multicast 1779 datagrams. Support for receiving and sending IP multicast 1780 datagrams, along with the appropriate lower-level protocol 1781 support, is required. The IP multicast datagrams used by 1782 OSPF never travel more than one hop. For this reason, the 1783 ability to forward IP multicast datagrams is not required. 1784 For information on IP multicast, see [Ref7]. 1786 Variable-length subnet support 1787 The router's IP protocol support must include the ability to 1788 divide a single IP class A, B, or C network number into many 1789 subnets of various sizes. This is commonly called 1790 variable-length subnetting; see Section 3.5 for details. 1792 IP supernetting support 1793 The router's IP protocol support must include the ability to 1794 aggregate contiguous collections of IP class A, B, and C 1795 networks into larger quantities called supernets. 1796 Supernetting has been proposed as one way to improve the 1797 scaling of IP routing in the worldwide Internet. For more 1798 information on IP supernetting, see [Ref10]. 1800 Lower-level protocol support 1801 The lower level protocols referred to here are the network 1802 access protocols, such as the Ethernet data link layer. 1803 Indications must be passed from these protocols to OSPF as 1804 the network interface goes up and down. For example, on an 1805 ethernet it would be valuable to know when the ethernet 1806 transceiver cable becomes unplugged. 1808 Non-broadcast lower-level protocol support 1809 On non-broadcast networks, the OSPF Hello Protocol can be 1810 aided by providing an indication when an attempt is made to 1811 send a packet to a dead or non-existent router. For 1812 example, on an X.25 PDN a dead neighboring router may be 1813 indicated by the reception of a X.25 clear with an 1814 appropriate cause and diagnostic, and this information would 1815 be passed to OSPF. 1817 List manipulation primitives 1818 Much of the OSPF functionality is described in terms of its 1819 operation on lists of LSAs. For example, the collection of 1820 LSAs that will be retransmitted to an adjacent router until 1821 acknowledged are described as a list. Any particular LSA 1822 may be on many such lists. An OSPF implementation needs to 1823 be able to manipulate these lists, adding and deleting 1824 constituent LSAs as necessary. 1826 Tasking support 1827 Certain procedures described in this specification invoke 1828 other procedures. At times, these other procedures should 1829 be executed in-line, that is, before the current procedure 1830 is finished. This is indicated in the text by instructions 1831 to execute a procedure. At other times, the other 1832 procedures are to be executed only when the current 1833 procedure has finished. This is indicated by instructions 1834 to schedule a task. 1836 4.5. Optional OSPF capabilities 1838 The OSPF protocol defines several optional capabilities. A 1839 router indicates the optional capabilities that it supports in 1840 its OSPF Hello packets, Database Description packets and in its 1841 LSAs. This enables routers supporting a mix of optional 1842 capabilities to coexist in a single Autonomous System. 1844 Some capabilities must be supported by all routers attached to a 1845 specific area. In this case, a router will not accept a 1846 neighbor's Hello Packet unless there is a match in reported 1847 capabilities (i.e., a capability mismatch prevents a neighbor 1848 relationship from forming). An example of this is the 1849 ExternalRoutingCapability (see below). 1851 Other capabilities can be negotiated during the Database 1852 Exchange process. This is accomplished by specifying the 1853 optional capabilities in Database Description packets. A 1854 capability mismatch with a neighbor in this case will result in 1855 only a subset of the link state database being exchanged between 1856 the two neighbors. 1858 The routing table build process can also be affected by the 1859 presence/absence of optional capabilities. For example, since 1860 the optional capabilities are reported in LSAs, routers 1861 incapable of certain functions can be avoided when building the 1862 shortest path tree. An example of this is the TOS routing 1863 capability (see below). 1865 The OSPF optional capabilities defined in this memo are listed 1866 below. See Section A.2 for more information. 1868 ExternalRoutingCapability 1869 Entire OSPF areas can be configured as "stubs" (see Section 1870 3.6). AS-external-LSAs will not be flooded into stub areas. 1871 This capability is represented by the E-bit in the OSPF 1872 Options field (see Section A.2). In order to ensure 1873 consistent configuration of stub areas, all routers 1874 interfacing to such an area must have the E-bit clear in 1875 their Hello packets (see Sections 9.5 and 10.5). 1877 TOS capability 1878 All OSPF implementations must be able to calculate separate 1879 routes based on IP Type of Service. However, to save 1880 routing table space and processing resources, an OSPF router 1881 can be configured to ignore TOS when forwarding packets. In 1882 this case, the router calculates routes for TOS 0 only. 1883 This capability is represented by the T-bit in the OSPF 1884 Options field (see Section A.2). TOS-capable routers will 1885 attempt to avoid non-TOS-capable routers when calculating 1886 non-zero TOS paths. 1888 5. Protocol Data Structures 1890 The OSPF protocol is described herein in terms of its operation on 1891 various protocol data structures. The following list comprises the 1892 top-level OSPF data structures. Any initialization that needs to be 1893 done is noted. OSPF areas, interfaces and neighbors also have 1894 associated data structures that are described later in this 1895 specification. 1897 Router ID 1898 A 32-bit number that uniquely identifies this router in the AS. 1899 One possible implementation strategy would be to use the 1900 smallest IP interface address belonging to the router. If a 1901 router's OSPF Router ID is changed, the router's OSPF software 1902 should be restarted before the new Router ID takes effect. In 1903 this case the router should flush its self-originated LSAs from 1904 the routing domain (see Section 14.1) before restarting, or they 1905 will persist for up to MaxAge minutes. 1907 Area structures 1908 Each one of the areas to which the router is connected has its 1909 own data structure. This data structure describes the working 1910 of the basic OSPF algorithm. Remember that each area runs a 1911 separate copy of the basic OSPF algorithm. 1913 Backbone (area) structure 1914 The OSPF backbone area is responsible for the dissemination of 1915 inter-area routing information. 1917 Virtual links configured 1918 The virtual links configured with this router as one endpoint. 1919 In order to have configured virtual links, the router itself 1920 must be an area border router. Virtual links are identified by 1921 the Router ID of the other endpoint -- which is another area 1922 border router. These two endpoint routers must be attached to a 1923 common area, called the virtual link's Transit area. Virtual 1924 links are part of the backbone, and behave as if they were 1925 unnumbered point-to-point networks between the two routers. A 1926 virtual link uses the intra-area routing of its Transit area to 1927 forward packets. Virtual links are brought up and down through 1928 the building of the shortest-path trees for the Transit area. 1930 List of external routes 1931 These are routes to destinations external to the Autonomous 1932 System, that have been gained either through direct experience 1933 with another routing protocol (such as BGP), or through 1934 configuration information, or through a combination of the two 1935 (e.g., dynamic external information to be advertised by OSPF 1936 with configured metric). Any router having these external routes 1937 is called an AS boundary router. These routes are advertised by 1938 the router into the OSPF routing domain via AS-external-LSAs. 1940 List of AS-external-LSAs 1941 Part of the link-state database. These have originated from the 1942 AS boundary routers. They comprise routes to destinations 1943 external to the Autonomous System. Note that, if the router is 1944 itself an AS boundary router, some of these AS-external-LSAs 1945 have been self-originated. 1947 The routing table 1948 Derived from the link-state database. Each entry in the routing 1949 table is indexed by a destination, and contains the 1950 destination's cost and a set of paths to use in forwarding 1951 packets to the destination. A path is described by its type and 1952 next hop. For more information, see Section 11. 1954 TOS capability 1955 This item indicates whether the router will calculate separate 1956 routes based on TOS. This is a configurable parameter. For 1957 more information, see Sections 4.5 and 16.9. 1959 Figure 9 shows the collection of data structures present in a 1960 typical router. The router pictured is RT10, from the map in Figure 1961 6. Note that Router RT10 has a virtual link configured to Router 1962 RT11, with Area 2 as the link's Transit area. This is indicated by 1963 the dashed line in Figure 9. When the virtual link becomes active, 1964 through the building of the shortest path tree for Area 2, it 1965 becomes an interface to the backbone (see the two backbone 1966 interfaces depicted in Figure 9). 1968 6. The Area Data Structure 1970 The area data structure contains all the information used to run the 1971 basic OSPF routing algorithm. Each area maintains its own link-state 1972 database. A network belongs to a single area, and a router interface 1973 connects to a single area. Each router adjacency also belongs to a 1974 single area. 1976 The OSPF backbone is the special OSPF area responsible for 1977 disseminating inter-area routing information. 1979 The area link-state database consists of the collection of router- 1980 LSAs, network-LSAs and summary-LSAs that have originated from the 1981 area's routers. This information is flooded throughout a single 1982 area only. The list of AS-external-LSAs (see Section 5) is also 1983 considered to be part of each area's link-state database. 1985 +----+ 1986 |RT10|------+ 1987 +----+ \+-------------+ 1988 / \ |Routing Table| 1989 / \ +-------------+ 1990 / \ 1991 +------+ / \ +--------+ 1992 |Area 2|---+ +---|Backbone| 1993 +------+***********+ +--------+ 1994 / \ * / \ 1995 / \ * / \ 1996 +---------+ +---------+ +------------+ +------------+ 1997 |Interface| |Interface| |Virtual Link| |Interface Ib| 1998 | to N6 | | to N8 | | to RT11 | +------------+ 1999 +---------+ +---------+ +------------+ | 2000 / \ | | | 2001 / \ | | | 2002 +--------+ +--------+ | +-------------+ +------------+ 2003 |Neighbor| |Neighbor| | |Neighbor RT11| |Neighbor RT6| 2004 | RT8 | | RT7 | | +-------------+ +------------+ 2005 +--------+ +--------+ | 2006 | 2007 +-------------+ 2008 |Neighbor RT11| 2009 +-------------+ 2011 Figure 9: Router RT10's Data structures 2013 Area ID 2014 A 32-bit number identifying the area. The Area ID of 0.0.0.0 is 2015 reserved for the backbone. 2017 List of area address ranges 2018 In order to aggregate routing information at area boundaries, 2019 area address ranges can be employed. Each address range is 2020 specified by an [address,mask] pair and a status indication of 2021 either Advertise or DoNotAdvertise (see Section 12.4.3). 2023 Associated router interfaces 2024 This router's interfaces connecting to the area. A router 2025 interface belongs to one and only one area (or the backbone). 2026 For the backbone area this list includes all the virtual links. 2027 A virtual link is identified by the Router ID of its other 2028 endpoint; its cost is the cost of the shortest intra-area path 2029 through the Transit area that exists between the two routers. 2031 List of router-LSAs 2032 A router-LSA is generated by each router in the area. It 2033 describes the state of the router's interfaces to the area. 2035 List of network-LSAs 2036 One network-LSA is generated for each transit broadcast and NBMA 2037 network in the area. A network-LSA describes the set of routers 2038 currently connected to the network. 2040 List of summary-LSAs 2041 Summary-LSAs originate from the area's area border routers. 2042 They describe routes to destinations internal to the Autonomous 2043 System, yet external to the area (i.e., inter-area 2044 destinations). 2046 Shortest-path tree 2047 The shortest-path tree for the area, with this router itself as 2048 root. Derived from the collected router-LSAs and network-LSAs 2049 by the Dijkstra algorithm (see Section 16.1). 2051 TransitCapability 2052 This parameter indicates whether the area can carry data traffic 2053 that neither originates nor terminates in the area itself. This 2054 parameter is calculated when the area's shortest-path tree is 2055 built (see Section 16.1, where TransitCapability is set to TRUE 2056 if and only if there are one or more fully adjacent virtual 2057 links using the area as Transit area), and is used as an input 2058 to a subsequent step of the routing table build process (see 2059 Section 16.3). When an area's TransitCapability is set to TRUE, 2060 the area is said to be a "transit area". 2062 ExternalRoutingCapability 2063 Whether AS-external-LSAs will be flooded into/throughout the 2064 area. This is a configurable parameter. If AS-external-LSAs 2065 are excluded from the area, the area is called a "stub". Within 2066 stub areas, routing to AS external destinations will be based 2067 solely on a default summary route. The backbone cannot be 2068 configured as a stub area. Also, virtual links cannot be 2069 configured through stub areas. For more information, see 2070 Section 3.6. 2072 StubDefaultCost 2073 If the area has been configured as a stub area, and the router 2074 itself is an area border router, then the StubDefaultCost 2075 indicates the cost of the default summary-LSA that the router 2076 should advertise into the area. There can be a separate cost 2077 configured for each IP TOS. See Section 12.4.3 for more 2078 information. 2080 Unless otherwise specified, the remaining sections of this document 2081 refer to the operation of the OSPF protocol within a single area. 2083 7. Bringing Up Adjacencies 2085 OSPF creates adjacencies between neighboring routers for the purpose 2086 of exchanging routing information. Not every two neighboring 2087 routers will become adjacent. This section covers the generalities 2088 involved in creating adjacencies. For further details consult 2089 Section 10. 2091 7.1. The Hello Protocol 2093 The Hello Protocol is responsible for establishing and 2094 maintaining neighbor relationships. It also ensures that 2095 communication between neighbors is bidirectional. Hello packets 2096 are sent periodically out all router interfaces. Bidirectional 2097 communication is indicated when the router sees itself listed in 2098 the neighbor's Hello Packet. On broadcast and NBMA networks, 2099 the Hello Protocol elects a Designated Router for the network. 2101 The Hello Protocol works differently on broadcast networks, NBMA 2102 networks and Point-to-MultiPoint networks. On broadcast 2103 networks, each router advertises itself by periodically 2104 multicasting Hello Packets. This allows neighbors to be 2105 discovered dynamically. These Hello Packets contain the 2106 router's view of the Designated Router's identity, and the list 2107 of routers whose Hello Packets have been seen recently. 2109 On NBMA networks some configuration information may be necessary 2110 for the operation of the Hello Protocol. Each router that may 2111 potentially become Designated Router has a list of all other 2112 routers attached to the network. A router, having Designated 2113 Router potential, sends Hello Packets to all other potential 2114 Designated Routers when its interface to the NBMA network first 2115 becomes operational. This is an attempt to find the Designated 2116 Router for the network. If the router itself is elected 2117 Designated Router, it begins sending Hello Packets to all other 2118 routers attached to the network. 2120 On Point-to-MultiPoint networks, a router sends Hello Packets to 2121 all neighbors with which it can communicate directly. These 2122 neighbors may be discovered dynamically through a protocol such 2123 as Inverse ARP (see [Ref14]), or they may be configured. 2125 After a neighbor has been discovered, bidirectional 2126 communication ensured, and (if on a broadcast or NBMA network) a 2127 Designated Router elected, a decision is made regarding whether 2128 or not an adjacency should be formed with the neighbor (see 2129 Section 10.4). If an adjacency is to be formed, the first step 2130 is to synchronize the neighbors' link-state databases. This is 2131 covered in the next section. 2133 7.2. The Synchronization of Databases 2135 In a link-state routing algorithm, it is very important for all 2136 routers' link-state databases to stay synchronized. OSPF 2137 simplifies this by requiring only adjacent routers to remain 2138 synchronized. The synchronization process begins as soon as the 2139 routers attempt to bring up the adjacency. Each router 2140 describes its database by sending a sequence of Database 2141 Description packets to its neighbor. Each Database Description 2142 Packet describes a set of LSAs belonging to the router's 2143 database. When the neighbor sees an LSA that is more recent 2144 than its own database copy, it makes a note that this newer LSA 2145 should be requested. 2147 This sending and receiving of Database Description packets is 2148 called the "Database Exchange Process". During this process, 2149 the two routers form a master/slave relationship. Each Database 2150 Description Packet has a sequence number. Database Description 2151 Packets sent by the master (polls) are acknowledged by the slave 2152 through echoing of the sequence number. Both polls and their 2153 responses contain summaries of link state data. The master is 2154 the only one allowed to retransmit Database Description Packets. 2155 It does so only at fixed intervals, the length of which is the 2156 configured per-interface constant RxmtInterval. 2158 Each Database Description contains an indication that there are 2159 more packets to follow --- the M-bit. The Database Exchange 2160 Process is over when a router has received and sent Database 2161 Description Packets with the M-bit off. 2163 During and after the Database Exchange Process, each router has 2164 a list of those LSAs for which the neighbor has more up-to-date 2165 instances. These LSAs are requested in Link State Request 2166 Packets. Link State Request packets that are not satisfied are 2167 retransmitted at fixed intervals of time RxmtInterval. When the 2168 Database Description Process has completed and all Link State 2169 Requests have been satisfied, the databases are deemed 2170 synchronized and the routers are marked fully adjacent. At this 2171 time the adjacency is fully functional and is advertised in the 2172 two routers' router-LSAs. 2174 The adjacency is used by the flooding procedure as soon as the 2175 Database Exchange Process begins. This simplifies database 2176 synchronization, and guarantees that it finishes in a 2177 predictable period of time. 2179 7.3. The Designated Router 2181 Every broadcast and NBMA network has a Designated Router. The 2182 Designated Router performs two main functions for the routing 2183 protocol: 2185 o The Designated Router originates a network-LSA on behalf of 2186 the network. This LSA lists the set of routers (including 2187 the Designated Router itself) currently attached to the 2188 network. The Link State ID for this LSA (see Section 2189 12.1.4) is the IP interface address of the Designated 2190 Router. The IP network number can then be obtained by using 2191 the network's subnet/network mask. 2193 o The Designated Router becomes adjacent to all other routers 2194 on the network. Since the link state databases are 2195 synchronized across adjacencies (through adjacency bring-up 2196 and then the flooding procedure), the Designated Router 2197 plays a central part in the synchronization process. 2199 The Designated Router is elected by the Hello Protocol. A 2200 router's Hello Packet contains its Router Priority, which is 2201 configurable on a per-interface basis. In general, when a 2202 router's interface to a network first becomes functional, it 2203 checks to see whether there is currently a Designated Router for 2204 the network. If there is, it accepts that Designated Router, 2205 regardless of its Router Priority. (This makes it harder to 2206 predict the identity of the Designated Router, but ensures that 2207 the Designated Router changes less often. See below.) 2208 Otherwise, the router itself becomes Designated Router if it has 2209 the highest Router Priority on the network. A more detailed 2210 (and more accurate) description of Designated Router election is 2211 presented in Section 9.4. 2213 The Designated Router is the endpoint of many adjacencies. In 2214 order to optimize the flooding procedure on broadcast networks, 2215 the Designated Router multicasts its Link State Update Packets 2216 to the address AllSPFRouters, rather than sending separate 2217 packets over each adjacency. 2219 Section 2 of this document discusses the directed graph 2220 representation of an area. Router nodes are labelled with their 2221 Router ID. Transit network nodes are actually labelled with the 2222 IP address of their Designated Router. It follows that when the 2223 Designated Router changes, it appears as if the network node on 2224 the graph is replaced by an entirely new node. This will cause 2225 the network and all its attached routers to originate new LSAs. 2226 Until the link-state databases again converge, some temporary 2227 loss of connectivity may result. This may result in ICMP 2228 unreachable messages being sent in response to data traffic. 2229 For that reason, the Designated Router should change only 2230 infrequently. Router Priorities should be configured so that 2231 the most dependable router on a network eventually becomes 2232 Designated Router. 2234 7.4. The Backup Designated Router 2236 In order to make the transition to a new Designated Router 2237 smoother, there is a Backup Designated Router for each broadcast 2238 and NBMA network. The Backup Designated Router is also adjacent 2239 to all routers on the network, and becomes Designated Router 2240 when the previous Designated Router fails. If there were no 2241 Backup Designated Router, when a new Designated Router became 2242 necessary, new adjacencies would have to be formed between the 2243 new Designated Router and all other routers attached to the 2244 network. Part of the adjacency forming process is the 2245 synchronizing of link-state databases, which can potentially 2246 take quite a long time. During this time, the network would not 2247 be available for transit data traffic. The Backup Designated 2248 obviates the need to form these adjacencies, since they already 2249 exist. This means the period of disruption in transit traffic 2250 lasts only as long as it takes to flood the new LSAs (which 2251 announce the new Designated Router). 2253 The Backup Designated Router does not generate a network-LSA for 2254 the network. (If it did, the transition to a new Designated 2255 Router would be even faster. However, this is a tradeoff 2256 between database size and speed of convergence when the 2257 Designated Router disappears.) 2259 The Backup Designated Router is also elected by the Hello 2260 Protocol. Each Hello Packet has a field that specifies the 2261 Backup Designated Router for the network. 2263 In some steps of the flooding procedure, the Backup Designated 2264 Router plays a passive role, letting the Designated Router do 2265 more of the work. This cuts down on the amount of local routing 2266 traffic. See Section 13.3 for more information. 2268 7.5. The graph of adjacencies 2270 An adjacency is bound to the network that the two routers have 2271 in common. If two routers have multiple networks in common, 2272 they may have multiple adjacencies between them. 2274 One can picture the collection of adjacencies on a network as 2275 forming an undirected graph. The vertices consist of routers, 2276 with an edge joining two routers if they are adjacent. The 2277 graph of adjacencies describes the flow of routing protocol 2278 packets, and in particular Link State Update Packets, through 2279 the Autonomous System. 2281 Two graphs are possible, depending on whether a Designated 2282 Router is elected for the network. On physical point-to-point 2283 networks, Point-to-MultiPoint networks and virtual links, 2284 neighboring routers become adjacent whenever they can 2285 communicate directly. In contrast, on broadcast and NBMA 2286 networks only the Designated Router and the Backup Designated 2287 Router become adjacent to all other routers attached to the 2288 network. 2290 These graphs are shown in Figure 10. It is assumed that Router 2291 RT7 has become the Designated Router, and Router RT3 the Backup 2292 Designated Router, for the Network N2. The Backup Designated 2293 Router performs a lesser function during the flooding procedure 2294 than the Designated Router (see Section 13.3). This is the 2295 reason for the dashed lines connecting the Backup Designated 2296 Router RT3. 2298 8. Protocol Packet Processing 2300 This section discusses the general processing of OSPF routing 2301 protocol packets. It is very important that the router link-state 2302 databases remain synchronized. For this reason, routing protocol 2303 packets should get preferential treatment over ordinary data 2304 packets, both in sending and receiving. 2306 Routing protocol packets are sent along adjacencies only (with the 2307 exception of Hello packets, which are used to discover the 2308 adjacencies). This means that all routing protocol packets travel a 2310 +---+ +---+ 2311 |RT1|------------|RT2| o---------------o 2312 +---+ N1 +---+ RT1 RT2 2314 RT7 2315 o---------+ 2316 +---+ +---+ +---+ /|\ | 2317 |RT7| |RT3| |RT4| / | \ | 2318 +---+ +---+ +---+ / | \ | 2319 | | | / | \ | 2320 +-----------------------+ RT5o RT6o oRT4 | 2321 | | N2 * * * | 2322 +---+ +---+ * * * | 2323 |RT5| |RT6| * * * | 2324 +---+ +---+ *** | 2325 o---------+ 2326 RT3 2328 Figure 10: The graph of adjacencies 2330 single IP hop, except those sent over virtual links. 2332 All routing protocol packets begin with a standard header. The 2333 sections below provide details on how to fill in and verify this 2334 standard header. Then, for each packet type, the section giving 2335 more details on that particular packet type's processing is listed. 2337 8.1. Sending protocol packets 2339 When a router sends a routing protocol packet, it fills in the 2340 fields of the standard OSPF packet header as follows. For more 2341 details on the header format consult Section A.3.1: 2343 Version # 2344 Set to 2, the version number of the protocol as documented 2345 in this specification. 2347 Packet type 2348 The type of OSPF packet, such as Link state Update or Hello 2349 Packet. 2351 Packet length 2352 The length of the entire OSPF packet in bytes, including the 2353 standard OSPF packet header. 2355 Router ID 2356 The identity of the router itself (who is originating the 2357 packet). 2359 Area ID 2360 The OSPF area that the packet is being sent into. 2362 Checksum 2363 The standard IP 16-bit one's complement checksum of the 2364 entire OSPF packet, excluding the 64-bit authentication 2365 field. This checksum is calculated as part of the 2366 appropriate authentication procedure; for some OSPF 2367 authentication types, the checksum calculation is omitted. 2368 See Section D.4 for details. 2370 AuType and Authentication 2371 Each OSPF packet exchange is authenticated. Authentication 2372 types are assigned by the protocol and are documented in 2373 Appendix D. A different authentication procedure can be 2374 used for each IP network/subnet. Autype indicates the type 2375 of authentication procedure in use. The 64-bit 2376 authentication field is then for use by the chosen 2377 authentication procedure. This procedure should be the last 2378 called when forming the packet to be sent. See Section D.4 2379 for details. 2381 The IP destination address for the packet is selected as 2382 follows. On physical point-to-point networks, the IP 2383 destination is always set to the address AllSPFRouters. On all 2384 other network types (including virtual links), the majority of 2385 OSPF packets are sent as unicasts, i.e., sent directly to the 2386 other end of the adjacency. In this case, the IP destination is 2387 just the Neighbor IP address associated with the other end of 2388 the adjacency (see Section 10). The only packets not sent as 2389 unicasts are on broadcast networks; on these networks Hello 2390 packets are sent to the multicast destination AllSPFRouters, the 2391 Designated Router and its Backup send both Link State Update 2392 Packets and Link State Acknowledgment Packets to the multicast 2393 address AllSPFRouters, while all other routers send both their 2394 Link State Update and Link State Acknowledgment Packets to the 2395 multicast address AllDRouters. 2397 Retransmissions of Link State Update packets are ALWAYS sent as 2398 unicasts. 2400 The IP source address should be set to the IP address of the 2401 sending interface. Interfaces to unnumbered point-to-point 2402 networks have no associated IP address. On these interfaces, 2403 the IP source should be set to any of the other IP addresses 2404 belonging to the router. For this reason, there must be at 2405 least one IP address assigned to the router.[2] Note that, for 2406 most purposes, virtual links act precisely the same as 2407 unnumbered point-to-point networks. However, each virtual link 2408 does have an IP interface address (discovered during the routing 2409 table build process) which is used as the IP source when sending 2410 packets over the virtual link. 2412 For more information on the format of specific OSPF packet 2413 types, consult the sections listed in Table 10. 2415 Type Packet name detailed section (transmit) 2416 _________________________________________________________ 2417 1 Hello Section 9.5 2418 2 Database description Section 10.8 2419 3 Link state request Section 10.9 2420 4 Link state update Section 13.3 2421 5 Link state ack Section 13.5 2423 Table 10: Sections describing OSPF protocol packet transmission. 2425 8.2. Receiving protocol packets 2427 Whenever a protocol packet is received by the router it is 2428 marked with the interface it was received on. For routers that 2429 have virtual links configured, it may not be immediately obvious 2430 which interface to associate the packet with. For example, 2431 consider the Router RT11 depicted in Figure 6. If RT11 receives 2432 an OSPF protocol packet on its interface to Network N8, it may 2433 want to associate the packet with the interface to Area 2, or 2434 with the virtual link to Router RT10 (which is part of the 2435 backbone). In the following, we assume that the packet is 2436 initially associated with the non-virtual link.[3] 2438 In order for the packet to be accepted at the IP level, it must 2439 pass a number of tests, even before the packet is passed to OSPF 2440 for processing: 2442 o The IP checksum must be correct. 2444 o The packet's IP destination address must be the IP address 2445 of the receiving interface, or one of the IP multicast 2446 addresses AllSPFRouters or AllDRouters. 2448 o The IP protocol specified must be OSPF (89). 2450 o Locally originated packets should not be passed on to OSPF. 2451 That is, the source IP address should be examined to make 2452 sure this is not a multicast packet that the router itself 2453 generated. 2455 Next, the OSPF packet header is verified. The fields specified 2456 in the header must match those configured for the receiving 2457 interface. If they do not, the packet should be discarded: 2459 o The version number field must specify protocol version 2. 2461 o The Area ID found in the OSPF header must be verified. If 2462 both of the following cases fail, the packet should be 2463 discarded. The Area ID specified in the header must either: 2465 (1) Match the Area ID of the receiving interface. In this 2466 case, the packet has been sent over a single hop. 2467 Therefore, the packet's IP source address is required to 2468 be on the same network as the receiving interface. This 2469 can be verified by comparing the packet's IP source 2470 address to the interface's IP address, after masking 2471 both addresses with the interface mask. This comparison 2472 should not be performed on point-to-point networks. On 2473 point-to-point networks, the interface addresses of each 2474 end of the link are assigned independently, if they are 2475 assigned at all. 2477 (2) Indicate the backbone. In this case, the packet has 2478 been sent over a virtual link. The receiving router 2479 must be an area border router, and the Router ID 2480 specified in the packet (the source router) must be the 2481 other end of a configured virtual link. The receiving 2482 interface must also attach to the virtual link's 2483 configured Transit area. If all of these checks 2484 succeed, the packet is accepted and is from now on 2485 associated with the virtual link (and the backbone 2486 area). 2488 o Packets whose IP destination is AllDRouters should only be 2489 accepted if the state of the receiving interface is DR or 2490 Backup (see Section 9.1). 2492 o The AuType specified in the packet must match the AuType 2493 specified for the associated area. 2495 o The packet must be authenticated. The authentication 2496 procedure is indicated by the setting of AuType (see 2497 Appendix D). The authentication procedure may use one or 2498 more Authentication keys, which can be configured on a per- 2499 interface basis. The authentication procedure may also 2500 verify the checksum field in the OSPF packet header (which, 2501 when used, is set to the standard IP 16-bit one's complement 2502 checksum of the OSPF packet's contents after excluding the 2503 64-bit authentication field). If the authentication 2504 procedure fails, the packet should be discarded. 2506 If the packet type is Hello, it should then be further processed 2507 by the Hello Protocol (see Section 10.5). All other packet 2508 types are sent/received only on adjacencies. This means that 2509 the packet must have been sent by one of the router's active 2510 neighbors. If the receiving interface connects to a broadcast 2511 network, Point-to-MultiPoint network or NBMA network the sender 2512 is identified by the IP source address found in the packet's IP 2513 header. If the receiving interface connects to a point-to-point 2514 network or a virtual link, the sender is identified by the 2515 Router ID (source router) found in the packet's OSPF header. 2516 The data structure associated with the receiving interface 2517 contains the list of active neighbors. Packets not matching any 2518 active neighbor are discarded. 2520 At this point all received protocol packets are associated with 2521 an active neighbor. For the further input processing of 2522 specific packet types, consult the sections listed in Table 11. 2524 Type Packet name detailed section (receive) 2525 ________________________________________________________ 2526 1 Hello Section 10.5 2527 2 Database description Section 10.6 2528 3 Link state request Section 10.7 2529 4 Link state update Section 13 2530 5 Link state ack Section 13.7 2532 Table 11: Sections describing OSPF protocol packet reception. 2534 9. The Interface Data Structure 2536 An OSPF interface is the connection between a router and a network. 2537 We assume a single OSPF interface to each attached network/subnet, 2538 although supporting multiple interfaces on a single network is 2539 considered in Appendix F. Each interface structure has at most one 2540 IP interface address. 2542 An OSPF interface can be considered to belong to the area that 2543 contains the attached network. All routing protocol packets 2544 originated by the router over this interface are labelled with the 2545 interface's Area ID. One or more router adjacencies may develop 2546 over an interface. A router's LSAs reflect the state of its 2547 interfaces and their associated adjacencies. 2549 The following data items are associated with an interface. Note 2550 that a number of these items are actually configuration for the 2551 attached network; such items must be the same for all routers 2552 connected to the network. 2554 Type 2555 The OSPF interface type is either point-to-point, broadcast, 2556 NBMA, Point-to-MultiPoint or virtual link. 2558 State 2559 The functional level of an interface. State determines whether 2560 or not full adjacencies are allowed to form over the interface. 2561 State is also reflected in the router's LSAs. 2563 IP interface address 2564 The IP address associated with the interface. This appears as 2565 the IP source address in all routing protocol packets originated 2566 over this interface. Interfaces to unnumbered point-to-point 2567 networks do not have an associated IP address. 2569 IP interface mask 2570 Also referred to as the subnet mask, this indicates the portion 2571 of the IP interface address that identifies the attached 2572 network. Masking the IP interface address with the IP interface 2573 mask yields the IP network number of the attached network. On 2574 point-to-point networks and virtual links, the IP interface mask 2575 is not defined. On these networks, the link itself is not 2576 assigned an IP network number, and so the addresses of each side 2577 of the link are assigned independently, if they are assigned at 2578 all. 2580 Area ID 2581 The Area ID of the area to which the attached network belongs. 2582 All routing protocol packets originating from the interface are 2583 labelled with this Area ID. 2585 HelloInterval 2586 The length of time, in seconds, between the Hello packets that 2587 the router sends on the interface. Advertised in Hello packets 2588 sent out this interface. 2590 RouterDeadInterval 2591 The number of seconds before the router's neighbors will declare 2592 it down, when they stop hearing the router's Hello Packets. 2593 Advertised in Hello packets sent out this interface. 2595 InfTransDelay 2596 The estimated number of seconds it takes to transmit a Link 2597 State Update Packet over this interface. LSAs contained in the 2598 Link State Update packet will have their age incremented by this 2599 amount before transmission. This value should take into account 2600 transmission and propagation delays; it must be greater than 2601 zero. 2603 Router Priority 2604 An 8-bit unsigned integer. When two routers attached to a 2605 network both attempt to become Designated Router, the one with 2606 the highest Router Priority takes precedence. A router whose 2607 Router Priority is set to 0 is ineligible to become Designated 2608 Router on the attached network. Advertised in Hello packets 2609 sent out this interface. 2611 Hello Timer 2612 An interval timer that causes the interface to send a Hello 2613 packet. This timer fires every HelloInterval seconds. Note 2614 that on non-broadcast networks a separate Hello packet is sent 2615 to each qualified neighbor. 2617 Wait Timer 2618 A single shot timer that causes the interface to exit the 2619 Waiting state, and as a consequence select a Designated Router 2620 on the network. The length of the timer is RouterDeadInterval 2621 seconds. 2623 List of neighboring routers 2624 The other routers attached to this network. This list is formed 2625 by the Hello Protocol. Adjacencies will be formed to some of 2626 these neighbors. The set of adjacent neighbors can be 2627 determined by an examination of all of the neighbors' states. 2629 Designated Router 2630 The Designated Router selected for the attached network. The 2631 Designated Router is selected on all broadcast and NBMA networks 2632 by the Hello Protocol. Two pieces of identification are kept 2633 for the Designated Router: its Router ID and its IP interface 2634 address on the network. The Designated Router advertises link 2635 state for the network; this network-LSA is labelled with the 2636 Designated Router's IP address. The Designated Router is 2637 initialized to 0.0.0.0, which indicates the lack of a Designated 2638 Router. 2640 Backup Designated Router 2641 The Backup Designated Router is also selected on all broadcast 2642 and NBMA networks by the Hello Protocol. All routers on the 2643 attached network become adjacent to both the Designated Router 2644 and the Backup Designated Router. The Backup Designated Router 2645 becomes Designated Router when the current Designated Router 2646 fails. The Backup Designated Router is initialized to 0.0.0.0, 2647 indicating the lack of a Backup Designated Router. 2649 Interface output cost(s) 2650 The cost of sending a data packet on the interface, expressed in 2651 the link state metric. This is advertised as the link cost for 2652 this interface in the router-LSA. There may be a separate cost 2653 for each IP Type of Service. The cost of an interface must be 2654 greater than zero. 2656 RxmtInterval 2657 The number of seconds between LSA retransmissions, for 2658 adjacencies belonging to this interface. Also used when 2659 retransmitting Database Description and Link State Request 2660 Packets. 2662 AuType 2663 The type of authentication used on the attached network/subnet. 2664 Authentication types are defined in Appendix D. All OSPF packet 2665 exchanges are authenticated. Different authentication schemes 2666 may be used on different networks/subnets. 2668 Authentication key 2669 This configured data allows the authentication procedure to 2670 generate and/or verify OSPF protocol packets. The 2671 Authentication key can be configured on a per-interface basis. 2672 For example, if the AuType indicates simple password, the 2673 Authentication key would be a 64-bit clear password which is 2674 inserted into the OSPF packet header. If instead Autype 2675 indicates Cryptographic authentication, then the Authentication 2676 key is a shared secret which enables the generation/verification 2677 of message digests which are appended to the OSPF protocol 2678 packets. When Cryptographic authentication is used, multiple 2679 simultaneous keys are supported in order to achieve smooth key 2680 transition (see Section D.3). 2682 9.1. Interface states 2684 The various states that router interfaces may attain is 2685 documented in this section. The states are listed in order of 2686 progressing functionality. For example, the inoperative state 2687 is listed first, followed by a list of intermediate states 2688 before the final, fully functional state is achieved. The 2689 specification makes use of this ordering by sometimes making 2690 references such as "those interfaces in state greater than X". 2691 Figure 11 shows the graph of interface state changes. The arcs 2693 +----+ UnloopInd +--------+ 2694 |Down|<--------------|Loopback| 2695 +----+ +--------+ 2696 | 2697 |InterfaceUp 2698 +-------+ | +--------------+ 2699 |Waiting|<-+-------------->|Point-to-point| 2700 +-------+ +--------------+ 2701 | 2702 WaitTimer|BackupSeen 2703 | 2704 | 2705 | NeighborChange 2706 +------+ +-+<---------------- +-------+ 2707 |Backup|<----------|?|----------------->|DROther| 2708 +------+---------->+-+<-----+ +-------+ 2709 Neighbor | | 2710 Change | |Neighbor 2711 | |Change 2712 | +--+ 2713 +---->|DR| 2714 +--+ 2716 Figure 11: Interface State changes 2718 In addition to the state transitions pictured, 2719 Event InterfaceDown always forces Down State, and 2720 Event LoopInd always forces Loopback State 2721 of the graph are labelled with the event causing the state 2722 change. These events are documented in Section 9.2. The 2723 interface state machine is described in more detail in Section 2724 9.3. 2726 Down 2727 This is the initial interface state. In this state, the 2728 lower-level protocols have indicated that the interface is 2729 unusable. No protocol traffic at all will be sent or 2730 received on such a interface. In this state, interface 2731 parameters should be set to their initial values. All 2732 interface timers should be disabled, and there should be no 2733 adjacencies associated with the interface. 2735 Loopback 2736 In this state, the router's interface to the network is 2737 looped back. The interface may be looped back in hardware 2738 or software. The interface will be unavailable for regular 2739 data traffic. However, it may still be desirable to gain 2740 information on the quality of this interface, either through 2741 sending ICMP pings to the interface or through something 2742 like a bit error test. For this reason, IP packets may 2743 still be addressed to an interface in Loopback state. To 2744 facilitate this, such interfaces are advertised in router- 2745 LSAs as single host routes, whose destination is the IP 2746 interface address.[4] 2748 Waiting 2749 In this state, the router is trying to determine the 2750 identity of the (Backup) Designated Router for the network. 2751 To do this, the router monitors the Hello Packets it 2752 receives. The router is not allowed to elect a Backup 2753 Designated Router nor a Designated Router until it 2754 transitions out of Waiting state. This prevents unnecessary 2755 changes of (Backup) Designated Router. 2757 Point-to-point 2758 In this state, the interface is operational, and connects 2759 either to a physical point-to-point network or to a virtual 2760 link. Upon entering this state, the router attempts to form 2761 an adjacency with the neighboring router. Hello Packets are 2762 sent to the neighbor every HelloInterval seconds. 2764 DR Other 2765 The interface is to a broadcast or NBMA network on which 2766 another router has been selected to be the Designated 2767 Router. In this state, the router itself has not been 2768 selected Backup Designated Router either. The router forms 2769 adjacencies to both the Designated Router and the Backup 2770 Designated Router (if they exist). 2772 Backup 2773 In this state, the router itself is the Backup Designated 2774 Router on the attached network. It will be promoted to 2775 Designated Router when the present Designated Router fails. 2776 The router establishes adjacencies to all other routers 2777 attached to the network. The Backup Designated Router 2778 performs slightly different functions during the Flooding 2779 Procedure, as compared to the Designated Router (see Section 2780 13.3). See Section 7.4 for more details on the functions 2781 performed by the Backup Designated Router. 2783 DR In this state, this router itself is the Designated Router 2784 on the attached network. Adjacencies are established to all 2785 other routers attached to the network. The router must also 2786 originate a network-LSA for the network node. The network- 2787 LSA will contain links to all routers (including the 2788 Designated Router itself) attached to the network. See 2789 Section 7.3 for more details on the functions performed by 2790 the Designated Router. 2792 9.2. Events causing interface state changes 2794 State changes can be effected by a number of events. These 2795 events are pictured as the labelled arcs in Figure 11. The 2796 label definitions are listed below. For a detailed explanation 2797 of the effect of these events on OSPF protocol operation, 2798 consult Section 9.3. 2800 InterfaceUp 2801 Lower-level protocols have indicated that the network 2802 interface is operational. This enables the interface to 2803 transition out of Down state. On virtual links, the 2804 interface operational indication is actually a result of the 2805 shortest path calculation (see Section 16.7). 2807 WaitTimer 2808 The Wait Timer has fired, indicating the end of the waiting 2809 period that is required before electing a (Backup) 2810 Designated Router. 2812 BackupSeen 2813 The router has detected the existence or non-existence of a 2814 Backup Designated Router for the network. This is done in 2815 one of two ways. First, an Hello Packet may be received 2816 from a neighbor claiming to be itself the Backup Designated 2817 Router. Alternatively, an Hello Packet may be received from 2818 a neighbor claiming to be itself the Designated Router, and 2819 indicating that there is no Backup Designated Router. In 2820 either case there must be bidirectional communication with 2821 the neighbor, i.e., the router must also appear in the 2822 neighbor's Hello Packet. This event signals an end to the 2823 Waiting state. 2825 NeighborChange 2826 There has been a change in the set of bidirectional 2827 neighbors associated with the interface. The (Backup) 2828 Designated Router needs to be recalculated. The following 2829 neighbor changes lead to the NeighborChange event. For an 2830 explanation of neighbor states, see Section 10.1. 2832 o Bidirectional communication has been established to a 2833 neighbor. In other words, the state of the neighbor has 2834 transitioned to 2-Way or higher. 2836 o There is no longer bidirectional communication with a 2837 neighbor. In other words, the state of the neighbor has 2838 transitioned to Init or lower. 2840 o One of the bidirectional neighbors is newly declaring 2841 itself as either Designated Router or Backup Designated 2842 Router. This is detected through examination of that 2843 neighbor's Hello Packets. 2845 o One of the bidirectional neighbors is no longer 2846 declaring itself as Designated Router, or is no longer 2847 declaring itself as Backup Designated Router. This is 2848 again detected through examination of that neighbor's 2849 Hello Packets. 2851 o The advertised Router Priority for a bidirectional 2852 neighbor has changed. This is again detected through 2853 examination of that neighbor's Hello Packets. 2855 LoopInd 2856 An indication has been received that the interface is now 2857 looped back to itself. This indication can be received 2858 either from network management or from the lower level 2859 protocols. 2861 UnloopInd 2862 An indication has been received that the interface is no 2863 longer looped back. As with the LoopInd event, this 2864 indication can be received either from network management or 2865 from the lower level protocols. 2867 InterfaceDown 2868 Lower-level protocols indicate that this interface is no 2869 longer functional. No matter what the current interface 2870 state is, the new interface state will be Down. 2872 9.3. The Interface state machine 2874 A detailed description of the interface state changes follows. 2875 Each state change is invoked by an event (Section 9.2). This 2876 event may produce different effects, depending on the current 2877 state of the interface. For this reason, the state machine 2878 below is organized by current interface state and received 2879 event. Each entry in the state machine describes the resulting 2880 new interface state and the required set of additional actions. 2882 When an interface's state changes, it may be necessary to 2883 originate a new router-LSA. See Section 12.4 for more details. 2885 Some of the required actions below involve generating events for 2886 the neighbor state machine. For example, when an interface 2887 becomes inoperative, all neighbor connections associated with 2888 the interface must be destroyed. For more information on the 2889 neighbor state machine, see Section 10.3. 2891 State(s): Down 2893 Event: InterfaceUp 2895 New state: Depends upon action routine 2897 Action: Start the interval Hello Timer, enabling the 2898 periodic sending of Hello packets out the interface. 2899 If the attached network is a physical point-to-point 2900 network, Point-to-MultiPoint network or virtual 2901 link, the interface state transitions to Point-to- 2902 Point. Else, if the router is not eligible to 2903 become Designated Router the interface state 2904 transitions to DR Other. 2906 Otherwise, the attached network is a broadcast or 2907 NBMA network and the router is eligible to become 2908 Designated Router. In this case, in an attempt to 2909 discover the attached network's Designated Router 2910 the interface state is set to Waiting and the single 2911 shot Wait Timer is started. Additionally, if the 2912 network is an NBMA network examine the configured 2913 list of neighbors for this interface and generate 2914 the neighbor event Start for each neighbor that is 2915 also eligible to become Designated Router. 2917 State(s): Waiting 2919 Event: BackupSeen 2921 New state: Depends upon action routine. 2923 Action: Calculate the attached network's Backup Designated 2924 Router and Designated Router, as shown in Section 2925 9.4. As a result of this calculation, the new state 2926 of the interface will be either DR Other, Backup or 2927 DR. 2929 State(s): Waiting 2931 Event: WaitTimer 2933 New state: Depends upon action routine. 2935 Action: Calculate the attached network's Backup Designated 2936 Router and Designated Router, as shown in Section 2937 9.4. As a result of this calculation, the new state 2938 of the interface will be either DR Other, Backup or 2939 DR. 2941 State(s): DR Other, Backup or DR 2943 Event: NeighborChange 2945 New state: Depends upon action routine. 2947 Action: Recalculate the attached network's Backup Designated 2948 Router and Designated Router, as shown in Section 2949 9.4. As a result of this calculation, the new state 2950 of the interface will be either DR Other, Backup or 2951 DR. 2953 State(s): Any State 2955 Event: InterfaceDown 2957 New state: Down 2959 Action: All interface variables are reset, and interface 2960 timers disabled. Also, all neighbor connections 2961 associated with the interface are destroyed. This 2962 is done by generating the event KillNbr on all 2963 associated neighbors (see Section 10.2). 2965 State(s): Any State 2967 Event: LoopInd 2969 New state: Loopback 2971 Action: Since this interface is no longer connected to the 2972 attached network the actions associated with the 2973 above InterfaceDown event are executed. 2975 State(s): Loopback 2977 Event: UnloopInd 2979 New state: Down 2981 Action: No actions are necessary. For example, the 2982 interface variables have already been reset upon 2983 entering the Loopback state. Note that reception of 2984 an InterfaceUp event is necessary before the 2985 interface again becomes fully functional. 2987 9.4. Electing the Designated Router 2989 This section describes the algorithm used for calculating a 2990 network's Designated Router and Backup Designated Router. This 2991 algorithm is invoked by the Interface state machine. The 2992 initial time a router runs the election algorithm for a network, 2993 the network's Designated Router and Backup Designated Router are 2994 initialized to 0.0.0.0. This indicates the lack of both a 2995 Designated Router and a Backup Designated Router. 2997 The Designated Router election algorithm proceeds as follows: 2998 Call the router doing the calculation Router X. The list of 2999 neighbors attached to the network and having established 3000 bidirectional communication with Router X is examined. This 3001 list is precisely the collection of Router X's neighbors (on 3002 this network) whose state is greater than or equal to 2-Way (see 3003 Section 10.1). Router X itself is also considered to be on the 3004 list. Discard all routers from the list that are ineligible to 3005 become Designated Router. (Routers having Router Priority of 0 3006 are ineligible to become Designated Router.) The following 3007 steps are then executed, considering only those routers that 3008 remain on the list: 3010 (1) Note the current values for the network's Designated Router 3011 and Backup Designated Router. This is used later for 3012 comparison purposes. 3014 (2) Calculate the new Backup Designated Router for the network 3015 as follows. Only those routers on the list that have not 3016 declared themselves to be Designated Router are eligible to 3017 become Backup Designated Router. If one or more of these 3018 routers have declared themselves Backup Designated Router 3019 (i.e., they are currently listing themselves as Backup 3020 Designated Router, but not as Designated Router, in their 3021 Hello Packets) the one having highest Router Priority is 3022 declared to be Backup Designated Router. In case of a tie, 3023 the one having the highest Router ID is chosen. If no 3024 routers have declared themselves Backup Designated Router, 3025 choose the router having highest Router Priority, (again 3026 excluding those routers who have declared themselves 3027 Designated Router), and again use the Router ID to break 3028 ties. 3030 (3) Calculate the new Designated Router for the network as 3031 follows. If one or more of the routers have declared 3032 themselves Designated Router (i.e., they are currently 3033 listing themselves as Designated Router in their Hello 3034 Packets) the one having highest Router Priority is declared 3035 to be Designated Router. In case of a tie, the one having 3036 the highest Router ID is chosen. If no routers have 3037 declared themselves Designated Router, assign the Designated 3038 Router to be the same as the newly elected Backup Designated 3039 Router. 3041 (4) If Router X is now newly the Designated Router or newly the 3042 Backup Designated Router, or is now no longer the Designated 3043 Router or no longer the Backup Designated Router, repeat 3044 steps 2 and 3, and then proceed to step 5. For example, if 3045 Router X is now the Designated Router, when step 2 is 3046 repeated X will no longer be eligible for Backup Designated 3047 Router election. Among other things, this will ensure that 3048 no router will declare itself both Backup Designated Router 3049 and Designated Router.[5] 3051 (5) As a result of these calculations, the router itself may now 3052 be Designated Router or Backup Designated Router. See 3053 Sections 7.3 and 7.4 for the additional duties this would 3054 entail. The router's interface state should be set 3055 accordingly. If the router itself is now Designated Router, 3056 the new interface state is DR. If the router itself is now 3057 Backup Designated Router, the new interface state is Backup. 3058 Otherwise, the new interface state is DR Other. 3060 (6) If the attached network is an NBMA network, and the router 3061 itself has just become either Designated Router or Backup 3062 Designated Router, it must start sending Hello Packets to 3063 those neighbors that are not eligible to become Designated 3064 Router (see Section 9.5.1). This is done by invoking the 3065 neighbor event Start for each neighbor having a Router 3066 Priority of 0. 3068 (7) If the above calculations have caused the identity of either 3069 the Designated Router or Backup Designated Router to change, 3070 the set of adjacencies associated with this interface will 3071 need to be modified. Some adjacencies may need to be 3072 formed, and others may need to be broken. To accomplish 3073 this, invoke the event AdjOK? on all neighbors whose state 3074 is at least 2-Way. This will cause their eligibility for 3075 adjacency to be reexamined (see Sections 10.3 and 10.4). 3077 The reason behind the election algorithm's complexity is the 3078 desire for an orderly transition from Backup Designated Router 3079 to Designated Router, when the current Designated Router fails. 3080 This orderly transition is ensured through the introduction of 3081 hysteresis: no new Backup Designated Router can be chosen until 3082 the old Backup accepts its new Designated Router 3083 responsibilities. 3085 The above procedure may elect the same router to be both 3086 Designated Router and Backup Designated Router, although that 3087 router will never be the calculating router (Router X) itself. 3089 The elected Designated Router may not be the router having the 3090 highest Router Priority, nor will the Backup Designated Router 3091 necessarily have the second highest Router Priority. If Router 3092 X is not itself eligible to become Designated Router, it is 3093 possible that neither a Backup Designated Router nor a 3094 Designated Router will be selected in the above procedure. Note 3095 also that if Router X is the only attached router that is 3096 eligible to become Designated Router, it will select itself as 3097 Designated Router and there will be no Backup Designated Router 3098 for the network. 3100 9.5. Sending Hello packets 3102 Hello packets are sent out each functioning router interface. 3103 They are used to discover and maintain neighbor 3104 relationships.[6] On broadcast and NBMA networks, Hello Packets 3105 are also used to elect the Designated Router and Backup 3106 Designated Router. 3108 The format of an Hello packet is detailed in Section A.3.2. The 3109 Hello Packet contains the router's Router Priority (used in 3110 choosing the Designated Router), and the interval between Hello 3111 Packets sent out the interface (HelloInterval). The Hello 3112 Packet also indicates how often a neighbor must be heard from to 3113 remain active (RouterDeadInterval). Both HelloInterval and 3114 RouterDeadInterval must be the same for all routers attached to 3115 a common network. The Hello packet also contains the IP address 3116 mask of the attached network (Network Mask). On unnumbered 3117 point-to-point networks and on virtual links this field should 3118 be set to 0.0.0.0. 3120 The Hello packet's Options field describes the router's optional 3121 OSPF capabilities. Two optional capabilities are defined in 3122 this specification (see Sections 4.5 and A.2). The T-bit of the 3123 Options field should be set if the router is capable of 3124 calculating separate routes for each IP TOS. The E-bit should 3125 be set if and only if the attached area is capable of processing 3126 AS-external-LSAs (i.e., it is not a stub area). If the E-bit is 3127 set incorrectly the neighboring routers will refuse to accept 3128 the Hello Packet (see Section 10.5). Unrecognized bits in the 3129 Hello Packet's Options field should be set to zero. 3131 In order to ensure two-way communication between adjacent 3132 routers, the Hello packet contains the list of all routers on 3133 the network from which Hello Packets have been seen recently. 3134 The Hello packet also contains the router's current choice for 3135 Designated Router and Backup Designated Router. A value of 3136 0.0.0.0 in these fields means that one has not yet been 3137 selected. 3139 On broadcast networks and physical point-to-point networks, 3140 Hello packets are sent every HelloInterval seconds to the IP 3141 multicast address AllSPFRouters. On virtual links, Hello 3142 packets are sent as unicasts (addressed directly to the other 3143 end of the virtual link) every HelloInterval seconds. On Point- 3144 to-MultiPoint networks, separate Hello packets are sent to each 3145 attached neighbor every HelloInterval seconds. Sending of Hello 3146 packets on NBMA networks is covered in the next section. 3148 9.5.1. Sending Hello packets on NBMA networks 3150 Static configuration information may be necessary in order 3151 for the Hello Protocol to function on non-broadcast networks 3152 (see Sections C.5 and C.6). On NBMA networks, every 3153 attached router which is eligible to become Designated 3154 Router becomes aware of all of its neighbors on the network 3155 (either through configuration or by some unspecified 3156 mechanism). Each neighbor is labelled with the neighbor's 3157 Designated Router eligibility. 3159 The interface state must be at least Waiting for any Hello 3160 Packets to be sent out the NBMA interface. Hello Packets 3161 are then sent directly (as unicasts) to some subset of a 3162 router's neighbors. Sometimes an Hello Packet is sent 3163 periodically on a timer; at other times it is sent as a 3164 response to a received Hello Packet. A router's hello- 3165 sending behavior varies depending on whether the router 3166 itself is eligible to become Designated Router. 3168 If the router is eligible to become Designated Router, it 3169 must periodically send Hello Packets to all neighbors that 3170 are also eligible. In addition, if the router is itself the 3171 Designated Router or Backup Designated Router, it must also 3172 send periodic Hello Packets to all other neighbors. This 3173 means that any two eligible routers are always exchanging 3174 Hello Packets, which is necessary for the correct operation 3175 of the Designated Router election algorithm. To minimize 3176 the number of Hello Packets sent, the number of eligible 3177 routers on an NBMA network should be kept small. 3179 If the router is not eligible to become Designated Router, 3180 it must periodically send Hello Packets to both the 3181 Designated Router and the Backup Designated Router (if they 3182 exist). It must also send an Hello Packet in reply to an 3183 Hello Packet received from any eligible neighbor (other than 3184 the current Designated Router and Backup Designated Router). 3185 This is needed to establish an initial bidirectional 3186 relationship with any potential Designated Router. 3188 When sending Hello packets periodically to any neighbor, the 3189 interval between Hello Packets is determined by the 3190 neighbor's state. If the neighbor is in state Down, Hello 3191 Packets are sent every PollInterval seconds. Otherwise, 3192 Hello Packets are sent every HelloInterval seconds. 3194 10. The Neighbor Data Structure 3196 An OSPF router converses with its neighboring routers. Each 3197 separate conversation is described by a "neighbor data structure". 3198 Each conversation is bound to a particular OSPF router interface, 3199 and is identified either by the neighboring router's OSPF Router ID 3200 or by its Neighbor IP address (see below). Thus if the OSPF router 3201 and another router have multiple attached networks in common, 3202 multiple conversations ensue, each described by a unique neighbor 3203 data structure. Each separate conversation is loosely referred to 3204 in the text as being a separate "neighbor". 3206 The neighbor data structure contains all information pertinent to 3207 the forming or formed adjacency between the two neighbors. 3208 (However, remember that not all neighbors become adjacent.) An 3209 adjacency can be viewed as a highly developed conversation between 3210 two routers. 3212 State 3213 The functional level of the neighbor conversation. This is 3214 described in more detail in Section 10.1. 3216 Inactivity Timer 3217 A single shot timer whose firing indicates that no Hello Packet 3218 has been seen from this neighbor recently. The length of the 3219 timer is RouterDeadInterval seconds. 3221 Master/Slave 3222 When the two neighbors are exchanging databases, they form a 3223 master/slave relationship. The master sends the first Database 3224 Description Packet, and is the only part that is allowed to 3225 retransmit. The slave can only respond to the master's Database 3226 Description Packets. The master/slave relationship is 3227 negotiated in state ExStart. 3229 DD Sequence Number 3230 A 32-bit number identifying individual Database Description 3231 packets. When the neighbor state ExStart is entered, the DD 3232 sequence number should be set to a value not previously seen by 3233 the neighboring router. One possible scheme is to use the 3234 machine's time of day counter. The DD sequence number is then 3235 incremented by the master with each new Database Description 3236 packet sent. The slave's DD sequence number indicates the last 3237 packet received from the master. Only one packet is allowed 3238 outstanding at a time. 3240 Neighbor ID 3241 The OSPF Router ID of the neighboring router. The Neighbor ID 3242 is learned when Hello packets are received from the neighbor, or 3243 is configured if this is a virtual adjacency (see Section C.4). 3245 Neighbor Priority 3246 The Router Priority of the neighboring router. Contained in the 3247 neighbor's Hello packets, this item is used when selecting the 3248 Designated Router for the attached network. 3250 Neighbor IP address 3251 The IP address of the neighboring router's interface to the 3252 attached network. Used as the Destination IP address when 3253 protocol packets are sent as unicasts along this adjacency. 3254 Also used in router-LSAs as the Link ID for the attached network 3255 if the neighboring router is selected to be Designated Router 3256 (see Section 12.4.1). The Neighbor IP address is learned when 3257 Hello packets are received from the neighbor. For virtual 3258 links, the Neighbor IP address is learned during the routing 3259 table build process (see Section 15). 3261 Neighbor Options 3262 The optional OSPF capabilities supported by the neighbor. 3263 Learned during the Database Exchange process (see Section 10.6). 3264 The neighbor's optional OSPF capabilities are also listed in its 3265 Hello packets. This enables received Hello Packets to be 3266 rejected (i.e., neighbor relationships will not even start to 3267 form) if there is a mismatch in certain crucial OSPF 3268 capabilities (see Section 10.5). The optional OSPF capabilities 3269 are documented in Section 4.5. 3271 Neighbor's Designated Router 3272 The neighbor's idea of the Designated Router. If this is the 3273 neighbor itself, this is important in the local calculation of 3274 the Designated Router. Defined only on broadcast and NBMA 3275 networks. 3277 Neighbor's Backup Designated Router 3278 The neighbor's idea of the Backup Designated Router. If this is 3279 the neighbor itself, this is important in the local calculation 3280 of the Backup Designated Router. Defined only on broadcast and 3281 NBMA networks. 3283 The next set of variables are lists of LSAs. These lists describe 3284 subsets of the area link-state database. This memo defines five 3285 distinct types of LSAs, all of which may be present in an area 3286 link-state database: router-LSAs, network-LSAs, and Type 3 and 4 3287 summary-LSAs (all stored in the area data structure), and AS- 3288 external-LSAs (stored in the global data structure). 3290 Link state retransmission list 3291 The list of LSAs that have been flooded but not acknowledged on 3292 this adjacency. These will be retransmitted at intervals until 3293 they are acknowledged, or until the adjacency is destroyed. 3295 Database summary list 3296 The complete list of LSAs that make up the area link-state 3297 database, at the moment the neighbor goes into Database Exchange 3298 state. This list is sent to the neighbor in Database 3299 Description packets. 3301 Link state request list 3302 The list of LSAs that need to be received from this neighbor in 3303 order to synchronize the two neighbors' link-state databases. 3304 This list is created as Database Description packets are 3305 received, and is then sent to the neighbor in Link State Request 3306 packets. The list is depleted as appropriate Link State Update 3307 packets are received. 3309 10.1. Neighbor states 3311 The state of a neighbor (really, the state of a conversation 3312 being held with a neighboring router) is documented in the 3313 following sections. The states are listed in order of 3314 progressing functionality. For example, the inoperative state 3315 is listed first, followed by a list of intermediate states 3316 before the final, fully functional state is achieved. The 3317 specification makes use of this ordering by sometimes making 3318 references such as "those neighbors/adjacencies in state greater 3319 than X". Figures 12 and 13 show the graph of neighbor state 3320 changes. The arcs of the graphs are labelled with the event 3321 causing the state change. The neighbor events are documented in 3322 Section 10.2. 3324 The graph in Figure 12 shows the state changes effected by the 3325 Hello Protocol. The Hello Protocol is responsible for neighbor 3326 acquisition and maintenance, and for ensuring two way 3327 communication between neighbors. 3329 The graph in Figure 13 shows the forming of an adjacency. Not 3330 every two neighboring routers become adjacent (see Section 3331 10.4). The adjacency starts to form when the neighbor is in 3332 state ExStart. After the two routers discover their 3333 master/slave status, the state transitions to Exchange. At this 3334 point the neighbor starts to be used in the flooding procedure, 3335 and the two neighboring routers begin synchronizing their 3336 databases. When this synchronization is finished, the neighbor 3337 is in state Full and we say that the two routers are fully 3338 adjacent. At this point the adjacency is listed in LSAs. 3340 For a more detailed description of neighbor state changes, 3342 +----+ 3343 |Down| 3344 +----+ 3345 |\ 3346 | \Start 3347 | \ +-------+ 3348 Hello | +---->|Attempt| 3349 Received | +-------+ 3350 | | 3351 +----+<-+ |HelloReceived 3352 |Init|<---------------+ 3353 +----+<--------+ 3354 | | 3355 |2-Way |1-Way 3356 |Received |Received 3357 | | 3358 +-------+ | +-----+ 3359 |ExStart|<--------+------->|2-Way| 3360 +-------+ +-----+ 3362 Figure 12: Neighbor state changes (Hello Protocol) 3364 In addition to the state transitions pictured, 3365 Event KillNbr always forces Down State, 3366 Event InactivityTimer always forces Down State, 3367 Event LLDown always forces Down State 3368 +-------+ 3369 |ExStart| 3370 +-------+ 3371 | 3372 NegotiationDone| 3373 +->+--------+ 3374 |Exchange| 3375 +--+--------+ 3376 | 3377 Exchange| 3378 Done | 3379 +----+ | +-------+ 3380 |Full|<---------+----->|Loading| 3381 +----+<-+ +-------+ 3382 | LoadingDone | 3383 +------------------+ 3385 Figure 13: Neighbor state changes (Database Exchange) 3387 In addition to the state transitions pictured, 3388 Event SeqNumberMismatch forces ExStart state, 3389 Event BadLSReq forces ExStart state, 3390 Event 1-Way forces Init state, 3391 Event KillNbr always forces Down State, 3392 Event InactivityTimer always forces Down State, 3393 Event LLDown always forces Down State, 3394 Event AdjOK? leads to adjacency forming/breaking 3396 together with the additional actions involved in each change, 3397 see Section 10.3. 3399 Down 3400 This is the initial state of a neighbor conversation. It 3401 indicates that there has been no recent information received 3402 from the neighbor. On NBMA networks, Hello packets may 3403 still be sent to "Down" neighbors, although at a reduced 3404 frequency (see Section 9.5.1). 3406 Attempt 3407 This state is only valid for neighbors attached to NBMA 3408 networks. It indicates that no recent information has been 3409 received from the neighbor, but that a more concerted effort 3410 should be made to contact the neighbor. This is done by 3411 sending the neighbor Hello packets at intervals of 3412 HelloInterval (see Section 9.5.1). 3414 Init 3415 In this state, an Hello packet has recently been seen from 3416 the neighbor. However, bidirectional communication has not 3417 yet been established with the neighbor (i.e., the router 3418 itself did not appear in the neighbor's Hello packet). All 3419 neighbors in this state (or higher) are listed in the Hello 3420 packets sent from the associated interface. 3422 2-Way 3423 In this state, communication between the two routers is 3424 bidirectional. This has been assured by the operation of 3425 the Hello Protocol. This is the most advanced state short 3426 of beginning adjacency establishment. The (Backup) 3427 Designated Router is selected from the set of neighbors in 3428 state 2-Way or greater. 3430 ExStart 3431 This is the first step in creating an adjacency between the 3432 two neighboring routers. The goal of this step is to decide 3433 which router is the master, and to decide upon the initial 3434 DD sequence number. Neighbor conversations in this state or 3435 greater are called adjacencies. 3437 Exchange 3438 In this state the router is describing its entire link state 3439 database by sending Database Description packets to the 3440 neighbor. Each Database Description Packet has a DD 3441 sequence number, and is explicitly acknowledged. Only one 3442 Database Description Packet is allowed outstanding at any 3443 one time. In this state, Link State Request Packets may 3444 also be sent asking for the neighbor's more recent LSAs. 3445 All adjacencies in Exchange state or greater are used by the 3446 flooding procedure. In fact, these adjacencies are fully 3447 capable of transmitting and receiving all types of OSPF 3448 routing protocol packets. 3450 Loading 3451 In this state, Link State Request packets are sent to the 3452 neighbor asking for the more recent LSAs that have been 3453 discovered (but not yet received) in the Exchange state. 3455 Full 3456 In this state, the neighboring routers are fully adjacent. 3457 These adjacencies will now appear in router-LSAs and 3458 network-LSAs. 3460 10.2. Events causing neighbor state changes 3462 State changes can be effected by a number of events. These 3463 events are shown in the labels of the arcs in Figures 12 and 13. 3464 The label definitions are as follows: 3466 HelloReceived 3467 An Hello packet has been received from the neighbor. 3469 Start 3470 This is an indication that Hello Packets should now be sent 3471 to the neighbor at intervals of HelloInterval seconds. This 3472 event is generated only for neighbors associated with NBMA 3473 networks. 3475 2-WayReceived 3476 Bidirectional communication has been realized between the 3477 two neighboring routers. This is indicated by the router 3478 seeing itself in the neighbor's Hello packet. 3480 NegotiationDone 3481 The Master/Slave relationship has been negotiated, and DD 3482 sequence numbers have been exchanged. This signals the 3483 start of the sending/receiving of Database Description 3484 packets. For more information on the generation of this 3485 event, consult Section 10.8. 3487 ExchangeDone 3488 Both routers have successfully transmitted a full sequence 3489 of Database Description packets. Each router now knows what 3490 parts of its link state database are out of date. For more 3491 information on the generation of this event, consult Section 3492 10.8. 3494 BadLSReq 3495 A Link State Request has been received for an LSA not 3496 contained in the database. This indicates an error in the 3497 Database Exchange process. 3499 Loading Done 3500 Link State Updates have been received for all out-of-date 3501 portions of the database. This is indicated by the Link 3502 state request list becoming empty after the Database 3503 Exchange process has completed. 3505 AdjOK? 3506 A decision must be made as to whether an adjacency should be 3507 established/maintained with the neighbor. This event will 3508 start some adjacencies forming, and destroy others. 3510 The following events cause well developed neighbors to revert to 3511 lesser states. Unlike the above events, these events may occur 3512 when the neighbor conversation is in any of a number of states. 3514 SeqNumberMismatch 3515 A Database Description packet has been received that either 3516 a) has an unexpected DD sequence number, b) unexpectedly has 3517 the Init bit set or c) has an Options field differing from 3518 the last Options field received in a Database Description 3519 packet. Any of these conditions indicate that some error 3520 has occurred during adjacency establishment. 3522 1-Way 3523 An Hello packet has been received from the neighbor, in 3524 which the router is not mentioned. This indicates that 3525 communication with the neighbor is not bidirectional. 3527 KillNbr 3528 This is an indication that all communication with the 3529 neighbor is now impossible, forcing the neighbor to 3530 revert to Down state. 3532 InactivityTimer 3533 The inactivity Timer has fired. This means that no Hello 3534 packets have been seen recently from the neighbor. The 3535 neighbor reverts to Down state. 3537 LLDown 3538 This is an indication from the lower level protocols that 3539 the neighbor is now unreachable. For example, on an X.25 3540 network this could be indicated by an X.25 clear indication 3541 with appropriate cause and diagnostic fields. This event 3542 forces the neighbor into Down state. 3544 10.3. The Neighbor state machine 3546 A detailed description of the neighbor state changes follows. 3547 Each state change is invoked by an event (Section 10.2). This 3548 event may produce different effects, depending on the current 3549 state of the neighbor. For this reason, the state machine below 3550 is organized by current neighbor state and received event. Each 3551 entry in the state machine describes the resulting new neighbor 3552 state and the required set of additional actions. 3554 When a neighbor's state changes, it may be necessary to rerun 3555 the Designated Router election algorithm. This is determined by 3556 whether the interface NeighborChange event is generated (see 3557 Section 9.2). Also, if the Interface is in DR state (the router 3558 is itself Designated Router), changes in neighbor state may 3559 cause a new network-LSA to be originated (see Section 12.4). 3561 When the neighbor state machine needs to invoke the interface 3562 state machine, it should be done as a scheduled task (see 3563 Section 4.4). This simplifies things, by ensuring that neither 3564 state machine will be executed recursively. 3566 State(s): Down 3568 Event: Start 3570 New state: Attempt 3572 Action: Send an Hello Packet to the neighbor (this neighbor 3573 is always associated with an NBMA network) and start 3574 the Inactivity Timer for the neighbor. The timer's 3575 later firing would indicate that communication with 3576 the neighbor was not attained. 3578 State(s): Attempt 3580 Event: HelloReceived 3582 New state: Init 3584 Action: Restart the Inactivity Timer for the neighbor, since 3585 the neighbor has now been heard from. 3587 State(s): Down 3589 Event: HelloReceived 3591 New state: Init 3593 Action: Start the Inactivity Timer for the neighbor. The 3594 timer's later firing would indicate that the 3595 neighbor is dead. 3597 State(s): Init or greater 3599 Event: HelloReceived 3601 New state: No state change. 3603 Action: Restart the Inactivity Timer for the neighbor, since 3604 the neighbor has again been heard from. 3606 State(s): Init 3608 Event: 2-WayReceived 3610 New state: Depends upon action routine. 3612 Action: Determine whether an adjacency should be established 3613 with the neighbor (see Section 10.4). If not, the 3614 new neighbor state is 2-Way. 3616 Otherwise (an adjacency should be established) the 3617 neighbor state transitions to ExStart. Upon 3618 entering this state, the router increments the DD 3619 sequence number for this neighbor. If this is the 3620 first time that an adjacency has been attempted, the 3621 DD sequence number should be assigned some unique 3622 value (like the time of day clock). It then 3623 declares itself master (sets the master/slave bit to 3624 master), and starts sending Database Description 3625 Packets, with the initialize (I), more (M) and 3626 master (MS) bits set. This Database Description 3627 Packet should be otherwise empty. This Database 3628 Description Packet should be retransmitted at 3629 intervals of RxmtInterval until the next state is 3630 entered (see Section 10.8). 3632 State(s): ExStart 3634 Event: NegotiationDone 3636 New state: Exchange 3638 Action: The router must list the contents of its entire area 3639 link state database in the neighbor Database summary 3640 list. The area link state database consists of the 3641 router-LSAs, network-LSAs and summary-LSAs contained 3642 in the area structure, along with the AS-external- 3643 LSAs contained in the global structure. AS- 3644 external-LSAs are omitted from a virtual neighbor's 3645 Database summary list. AS-external-LSAs are omitted 3646 from the Database summary list if the area has been 3647 configured as a stub (see Section 3.6). LSAs whose 3648 age is equal to MaxAge are instead added to the 3649 neighbor's Link state retransmission list. A 3650 summary of the Database summary list will be sent to 3651 the neighbor in Database Description packets. Each 3652 Database Description Packet has a DD sequence 3653 number, and is explicitly acknowledged. Only one 3654 Database Description Packet is allowed outstanding 3655 at any one time. For more detail on the sending and 3656 receiving of Database Description packets, see 3657 Sections 10.8 and 10.6. 3659 State(s): Exchange 3661 Event: ExchangeDone 3663 New state: Depends upon action routine. 3665 Action: If the neighbor Link state request list is empty, 3666 the new neighbor state is Full. No other action is 3667 required. This is an adjacency's final state. 3669 Otherwise, the new neighbor state is Loading. Start 3670 (or continue) sending Link State Request packets to 3671 the neighbor (see Section 10.9). These are requests 3672 for the neighbor's more recent LSAs (which were 3673 discovered but not yet received in the Exchange 3674 state). These LSAs are listed in the Link state 3675 request list associated with the neighbor. 3677 State(s): Loading 3679 Event: Loading Done 3681 New state: Full 3683 Action: No action required. This is an adjacency's final 3684 state. 3686 State(s): 2-Way 3687 Event: AdjOK? 3689 New state: Depends upon action routine. 3691 Action: Determine whether an adjacency should be formed with 3692 the neighboring router (see Section 10.4). If not, 3693 the neighbor state remains at 2-Way. Otherwise, 3694 transition the neighbor state to ExStart and perform 3695 the actions associated with the above state machine 3696 entry for state Init and event 2-WayReceived. 3698 State(s): ExStart or greater 3700 Event: AdjOK? 3702 New state: Depends upon action routine. 3704 Action: Determine whether the neighboring router should 3705 still be adjacent. If yes, there is no state change 3706 and no further action is necessary. 3708 Otherwise, the (possibly partially formed) adjacency 3709 must be destroyed. The neighbor state transitions 3710 to 2-Way. The Link state retransmission list, 3711 Database summary list and Link state request list 3712 are cleared of LSAs. 3714 State(s): Exchange or greater 3716 Event: SeqNumberMismatch 3718 New state: ExStart 3720 Action: The (possibly partially formed) adjacency is torn 3721 down, and then an attempt is made at 3722 reestablishment. The neighbor state first 3723 transitions to ExStart. The Link state 3724 retransmission list, Database summary list and Link 3725 state request list are cleared of LSAs. Then the 3726 router increments the DD sequence number for this 3727 neighbor, declares itself master (sets the 3728 master/slave bit to master), and starts sending 3729 Database Description Packets, with the initialize 3730 (I), more (M) and master (MS) bits set. This 3731 Database Description Packet should be otherwise 3732 empty (see Section 10.8). 3734 State(s): Exchange or greater 3736 Event: BadLSReq 3738 New state: ExStart 3740 Action: The action for event BadLSReq is exactly the same as 3741 for the neighbor event SeqNumberMismatch. The 3742 (possibly partially formed) adjacency is torn down, 3743 and then an attempt is made at reestablishment. For 3744 more information, see the neighbor state machine 3745 entry that is invoked when event SeqNumberMismatch 3746 is generated in state Exchange or greater. 3748 State(s): Any state 3750 Event: KillNbr 3752 New state: Down 3754 Action: The Link state retransmission list, Database summary 3755 list and Link state request list are cleared of 3756 LSAs. Also, the Inactivity Timer is disabled. 3758 State(s): Any state 3760 Event: LLDown 3762 New state: Down 3764 Action: The Link state retransmission list, Database summary 3765 list and Link state request list are cleared of 3766 LSAs. Also, the Inactivity Timer is disabled. 3768 State(s): Any state 3770 Event: InactivityTimer 3772 New state: Down 3774 Action: The Link state retransmission list, Database summary 3775 list and Link state request list are cleared of 3776 LSAs. 3778 State(s): 2-Way or greater 3780 Event: 1-WayReceived 3782 New state: Init 3784 Action: The Link state retransmission list, Database summary 3785 list and Link state request list are cleared of 3786 LSAs. 3788 State(s): 2-Way or greater 3790 Event: 2-WayReceived 3792 New state: No state change. 3794 Action: No action required. 3796 State(s): Init 3798 Event: 1-WayReceived 3800 New state: No state change. 3802 Action: No action required. 3804 10.4. Whether to become adjacent 3806 Adjacencies are established with some subset of the router's 3807 neighbors. Routers connected by point-to-point networks, 3808 Point-to-MultiPoint networks and virtual links always become 3809 adjacent. On broadcast and NBMA networks, all routers become 3810 adjacent to both the Designated Router and the Backup Designated 3811 Router. 3813 The adjacency-forming decision occurs in two places in the 3814 neighbor state machine. First, when bidirectional communication 3815 is initially established with the neighbor, and secondly, when 3816 the identity of the attached network's (Backup) Designated 3817 Router changes. If the decision is made to not attempt an 3818 adjacency, the state of the neighbor communication stops at 2- 3819 Way. 3821 An adjacency should be established with a bidirectional neighbor 3822 when at least one of the following conditions holds: 3824 o The underlying network type is point-to-point 3826 o The underlying network type is Point-to-MultiPoint 3828 o The underlying network type is virtual link 3830 o The router itself is the Designated Router 3832 o The router itself is the Backup Designated Router 3834 o The neighboring router is the Designated Router 3836 o The neighboring router is the Backup Designated Router 3838 10.5. Receiving Hello Packets 3840 This section explains the detailed processing of a received 3841 Hello Packet. (See Section A.3.2 for the format of Hello 3842 packets.) The generic input processing of OSPF packets will 3843 have checked the validity of the IP header and the OSPF packet 3844 header. Next, the values of the Network Mask, HelloInterval, 3845 and RouterDeadInterval fields in the received Hello packet must 3846 be checked against the values configured for the receiving 3847 interface. Any mismatch causes processing to stop and the 3848 packet to be dropped. In other words, the above fields are 3849 really describing the attached network's configuration. However, 3850 there is one exception to the above rule: on point-to-point 3851 networks and on virtual links, the Network Mask in the received 3852 Hello Packet should be ignored. 3854 The receiving interface attaches to a single OSPF area (this 3855 could be the backbone). The setting of the E-bit found in the 3856 Hello Packet's Options field must match this area's 3857 ExternalRoutingCapability. If AS-external-LSAs are not flooded 3858 into/throughout the area (i.e, the area is a "stub") the E-bit 3859 must be clear in received Hello Packets, otherwise the E-bit 3860 must be set. A mismatch causes processing to stop and the 3861 packet to be dropped. The setting of the rest of the bits in 3862 the Hello Packet's Options field should be ignored. 3864 At this point, an attempt is made to match the source of the 3865 Hello Packet to one of the receiving interface's neighbors. If 3866 the receiving interface connects to a broadcast, Point-to- 3867 MultiPoint or NBMA network the source is identified by the IP 3868 source address found in the Hello's IP header. If the receiving 3869 interface connects to a point-to-point link or a virtual link, 3870 the source is identified by the Router ID found in the Hello's 3871 OSPF packet header. The interface's current list of neighbors 3872 is contained in the interface's data structure. If a matching 3873 neighbor structure cannot be found, (i.e., this is the first 3874 time the neighbor has been detected), one is created. The 3875 initial state of a newly created neighbor is set to Down. 3877 When receiving an Hello Packet from a neighbor on a broadcast, 3878 Point-to-MultiPoint or NBMA network, set the neighbor 3879 structure's Neighbor ID equal to the Router ID found in the 3880 packet's OSPF header. When receiving an Hello on a point-to- 3881 point network (but not on a virtual link) set the neighbor 3882 structure's Neighbor IP address to the packet's IP source 3883 address. 3885 Now the rest of the Hello Packet is examined, generating events 3886 to be given to the neighbor and interface state machines. These 3887 state machines are specified either to be executed or scheduled 3888 (see Section 4.4). For example, by specifying below that the 3889 neighbor state machine be executed in line, several neighbor 3890 state transitions may be effected by a single received Hello: 3892 o Each Hello Packet causes the neighbor state machine to be 3893 executed with the event HelloReceived. 3895 o Then the list of neighbors contained in the Hello Packet is 3896 examined. If the router itself appears in this list, the 3897 neighbor state machine should be executed with the event 2- 3898 WayReceived. Otherwise, the neighbor state machine should 3899 be executed with the event 1-WayReceived, and the processing 3900 of the packet stops. 3902 o Next, the Hello Packet's Router Priority field is examined. 3903 If this field is different than the one previously received 3904 from the neighbor, the receiving interface's state machine 3905 is scheduled with the event NeighborChange. In any case, 3906 the Router Priority field in the neighbor data structure 3907 should be updated accordingly. 3909 o Next the Designated Router field in the Hello Packet is 3910 examined. If the neighbor is both declaring itself to be 3911 Designated Router (Designated Router field = Neighbor IP 3912 address) and the Backup Designated Router field in the 3913 packet is equal to 0.0.0.0 and the receiving interface is in 3914 state Waiting, the receiving interface's state machine is 3915 scheduled with the event BackupSeen. Otherwise, if the 3916 neighbor is declaring itself to be Designated Router and it 3917 had not previously, or the neighbor is not declaring itself 3918 Designated Router where it had previously, the receiving 3919 interface's state machine is scheduled with the event 3920 NeighborChange. In any case, the Neighbors' Designated 3921 Router item in the neighbor structure is updated 3922 accordingly. 3924 o Finally, the Backup Designated Router field in the Hello 3925 Packet is examined. If the neighbor is declaring itself to 3926 be Backup Designated Router (Backup Designated Router field 3927 = Neighbor IP address) and the receiving interface is in 3928 state Waiting, the receiving interface's state machine is 3929 scheduled with the event BackupSeen. Otherwise, if the 3930 neighbor is declaring itself to be Backup Designated Router 3931 and it had not previously, or the neighbor is not declaring 3932 itself Backup Designated Router where it had previously, the 3933 receiving interface's state machine is scheduled with the 3934 event NeighborChange. In any case, the Neighbor's Backup 3935 Designated Router item in the neighbor structure is updated 3936 accordingly. 3938 On NBMA networks, receipt of an Hello Packet may also cause an 3939 Hello Packet to be sent back to the neighbor in response. See 3940 Section 9.5.1 for more details. 3942 10.6. Receiving Database Description Packets 3944 This section explains the detailed processing of a received 3945 Database Description Packet. The incoming Database Description 3946 Packet has already been associated with a neighbor and receiving 3947 interface by the generic input packet processing (Section 8.2). 3948 The further processing of the Database Description Packet 3949 depends on the neighbor state. If the neighbor's state is Down 3950 or Attempt the packet should be ignored. Otherwise, if the 3951 state is: 3953 Init 3954 The neighbor state machine should be executed with the event 3955 2-WayReceived. This causes an immediate state change to 3956 either state 2-Way or state ExStart. If the new state is 3957 ExStart, the processing of the current packet should then 3958 continue in this new state by falling through to case 3959 ExStart below. 3961 2-Way 3962 The packet should be ignored. Database Description Packets 3963 are used only for the purpose of bringing up adjacencies.[7] 3964 ExStart 3965 If the received packet matches one of the following cases, 3966 then the neighbor state machine should be executed with the 3967 event NegotiationDone (causing the state to transition to 3968 Exchange), the packet's Options field should be recorded in 3969 the neighbor structure's Neighbor Options field and the 3970 packet should be accepted as next in sequence and processed 3971 further (see below). Otherwise, the packet should be 3972 ignored. 3974 o The initialize(I), more (M) and master(MS) bits are set, 3975 the contents of the packet are empty, and the neighbor's 3976 Router ID is larger than the router's own. In this case 3977 the router is now Slave. Set the master/slave bit to 3978 slave, and set the DD sequence number to that specified 3979 by the master. 3981 o The initialize(I) and master(MS) bits are off, the 3982 packet's DD sequence number equals the router's own DD 3983 sequence number (indicating acknowledgment) and the 3984 neighbor's Router ID is smaller than the router's own. 3985 In this case the router is Master. 3987 Exchange 3988 If the state of the MS-bit is inconsistent with the 3989 master/slave state of the connection, generate the neighbor 3990 event SeqNumberMismatch and stop processing the packet. 3991 Otherwise: 3993 o If the initialize(I) bit is set, generate the neighbor 3994 event SeqNumberMismatch and stop processing the packet. 3996 o If the packet's Options field indicates a different set 3997 of optional OSPF capabilities than were previously 3998 received from the neighbor (recorded in the Neighbor 3999 Options field of the neighbor structure), generate the 4000 neighbor event SeqNumberMismatch and stop processing the 4001 packet. 4003 o If the router is master, and the packet's DD sequence 4004 number equals the router's own DD sequence number (this 4005 packet is the next in sequence) the packet should be 4006 accepted and its contents processed (below). 4008 o If the router is master, and the packet's DD sequence 4009 number is one less than the router's DD sequence number, 4010 the packet is a duplicate. Duplicates should be 4011 discarded by the master. 4013 o If the router is slave, and the packet's DD sequence 4014 number is one more than the router's own DD sequence 4015 number (this packet is the next in sequence) the packet 4016 should be accepted and its contents processed (below). 4018 o If the router is slave, and the packet's DD sequence 4019 number is equal to the router's DD sequence number, the 4020 packet is a duplicate. The slave must respond to 4021 duplicates by repeating the last Database Description 4022 packet that it had sent. 4024 o Else, generate the neighbor event SeqNumberMismatch and 4025 stop processing the packet. 4027 Loading or Full 4028 In this state, the router has sent and received an entire 4029 sequence of Database Description Packets. The only packets 4030 received should be duplicates (see above). In particular, 4031 the packet's Options field should match the set of optional 4032 OSPF capabilities previously indicated by the neighbor 4033 (stored in the neighbor structure's Neighbor Options field). 4034 Any other packets received, including the reception of a 4035 packet with the Initialize(I) bit set, should generate the 4036 neighbor event SeqNumberMismatch.[8] Duplicates should be 4037 discarded by the master. The slave must respond to 4038 duplicates by repeating the last Database Description packet 4039 that it had sent. 4041 When the router accepts a received Database Description Packet 4042 as the next in sequence the packet contents are processed as 4043 follows. For each LSA listed, the LSA's LS type is checked for 4044 validity. If the LS type is unknown (e.g., not one of the LS 4045 types 1-5 defined by this specification), or if this is an AS- 4046 external-LSA (LS type = 5) and the neighbor is associated with a 4047 stub area, generate the neighbor event SeqNumberMismatch and 4048 stop processing the packet. Otherwise, the router looks up the 4049 LSA in its database to see whether it also has an instance of 4050 the LSA. If it does not, or if the database copy is less recent 4051 (see Section 13.1), the LSA is put on the Link state request 4052 list so that it can be requested (immediately or at some later 4053 time) in Link State Request Packets. 4055 When the router accepts a received Database Description Packet 4056 as the next in sequence, it also performs the following actions, 4057 depending on whether it is master or slave: 4059 Master 4060 Increments the DD sequence number. If the router has 4061 already sent its entire sequence of Database Description 4062 Packets, and the just accepted packet has the more bit (M) 4063 set to 0, the neighbor event ExchangeDone is generated. 4064 Otherwise, it should send a new Database Description to the 4065 slave. 4067 Slave 4068 Sets the DD sequence number to the DD sequence number 4069 appearing in the received packet. The slave must send a 4070 Database Description Packet in reply. If the received 4071 packet has the more bit (M) set to 0, and the packet to be 4072 sent by the slave will also have the M-bit set to 0, the 4073 neighbor event ExchangeDone is generated. Note that the 4074 slave always generates this event before the master. 4076 10.7. Receiving Link State Request Packets 4078 This section explains the detailed processing of received Link 4079 State Request packets. Received Link State Request Packets 4080 specify a list of LSAs that the neighbor wishes to receive. 4081 Link State Request Packets should be accepted when the neighbor 4082 is in states Exchange, Loading, or Full. In all other states 4083 Link State Request Packets should be ignored. 4085 Each LSA specified in the Link State Request packet should be 4086 located in the router's database, and copied into Link State 4087 Update packets for transmission to the neighbor. These LSAs 4088 should NOT be placed on the Link state retransmission list for 4089 the neighbor. If an LSA cannot be found in the database, 4090 something has gone wrong with the Database Exchange process, and 4091 neighbor event BadLSReq should be generated. 4093 10.8. Sending Database Description Packets 4095 This section describes how Database Description Packets are sent 4096 to a neighbor. The router's optional OSPF capabilities (see 4097 Section 4.5) are transmitted to the neighbor in the Options 4098 field of the Database Description packet. The router should 4099 maintain the same set of optional capabilities throughout the 4100 Database Exchange and flooding procedures. If for some reason 4101 the router's optional capabilities change, the Database Exchange 4102 procedure should be restarted by reverting to neighbor state 4103 ExStart. There are currently two optional capabilities defined. 4104 The T-bit should be set if and only if the router is capable of 4105 calculating separate routes for each IP TOS. The E-bit should 4106 be set if and only if the attached network belongs to a non-stub 4107 area. The rest of the Options field should be set to zero. 4109 The sending of Database Description packets depends on the 4110 neighbor's state. In state ExStart the router sends empty 4111 Database Description packets, with the initialize (I), more (M) 4112 and master (MS) bits set. These packets are retransmitted every 4113 RxmtInterval seconds. 4115 In state Exchange the Database Description Packets actually 4116 contain summaries of the link state information contained in the 4117 router's database. Each LSA in the area's link-state database 4118 (at the time the neighbor transitions into Exchange state) is 4119 listed in the neighbor Database summary list. When a new 4120 Database Description Packet is to be sent, the packet's DD 4121 sequence number is incremented, and the (new) top of the 4122 Database summary list is described by the packet. Items are 4123 removed from the Database summary list when the previous packet 4124 is acknowledged. 4126 In state Exchange, the determination of when to send a Database 4127 Description packet depends on whether the router is master or 4128 slave: 4130 Master 4131 Database Description packets are sent when either a) the 4132 slave acknowledges the previous Database Description packet 4133 by echoing the DD sequence number or b) RxmtInterval seconds 4134 elapse without an acknowledgment, in which case the previous 4135 Database Description packet is retransmitted. 4137 Slave 4138 Database Description packets are sent only in response to 4139 Database Description packets received from the master. If 4140 the Database Description packet received from the master is 4141 new, a new Database Description packet is sent, otherwise 4142 the previous Database Description packet is resent. 4144 In states Loading and Full the slave must resend its last 4145 Database Description packet in response to duplicate Database 4146 Description packets received from the master. For this reason 4147 the slave must wait RouterDeadInterval seconds before freeing 4148 the last Database Description packet. Reception of a Database 4149 Description packet from the master after this interval will 4150 generate a SeqNumberMismatch neighbor event. 4152 10.9. Sending Link State Request Packets 4154 In neighbor states Exchange or Loading, the Link state request 4155 list contains a list of those LSAs that need to be obtained from 4156 the neighbor. To request these LSAs, a router sends the 4157 neighbor the beginning of the Link state request list, packaged 4158 in a Link State Request packet. 4160 When the neighbor responds to these requests with the proper 4161 Link State Update packet(s), the Link state request list is 4162 truncated and a new Link State Request packet is sent. This 4163 process continues until the Link state request list becomes 4164 empty. Unsatisfied Link State Request packets are retransmitted 4165 at intervals of RxmtInterval. There should be at most one Link 4166 State Request packet outstanding at any one time. 4168 When the Link state request list becomes empty, and the neighbor 4169 state is Loading (i.e., a complete sequence of Database 4170 Description packets has been sent to and received from the 4171 neighbor), the Loading Done neighbor event is generated. 4173 10.10. An Example 4175 Figure 14 shows an example of an adjacency forming. Routers RT1 4176 and RT2 are both connected to a broadcast network. It is 4177 assumed that RT2 is the Designated Router for the network, and 4178 that RT2 has a higher Router ID than Router RT1. 4180 The neighbor state changes realized by each router are listed on 4181 the sides of the figure. 4183 At the beginning of Figure 14, Router RT1's interface to the 4184 network becomes operational. It begins sending Hello Packets, 4185 although it doesn't know the identity of the Designated Router 4186 or of any other neighboring routers. Router RT2 hears this 4187 hello (moving the neighbor to Init state), and in its next Hello 4188 Packet indicates that it is itself the Designated Router and 4189 that it has heard Hello Packets from RT1. This in turn causes 4190 RT1 to go to state ExStart, as it starts to bring up the 4191 adjacency. 4193 RT1 begins by asserting itself as the master. When it sees that 4194 RT2 is indeed the master (because of RT2's higher Router ID), 4195 RT1 transitions to slave state and adopts its neighbor's DD 4196 sequence number. Database Description packets are then 4197 exchanged, with polls coming from the master (RT2) and responses 4198 from the slave (RT1). This sequence of Database Description 4199 +---+ +---+ 4200 |RT1| |RT2| 4201 +---+ +---+ 4203 Down Down 4204 Hello(DR=0,seen=0) 4205 ------------------------------> 4206 Hello (DR=RT2,seen=RT1,...) Init 4207 <------------------------------ 4208 ExStart D-D (Seq=x,I,M,Master) 4209 ------------------------------> 4210 D-D (Seq=y,I,M,Master) ExStart 4211 <------------------------------ 4212 Exchange D-D (Seq=y,M,Slave) 4213 ------------------------------> 4214 D-D (Seq=y+1,M,Master) Exchange 4215 <------------------------------ 4216 D-D (Seq=y+1,M,Slave) 4217 ------------------------------> 4218 ... 4219 ... 4220 ... 4221 D-D (Seq=y+n, Master) 4222 <------------------------------ 4223 D-D (Seq=y+n, Slave) 4224 Loading ------------------------------> 4225 LS Request Full 4226 ------------------------------> 4227 LS Update 4228 <------------------------------ 4229 LS Request 4230 ------------------------------> 4231 LS Update 4232 <------------------------------ 4233 Full 4235 Figure 14: An adjacency bring-up example 4236 Packets ends when both the poll and associated response has the 4237 M-bit off. 4239 In this example, it is assumed that RT2 has a completely up to 4240 date database. In that case, RT2 goes immediately into Full 4241 state. RT1 will go into Full state after updating the necessary 4242 parts of its database. This is done by sending Link State 4243 Request Packets, and receiving Link State Update Packets in 4244 response. Note that, while RT1 has waited until a complete set 4245 of Database Description Packets has been received (from RT2) 4246 before sending any Link State Request Packets, this need not be 4247 the case. RT1 could have interleaved the sending of Link State 4248 Request Packets with the reception of Database Description 4249 Packets. 4251 11. The Routing Table Structure 4253 The routing table data structure contains all the information 4254 necessary to forward an IP data packet toward its destination. Each 4255 routing table entry describes the collection of best paths to a 4256 particular destination. When forwarding an IP data packet, the 4257 routing table entry providing the best match for the packet's IP 4258 destination is located. The matching routing table entry then 4259 provides the next hop towards the packet's destination. OSPF also 4260 provides for the existence of a default route (Destination ID = 4261 DefaultDestination, Address Mask = 0x00000000). When the default 4262 route exists, it matches all IP destinations (although any other 4263 matching entry is a better match). Finding the routing table entry 4264 that best matches an IP destination is further described in Section 4265 11.1. 4267 There is a single routing table in each router. Two sample routing 4268 tables are described in Sections 11.2 and 11.3. The building of the 4269 routing table is discussed in Section 16. 4271 The rest of this section defines the fields found in a routing table 4272 entry. The first set of fields describes the routing table entry's 4273 destination. 4275 Destination Type 4276 Destination type is either "network" or "router". Only network 4277 entries are actually used when forwarding IP data traffic. 4278 Router routing table entries are used solely as intermediate 4279 steps in the routing table build process. 4281 A network is a range of IP addresses, to which IP data traffic 4282 may be forwarded. This includes IP networks (class A, B, or C), 4283 IP subnets, IP supernets and single IP hosts. The default route 4284 also falls into this category. 4286 Router entries are kept for area border routers and AS boundary 4287 routers. Routing table entries for area border routers are used 4288 when calculating the inter-area routes (see Section 16.2), and 4289 when maintaining configured virtual links (see Section 15). 4290 Routing table entries for AS boundary routers are used when 4291 calculating the AS external routes (see Section 16.4). 4293 Destination ID 4294 The destination's identifier or name. This depends on the 4295 Destination Type. For networks, the identifier is their 4296 associated IP address. For routers, the identifier is the OSPF 4297 Router ID.[9] 4299 Address Mask 4300 Only defined for networks. The network's IP address together 4301 with its address mask defines a range of IP addresses. For IP 4302 subnets, the address mask is referred to as the subnet mask. 4303 For host routes, the mask is "all ones" (0xffffffff). 4305 Optional Capabilities 4306 When the destination is a router this field indicates the 4307 optional OSPF capabilities supported by the destination router. 4308 The two optional capabilities currently defined by this 4309 specification are the ability to route based on IP TOS and the 4310 ability to process AS-external-LSAs. For a further discussion 4311 of OSPF's optional capabilities, see Section 4.5. 4313 The set of paths to use for a destination may vary based on IP Type 4314 of Service and the OSPF area to which the paths belong. This means 4315 that there may be multiple routing table entries for the same 4316 destination, depending on the values of the next two fields. 4318 Type of Service 4319 There can be a separate set of routes for each IP Type of 4320 Service. The encoding of TOS in OSPF LSAs is described in 4321 Section 12.3. 4323 Area 4324 This field indicates the area whose link state information has 4325 led to the routing table entry's collection of paths. This is 4326 called the entry's associated area. For sets of AS external 4327 paths, this field is not defined. For destinations of type 4328 "router", there may be separate sets of paths (and therefore 4329 separate routing table entries) associated with each of several 4330 areas. For example, this will happen when two area border 4331 routers share multiple areas in common. For destinations of 4332 type "network", only the set of paths associated with the best 4333 area (the one providing the preferred route) is kept. 4335 The rest of the routing table entry describes the set of paths to 4336 the destination. The following fields pertain to the set of paths 4337 as a whole. In other words, each one of the paths contained in a 4338 routing table entry is of the same path-type and cost (see below). 4340 Path-type 4341 There are four possible types of paths used to route traffic to 4342 the destination, listed here in order of preference: intra-area, 4343 inter-area, type 1 external or type 2 external. Intra-area 4344 paths indicate destinations belonging to one of the router's 4345 attached areas. Inter-area paths are paths to destinations in 4346 other OSPF areas. These are discovered through the examination 4347 of received summary-LSAs. AS external paths are paths to 4348 destinations external to the AS. These are detected through the 4349 examination of received AS-external-LSAs. 4351 Cost 4352 The link state cost of the path to the destination. For all 4353 paths except type 2 external paths this describes the entire 4354 path's cost. For Type 2 external paths, this field describes 4355 the cost of the portion of the path internal to the AS. This 4356 cost is calculated as the sum of the costs of the path's 4357 constituent links. 4359 Type 2 cost 4360 Only valid for type 2 external paths. For these paths, this 4361 field indicates the cost of the path's external portion. This 4362 cost has been advertised by an AS boundary router, and is the 4363 most significant part of the total path cost. For example, a 4364 type 2 external path with type 2 cost of 5 is always preferred 4365 over a path with type 2 cost of 10, regardless of the cost of 4366 the two paths' internal components. 4368 Link State Origin 4369 Valid only for intra-area paths, this field indicates the LSA 4370 (router-LSA or network-LSA) that directly references the 4371 destination. For example, if the destination is a transit 4372 network, this is the transit network's network-LSA. If the 4373 destination is a stub network, this is the router-LSA for the 4374 attached router. The LSA is discovered during the shortest-path 4375 tree calculation (see Section 16.1). Multiple LSAs may 4376 reference the destination, however a tie-breaking scheme always 4377 reduces the choice to a single LSA. The Link State Origin field 4378 is not used by the OSPF protocol, but it is used by the routing 4379 table calculation in OSPF's Multicast routing extensions 4380 (MOSPF). 4382 When multiple paths of equal path-type and cost exist to a 4383 destination (called elsewhere "equal-cost" paths), they are stored 4384 in a single routing table entry. Each one of the "equal-cost" paths 4385 is distinguished by the following fields: 4387 Next hop 4388 The outgoing router interface to use when forwarding traffic to 4389 the destination. On broadcast, Point-to-MultiPoint and NBMA 4390 networks, the next hop also includes the IP address of the next 4391 router (if any) in the path towards the destination. 4393 Advertising router 4394 Valid only for inter-area and AS external paths. This field 4395 indicates the Router ID of the router advertising the summary- 4396 LSA or AS-external-LSA that led to this path. 4398 11.1. Routing table lookup 4400 When an IP data packet is received, an OSPF router finds the 4401 routing table entry that best matches the packet's destination. 4402 This routing table entry then provides the outgoing interface 4403 and next hop router to use in forwarding the packet. This 4404 section describes the process of finding the best matching 4405 routing table entry. The process consists of a number of steps, 4406 wherein the collection of routing table entries is progressively 4407 pruned. In the end, the single routing table entry remaining is 4408 called the "best match". 4410 Before the lookup begins, "discard" routing table entries should 4411 be inserted into the routing table for each of the router's 4412 active area address ranges (see Section 3.5). (An area range is 4413 considered "active" if the range contains one or more networks 4414 reachable by intra-area paths.) The destination of a "discard" 4415 entry is the set of addresses described by its associated active 4416 area address range, and the path type of each "discard" entry is 4417 set to "inter-area".[10] 4418 Note that the steps described below may fail to produce a best 4419 match routing table entry (i.e., all existing routing table 4420 entries are pruned for some reason or another), or the best 4421 match routing table entry may be one of the above "discard" 4422 routing table entries. In these cases, the packet's IP 4423 destination is considered unreachable. Instead of being 4424 forwarded, the packet should be discarded and an ICMP 4425 destination unreachable message should be returned to the 4426 packet's source. 4428 (1) Select the complete set of "matching" routing table entries 4429 from the routing table. Each routing table entry describes 4430 a (set of) path(s) to a range of IP addresses. If the data 4431 packet's IP destination falls into an entry's range of IP 4432 addresses, the routing table entry is called a match. (It is 4433 quite likely that multiple entries will match the data 4434 packet. For example, a default route will match all 4435 packets.) 4437 (2) Reduce the set of matching entries to those having the most 4438 preferential path-type (see Section 11). OSPF has a four 4439 level hierarchy of paths. Intra-area paths are the most 4440 preferred, followed in order by inter-area, type 1 external 4441 and type 2 external paths. 4443 (3) Select the remaining routing table entry that provides the 4444 most specific (longest) match. Another way of saying this is 4445 to choose the remaining entry that specifies the narrowest 4446 range of IP addresses.[11] For example, the entry for the 4447 address/mask pair of (128.185.1.0, 0xffffff00) is more 4448 specific than an entry for the pair (128.185.0.0, 4449 0xffff0000). The default route is the least specific match, 4450 since it matches all destinations. 4452 (4) At this point, there may still be multiple routing table 4453 entries remaining. Each routing entry will specify the same 4454 range of IP addresses, but a different IP Type of Service. 4455 Select the routing table entry whose TOS value matches the 4456 TOS found in the packet header. If there is no routing table 4457 entry for this TOS, select the routing table entry for TOS 4458 0. In other words, packets requesting TOS X are routed along 4459 the TOS 0 path if a TOS X path does not exist. 4461 11.2. Sample routing table, without areas 4463 Consider the Autonomous System pictured in Figure 2. No OSPF 4464 areas have been configured. A single metric is shown per 4465 outbound interface, indicating that routes will not vary based 4466 on TOS. The calculation of Router RT6's routing table proceeds 4467 as described in Section 2.2. The resulting routing table is 4468 shown in Table 12. Destination types are abbreviated: Network 4469 as "N", Router as "R". 4471 There are no instances of multiple equal-cost shortest paths in 4472 this example. Also, since there are no areas, there are no 4473 inter-area paths. 4475 Routers RT5 and RT7 are AS boundary routers. Intra-area routes 4476 have been calculated to Routers RT5 and RT7. This allows 4477 external routes to be calculated to the destinations advertised 4478 by RT5 and RT7 (i.e., Networks N12, N13, N14 and N15). It is 4479 assumed all AS-external-LSAs originated by RT5 and RT7 are 4480 advertising type 1 external metrics. This results in type 1 4481 external paths being calculated to destinations N12-N15. 4483 11.3. Sample routing table, with areas 4485 Consider the previous example, this time split into OSPF areas. 4486 An OSPF area configuration is pictured in Figure 6. Router 4487 RT4's routing table will be described for this area 4488 configuration. Router RT4 has a connection to Area 1 and a 4489 backbone connection. This causes Router RT4 to view the AS as 4490 the concatenation of the two graphs shown in Figures 7 and 8. 4491 The resulting routing table is displayed in Table 13. 4493 Again, Routers RT5 and RT7 are AS boundary routers. Routers 4494 RT3, RT4, RT7, RT10 and RT11 are area border routers. Note that 4495 there are two routing entries for the area border router RT3, 4496 since it has two areas in common with RT4 (Area 1 and the 4497 backbone). 4499 Backbone paths have been calculated to all area border routers. 4500 These are used when determining the inter-area routes. Note 4501 that all of the inter-area routes are associated with the 4502 backbone; this is always the case when the calculating router is 4503 itself an area border router. Routing information is condensed 4504 at area boundaries. In this example, we assume that Area 3 has 4505 been defined so that networks N9-N11 and the host route to H1 4506 are all condensed to a single route when advertised into the 4507 Type Dest Area Path Type Cost Next Adv. 4508 Hop(s) Router(s) 4509 ____________________________________________________________ 4510 N N1 0 intra-area 10 RT3 * 4511 N N2 0 intra-area 10 RT3 * 4512 N N3 0 intra-area 7 RT3 * 4513 N N4 0 intra-area 8 RT3 * 4514 N Ib 0 intra-area 7 * * 4515 N Ia 0 intra-area 12 RT10 * 4516 N N6 0 intra-area 8 RT10 * 4517 N N7 0 intra-area 12 RT10 * 4518 N N8 0 intra-area 10 RT10 * 4519 N N9 0 intra-area 11 RT10 * 4520 N N10 0 intra-area 13 RT10 * 4521 N N11 0 intra-area 14 RT10 * 4522 N H1 0 intra-area 21 RT10 * 4523 R RT5 0 intra-area 6 RT5 * 4524 R RT7 0 intra-area 8 RT10 * 4525 ____________________________________________________________ 4526 N N12 * type 1 ext. 10 RT10 RT7 4527 N N13 * type 1 ext. 14 RT5 RT5 4528 N N14 * type 1 ext. 14 RT5 RT5 4529 N N15 * type 1 ext. 17 RT10 RT7 4531 Table 12: The routing table for Router RT6 4532 (no configured areas). 4534 backbone (by Router RT11). Note that the cost of this route is 4535 the maximum of the set of costs to its individual components. 4537 There is a virtual link configured between Routers RT10 and 4538 RT11. Without this configured virtual link, RT11 would be 4539 unable to advertise a route for networks N9-N11 and Host H1 into 4540 the backbone, and there would not be an entry for these networks 4541 in Router RT4's routing table. 4543 In this example there are two equal-cost paths to Network N12. 4544 However, they both use the same next hop (Router RT5). 4546 Router RT4's routing table would improve (i.e., some of the 4547 paths in the routing table would become shorter) if an 4548 additional virtual link were configured between Router RT4 and 4549 Router RT3. The new virtual link would itself be associated 4550 Type Dest Area Path Type Cost Next Adv. 4551 Hops(s) Router(s) 4552 __________________________________________________________________ 4553 N N1 1 intra-area 4 RT1 * 4554 N N2 1 intra-area 4 RT2 * 4555 N N3 1 intra-area 1 * * 4556 N N4 1 intra-area 3 RT3 * 4557 R RT3 1 intra-area 1 * * 4558 __________________________________________________________________ 4559 N Ib 0 intra-area 22 RT5 * 4560 N Ia 0 intra-area 27 RT5 * 4561 R RT3 0 intra-area 21 RT5 * 4562 R RT5 0 intra-area 8 * * 4563 R RT7 0 intra-area 14 RT5 * 4564 R RT10 0 intra-area 22 RT5 * 4565 R RT11 0 intra-area 25 RT5 * 4566 __________________________________________________________________ 4567 N N6 0 inter-area 15 RT5 RT7 4568 N N7 0 inter-area 19 RT5 RT7 4569 N N8 0 inter-area 18 RT5 RT7 4570 N N9-N11,H1 0 inter-area 36 RT5 RT11 4571 __________________________________________________________________ 4572 N N12 * type 1 ext. 16 RT5 RT5,RT7 4573 N N13 * type 1 ext. 16 RT5 RT5 4574 N N14 * type 1 ext. 16 RT5 RT5 4575 N N15 * type 1 ext. 23 RT5 RT7 4577 Table 13: Router RT4's routing table 4578 in the presence of areas. 4580 with the first entry for area border router RT3 in Table 13 (an 4581 intra-area path through Area 1). This would yield a cost of 1 4582 for the virtual link. The routing table entries changes that 4583 would be caused by the addition of this virtual link are shown 4584 in Table 14. 4586 12. Link State Advertisements (LSAs) 4588 Each router in the Autonomous System originates one or more link 4589 state advertisements (LSAs). This memo defines five distinct types 4590 of LSAs, which are described in Section 4.3. The collection of LSAs 4591 forms the link-state database. Each separate type of LSA has a 4592 separate function. Router-LSAs and network-LSAs describe how an 4593 Type Dest Area Path Type Cost Next Adv. 4594 Hop(s) Router(s) 4595 ________________________________________________________________ 4596 N Ib 0 intra-area 16 RT3 * 4597 N Ia 0 intra-area 21 RT3 * 4598 R RT3 0 intra-area 1 * * 4599 R RT10 0 intra-area 16 RT3 * 4600 R RT11 0 intra-area 19 RT3 * 4601 ________________________________________________________________ 4602 N N9-N11,H1 0 inter-area 30 RT3 RT11 4604 Table 14: Changes resulting from an 4605 additional virtual link. 4607 area's routers and networks are interconnected. Summary-LSAs 4608 provide a way of condensing an area's routing information. AS- 4609 external-LSAs provide a way of transparently advertising 4610 externally-derived routing information throughout the Autonomous 4611 System. 4613 Each LSA begins with a standard 20-byte header. This LSA header is 4614 discussed below. 4616 12.1. The LSA Header 4618 The LSA header contains the LS type, Link State ID and 4619 Advertising Router fields. The combination of these three 4620 fields uniquely identifies the LSA. 4622 There may be several instances of an LSA present in the 4623 Autonomous System, all at the same time. It must then be 4624 determined which instance is more recent. This determination is 4625 made by examining the LS sequence, LS checksum and LS age 4626 fields. These fields are also contained in the 20-byte LSA 4627 header. 4629 Several of the OSPF packet types list LSAs. When the instance 4630 is not important, an LSA is referred to by its LS type, Link 4631 State ID and Advertising Router (see Link State Request 4632 Packets). Otherwise, the LS sequence number, LS age and LS 4633 checksum fields must also be referenced. 4635 A detailed explanation of the fields contained in the LSA header 4636 follows. 4638 12.1.1. LS age 4640 This field is the age of the LSA in seconds. It should be 4641 processed as an unsigned 16-bit integer. It is set to 0 4642 when the LSA is originated. It must be incremented by 4643 InfTransDelay on every hop of the flooding procedure. LSAs 4644 are also aged as they are held in each router's database. 4646 The age of an LSA is never incremented past MaxAge. LSAs 4647 having age MaxAge are not used in the routing table 4648 calculation. When an LSA's age first reaches MaxAge, it is 4649 reflooded. An LSA of age MaxAge is finally flushed from the 4650 database when it is no longer needed to ensure database 4651 synchronization. For more information on the aging of LSAs, 4652 consult Section 14. 4654 The LS age field is examined when a router receives two 4655 instances of an LSA, both having identical LS sequence 4656 numbers and LS checksums. An instance of age MaxAge is then 4657 always accepted as most recent; this allows old LSAs to be 4658 flushed quickly from the routing domain. Otherwise, if the 4659 ages differ by more than MaxAgeDiff, the instance having the 4660 smaller age is accepted as most recent.[12] See Section 13.1 4661 for more details. 4663 12.1.2. Options 4665 The Options field in the LSA header indicates which optional 4666 capabilities are associated with the LSA. OSPF's optional 4667 capabilities are described in Section 4.5. There are 4668 currently two optional capabilities defined; they are 4669 represented by the T-bit and E-bit found in the Options 4670 field. The rest of the Options field should be set to zero. 4672 The E-bit represents OSPF's ExternalRoutingCapability. This 4673 bit should be set in all LSAs associated with the backbone, 4674 and all LSAs associated with non-stub areas (see Section 4675 3.6). It should also be set in all AS-external-LSAs. It 4676 should be reset in all router-LSAs, network-LSAs and 4677 summary-LSAs associated with a stub area. For all LSAs, the 4678 setting of the E-bit is for informational purposes only; it 4679 does not affect the routing table calculation. 4681 The T-bit represents OSPF's TOS routing capability. This 4682 bit should be set in a router-LSA if and only if the router 4683 is capable of calculating separate routes for each IP TOS 4684 (see Section 2.5). The T-bit should always be set in 4685 network-LSAs. It should be set in summary-LSAs and AS- 4686 external-LSAs if and only if the LSA describes paths for all 4687 TOS values, instead of just the TOS 0 path. Note that, with 4688 the T-bit set, there may still be only a single metric in 4689 the LSA (the TOS 0 metric). This would mean that paths for 4690 non-zero TOS exist, but are equivalent to the TOS 0 path. 4691 An LSA's T-bit is examined when calculating the routing 4692 table's non-zero TOS paths (see Section 16.9). 4694 12.1.3. LS type 4696 The LS type field dictates the format and function of the 4697 LSA. LSAs of different types have different names (e.g., 4698 router-LSAs or network-LSAs). All LSA types defined by this 4699 memo, except the AS-external-LSAs (LS type = 5), are flooded 4700 throughout a single area only. AS-external-LSAs are flooded 4701 throughout the entire Autonomous System, excepting stub 4702 areas (see Section 3.6). Each separate LSA type is briefly 4703 described below in Table 15. 4705 12.1.4. Link State ID 4707 This field identifies the piece of the routing domain that 4708 is being described by the LSA. Depending on the LSA's LS 4709 type, the Link State ID takes on the values listed in Table 4710 16. 4712 Actually, for Type 3 summary-LSAs (LS type = 3) and AS- 4713 external-LSAs (LS type = 5), the Link State ID may 4714 additionally have one or more of the destination network's 4715 "host" bits set. For example, when originating an AS- 4716 external-LSA for the network 10.0.0.0 with mask of 4717 255.0.0.0, the Link State ID can be set to anything in the 4718 range 10.0.0.0 through 10.255.255.255 inclusive (although 4719 10.0.0.0 should be used whenever possible). The freedom to 4720 set certain host bits allows a router to originate separate 4721 LSAs for two networks having the same address but different 4722 masks. See Appendix E for details. 4724 When the LSA is describing a network (LS type = 2, 3 or 5), 4725 the network's IP address is easily derived by masking the 4726 Link State ID with the network/subnet mask contained in the 4727 body of the LSA. When the LSA is describing a router (LS 4728 type = 1 or 4), the Link State ID is always the described 4729 router's OSPF Router ID. 4731 LS Type LSA description 4732 ________________________________________________ 4733 1 These are the router-LSAs. 4734 They describe the collected 4735 states of the router's 4736 interfaces. For more information, 4737 consult Section 12.4.1. 4738 ________________________________________________ 4739 2 These are the network-LSAs. 4740 They describe the set of routers 4741 attached to the network. For 4742 more information, consult 4743 Section 12.4.2. 4744 ________________________________________________ 4745 3 or 4 These are the summary-LSAs. 4746 They describe inter-area routes, 4747 and enable the condensation of 4748 routing information at area 4749 borders. Originated by area border 4750 routers, the Type 3 summary-LSAs 4751 describe routes to networks while the 4752 Type 4 summary-LSAs describe routes to 4753 AS boundary routers. 4754 ________________________________________________ 4755 5 These are the AS-external-LSAs. 4756 Originated by AS boundary routers, 4757 they describe routes 4758 to destinations external to the 4759 Autonomous System. A default route for 4760 the Autonomous System can also be 4761 described by an AS-external-LSA. 4763 Table 15: OSPF link state advertisements (LSAs). 4765 LS Type Link State ID 4766 _______________________________________________ 4767 1 The originating router's Router ID. 4768 2 The IP interface address of the 4769 network's Designated Router. 4770 3 The destination network's IP address. 4771 4 The Router ID of the described AS 4772 boundary router. 4773 5 The destination network's IP address. 4775 Table 16: The LSA's Link State ID. 4777 When an AS-external-LSA (LS Type = 5) is describing a 4778 default route, its Link State ID is set to 4779 DefaultDestination (0.0.0.0). 4781 12.1.5. Advertising Router 4783 This field specifies the OSPF Router ID of the LSA's 4784 originator. For router-LSAs, this field is identical to the 4785 Link State ID field. Network-LSAs are originated by the 4786 network's Designated Router. Summary-LSAs originated by 4787 area border routers. AS-external-LSAs are originated by AS 4788 boundary routers. 4790 12.1.6. LS sequence number 4792 The sequence number field is a signed 32-bit integer. It is 4793 used to detect old and duplicate LSAs. The space of 4794 sequence numbers is linearly ordered. The larger the 4795 sequence number (when compared as signed 32-bit integers) 4796 the more recent the LSA. To describe to sequence number 4797 space more precisely, let N refer in the discussion below to 4798 the constant 2**31. 4800 The sequence number -N (0x80000000) is reserved (and 4801 unused). This leaves -N + 1 (0x80000001) as the smallest 4802 (and therefore oldest) sequence number; this sequence number 4803 is referred to as the constant InitialSequenceNumber. A 4804 router uses InitialSequenceNumber the first time it 4805 originates any LSA. Afterwards, the LSA's sequence number 4806 is incremented each time the router originates a new 4807 instance of the LSA. When an attempt is made to increment 4808 the sequence number past the maximum value of N - 1 4809 (0x7fffffff; also referred to as MaxSequenceNumber), the 4810 current instance of the LSA must first be flushed from the 4811 routing domain. This is done by prematurely aging the LSA 4812 (see Section 14.1) and reflooding it. As soon as this flood 4813 has been acknowledged by all adjacent neighbors, a new 4814 instance can be originated with sequence number of 4815 InitialSequenceNumber. 4817 The router may be forced to promote the sequence number of 4818 one of its LSAs when a more recent instance of the LSA is 4819 unexpectedly received during the flooding process. This 4820 should be a rare event. This may indicate that an out-of- 4821 date LSA, originated by the router itself before its last 4822 restart/reload, still exists in the Autonomous System. For 4823 more information see Section 13.4. 4825 12.1.7. LS checksum 4827 This field is the checksum of the complete contents of the 4828 LSA, excepting the LS age field. The LS age field is 4829 excepted so that an LSA's age can be incremented without 4830 updating the checksum. The checksum used is the same that 4831 is used for ISO connectionless datagrams; it is commonly 4832 referred to as the Fletcher checksum. It is documented in 4833 Annex B of [Ref6]. The LSA header also contains the length 4834 of the LSA in bytes; subtracting the size of the LS age 4835 field (two bytes) yields the amount of data to checksum. 4837 The checksum is used to detect data corruption of an LSA. 4838 This corruption can occur while an LSA is being flooded, or 4839 while it is being held in a router's memory. The LS 4840 checksum field cannot take on the value of zero; the 4841 occurrence of such a value should be considered a checksum 4842 failure. In other words, calculation of the checksum is not 4843 optional. 4845 The checksum of an LSA is verified in two cases: a) when it 4846 is received in a Link State Update Packet and b) at times 4847 during the aging of the link state database. The detection 4848 of a checksum failure leads to separate actions in each 4849 case. See Sections 13 and 14 for more details. 4851 Whenever the LS sequence number field indicates that two 4852 instances of an LSA are the same, the LS checksum field is 4853 examined. If there is a difference, the instance with the 4854 larger LS checksum is considered to be most recent.[13] See 4855 Section 13.1 for more details. 4857 12.2. The link state database 4859 A router has a separate link state database for every area to 4860 which it belongs. All routers belonging to the same area have 4861 identical link state databases for the area. 4863 The databases for each individual area are always dealt with 4864 separately. The shortest path calculation is performed 4865 separately for each area (see Section 16). Components of the 4866 area link-state database are flooded throughout the area only. 4867 Finally, when an adjacency (belonging to Area A) is being 4868 brought up, only the database for Area A is synchronized between 4869 the two routers. 4871 The area database is composed of router-LSAs, network-LSAs and 4872 summary-LSAs (all listed in the area data structure). In 4873 addition, external routes (AS-external-LSAs) are included in all 4874 non-stub area databases (see Section 3.6). 4876 An implementation of OSPF must be able to access individual 4877 pieces of an area database. This lookup function is based on an 4878 LSA's LS type, Link State ID and Advertising Router.[14] There 4879 will be a single instance (the most up-to-date) of each LSA in 4880 the database. The database lookup function is invoked during 4881 the LSA flooding procedure (Section 13) and the routing table 4882 calculation (Section 16). In addition, using this lookup 4883 function the router can determine whether it has itself ever 4884 originated a particular LSA, and if so, with what LS sequence 4885 number. 4887 An LSA is added to a router's database when either a) it is 4888 received during the flooding process (Section 13) or b) it is 4889 originated by the router itself (Section 12.4). An LSA is 4890 deleted from a router's database when either a) it has been 4891 overwritten by a newer instance during the flooding process 4892 (Section 13) or b) the router originates a newer instance of one 4893 of its self-originated LSAs (Section 12.4) or c) the LSA ages 4894 out and is flushed from the routing domain (Section 14). 4895 Whenever an LSA is deleted from the database it must also be 4896 removed from all neighbors' Link state retransmission lists (see 4897 Section 10). 4899 12.3. Representation of TOS 4901 All OSPF LSAs (with the exception of network-LSAs) specify 4902 metrics. In router-LSAs, the metrics indicate the costs of the 4903 described interfaces. In summary-LSAs and AS-external-LSAs, the 4904 metric indicates the cost of the described path. In all of 4905 these LSAs, a separate metric can be specified for each IP TOS. 4906 The encoding of TOS in OSPF LSAs is specified in Table 17. That 4907 table relates the OSPF encoding to the IP packet header's TOS 4908 field (defined in [Ref12]). The OSPF encoding is expressed as a 4909 decimal integer, and the IP packet header's TOS field is 4910 expressed in the binary TOS values used in [Ref12]. 4912 OSPF encoding RFC 1349 TOS values 4913 ___________________________________________ 4914 0 0000 normal service 4915 2 0001 minimize monetary cost 4916 4 0010 maximize reliability 4917 6 0011 4918 8 0100 maximize throughput 4919 10 0101 4920 12 0110 4921 14 0111 4922 16 1000 minimize delay 4923 18 1001 4924 20 1010 4925 22 1011 4926 24 1100 4927 26 1101 4928 28 1110 4929 30 1111 4931 Table 17: Representing TOS in OSPF. 4933 Each OSPF LSA must specify the TOS 0 metric. Other TOS metrics, 4934 if they appear, must appear in order of increasing TOS encoding. 4935 For example, the TOS 8 (maximize throughput) metric must always 4936 appear before the TOS 16 (minimize delay) metric when both are 4937 specified. If a metric for some non-zero TOS is not specified, 4938 its cost defaults to the cost for TOS 0, unless the T-bit is 4939 reset in the LSA's Options field (see Section 12.1.2 for more 4940 details). 4942 12.4. Originating LSAs 4944 Into any given OSPF area, a router will originate several LSAs. 4945 Each router originates a router-LSA. If the router is also the 4946 Designated Router for any of the area's networks, it will 4947 originate network-LSAs for those networks. 4949 Area border routers originate a single summary-LSA for each 4950 known inter-area destination. AS boundary routers originate a 4951 single AS-external-LSA for each known AS external destination. 4952 Destinations are advertised one at a time so that the change in 4953 any single route can be flooded without reflooding the entire 4954 collection of routes. During the flooding procedure, many LSAs 4955 can be carried by a single Link State Update packet. 4957 As an example, consider Router RT4 in Figure 6. It is an area 4958 border router, having a connection to Area 1 and the backbone. 4959 Router RT4 originates 5 distinct LSAs into the backbone (one 4960 router-LSA, and one summary-LSA for each of the networks N1-N4). 4961 Router RT4 will also originate 8 distinct LSAs into Area 1 (one 4962 router-LSA and seven summary-LSAs as pictured in Figure 7). If 4963 RT4 has been selected as Designated Router for Network N3, it 4964 will also originate a network-LSA for N3 into Area 1. 4966 In this same figure, Router RT5 will be originating 3 distinct 4967 AS-external-LSAs (one for each of the networks N12-N14). These 4968 will be flooded throughout the entire AS, assuming that none of 4969 the areas have been configured as stubs. However, if area 3 has 4970 been configured as a stub area, the AS-external-LSAs for 4971 networks N12-N14 will not be flooded into area 3 (see Section 4972 3.6). Instead, Router RT11 would originate a default summary- 4973 LSA that would be flooded throughout area 3 (see Section 4974 12.4.3). This instructs all of area 3's internal routers to 4975 send their AS external traffic to RT11. 4977 Whenever a new instance of an LSA is originated, its LS sequence 4978 number is incremented, its LS age is set to 0, its LS checksum 4979 is calculated, and the LSA is added to the link state database 4980 and flooded out the appropriate interfaces. See Section 13.2 4981 for details concerning the installation of the LSA into the link 4982 state database. See Section 13.3 for details concerning the 4983 flooding of newly originated LSAs. 4985 The ten events that can cause a new instance of an LSA to be 4986 originated are: 4988 (1) The LS age field of one of the router's self-originated LSAs 4989 reaches the value LSRefreshTime. In this case, a new 4990 instance of the LSA is originated, even though the contents 4991 of the LSA (apart from the LSA header) will be the same. 4992 This guarantees periodic originations of all LSAs. This 4993 periodic updating of LSAs adds robustness to the link state 4994 algorithm. LSAs that solely describe unreachable 4995 destinations should not be refreshed, but should instead be 4996 flushed from the routing domain (see Section 14.1). 4998 When whatever is being described by an LSA changes, a new LSA is 4999 originated. However, two instances of the same LSA may not be 5000 originated within the time period MinLSInterval. This may 5001 require that the generation of the next instance be delayed by 5002 up to MinLSInterval. The following events may cause the 5003 contents of an LSA to change. These events should cause new 5004 originations if and only if the contents of the new LSA would be 5005 different: 5007 (2) An interface's state changes (see Section 9.1). This may 5008 mean that it is necessary to produce a new instance of the 5009 router-LSA. 5011 (3) An attached network's Designated Router changes. A new 5012 router-LSA should be originated. Also, if the router itself 5013 is now the Designated Router, a new network-LSA should be 5014 produced. If the router itself is no longer the Designated 5015 Router, any network-LSA that it might have originated for 5016 the network should be flushed from the routing domain (see 5017 Section 14.1). 5019 (4) One of the neighboring routers changes to/from the FULL 5020 state. This may mean that it is necessary to produce a new 5021 instance of the router-LSA. Also, if the router is itself 5022 the Designated Router for the attached network, a new 5023 network-LSA should be produced. 5025 The next four events concern area border routers only: 5027 (5) An intra-area route has been added/deleted/modified in the 5028 routing table. This may cause a new instance of a summary- 5029 LSA (for this route) to be originated in each attached area 5030 (possibly including the backbone). 5032 (6) An inter-area route has been added/deleted/modified in the 5033 routing table. This may cause a new instance of a summary- 5034 LSA (for this route) to be originated in each attached area 5035 (but NEVER for the backbone). 5037 (7) The router becomes newly attached to an area. The router 5038 must then originate summary-LSAs into the newly attached 5039 area for all pertinent intra-area and inter-area routes in 5040 the router's routing table. See Section 12.4.3 for more 5041 details. 5043 (8) When the state of one of the router's configured virtual 5044 links changes, it may be necessary to originate a new 5045 router-LSA into the virtual link's Transit area (see the 5046 discussion of the router-LSA's bit V in Section 12.4.1), as 5047 well as originating a new router-LSA into the backbone. 5049 The last two events concern AS boundary routers (and former AS 5050 boundary routers) only: 5052 (9) An external route gained through direct experience with an 5053 external routing protocol (like BGP) changes. This will 5054 cause an AS boundary router to originate a new instance of 5055 an AS-external-LSA. 5057 (10) 5058 A router ceases to be an AS boundary router, perhaps after 5059 restarting. In this situation the router should flush all 5060 AS-external-LSAs that it had previously originated. These 5061 LSAs can be flushed via the premature aging procedure 5062 specified in Section 14.1. 5064 The construction of each type of LSA is explained in detail 5065 below. In general, these sections describe the contents of the 5066 LSA body (i.e., the part coming after the 20-byte LSA header). 5067 For information concerning the building of the LSA header, see 5068 Section 12.1. 5070 12.4.1. Router-LSAs 5072 A router originates a router-LSA for each area that it 5073 belongs to. Such an LSA describes the collected states of 5074 the router's links to the area. The LSA is flooded 5075 throughout the particular area, and no further. 5077 The format of a router-LSA is shown in Appendix A (Section 5078 A.4.2). The first 20 bytes of the LSA consist of the 5079 generic LSA header that was discussed in Section 12.1. 5080 router-LSAs have LS type = 1. The router indicates whether 5081 it is willing to calculate separate routes for each IP TOS 5082 .................................... 5083 . 192.1.2 Area 1 . 5084 . + . 5085 . | . 5086 . | 3+---+1 . 5087 . N1 |--|RT1|-----+ . 5088 . | +---+ \ . 5089 . | \ _______N3 . 5090 . + \/ \ . 1+---+ 5091 . * 192.1.1 *------|RT4| 5092 . + /\_______/ . +---+ 5093 . | / | . 5094 . | 3+---+1 / | . 5095 . N2 |--|RT2|-----+ 1| . 5096 . | +---+ +---+8 . 6+---+ 5097 . | |RT3|----------------|RT6| 5098 . + +---+ . +---+ 5099 . 192.1.3 |2 . 18.10.0.6|7 5100 . | . | 5101 . +------------+ . 5102 . 192.1.4 (N4) . 5103 .................................... 5105 Figure 15: Area 1 with IP addresses shown 5107 by setting (or resetting) the T-bit of the LSA's Options 5108 field. 5110 A router also indicates whether it is an area border router, 5111 or an AS boundary router, by setting the appropriate bits 5112 (bit B and bit E, respectively) in its router-LSAs. This 5113 enables paths to those types of routers to be saved in the 5114 routing table, for later processing of summary-LSAs and AS- 5115 external-LSAs. Bit B should be set whenever the router is 5116 actively attached to two or more areas, even if the router 5117 is not currently attached to the OSPF backbone area. Bit E 5118 should never be set in a router-LSA for a stub area (stub 5119 areas cannot contain AS boundary routers). 5121 In addition, the router sets bit V in its router-LSA for 5122 Area A if and only if the router is the endpoint of one or 5123 more fully adjacent virtual links having Area A as their 5124 Transit area. The setting of bit V enables other routers in 5125 Area A to discover whether the area supports transit traffic 5126 (see TransitCapability in Section 6). 5128 The router-LSA then describes the router's working 5129 connections (i.e., interfaces or links) to the area. Each 5130 link is typed according to the kind of attached network. 5131 Each link is also labelled with its Link ID. This Link ID 5132 gives a name to the entity that is on the other end of the 5133 link. Table 18 summarizes the values used for the Type and 5134 Link ID fields. 5136 Link type Description Link ID 5137 __________________________________________________ 5138 1 Point-to-point Neighbor Router ID 5139 link 5140 2 Link to transit Interface address of 5141 network Designated Router 5142 3 Link to stub IP network number 5143 network 5144 4 Virtual link Neighbor Router ID 5146 Table 18: Link descriptions in the 5147 router-LSA. 5149 In addition, the Link Data field is specified for each link. 5150 This field gives 32 bits of extra information for the link. 5151 For links to transit networks, numbered point-to-point links 5152 and virtual links, this field specifies the IP interface 5153 address of the associated router interface (this is needed 5154 by the routing table calculation, see Section 16.1.1). For 5155 links to stub networks, this field specifies the stub 5156 network's IP address mask. For unnumbered point-to-point 5157 links, the Link Data field should be set to the unnumbered 5158 interface's MIB-II [Ref8] ifIndex value. 5160 Finally, the cost of using the link for output (possibly 5161 specifying a different cost for each Type of Service) is 5162 specified. The output cost of a link is configurable. With 5163 the exception of links to stub networks, the output cost 5164 must always be non-zero. 5166 To further describe the process of building the list of link 5167 descriptions, suppose a router wishes to build a router-LSA 5168 for Area A. The router examines its collection of interface 5169 data structures. For each interface, the following steps 5170 are taken: 5172 o If the attached network does not belong to Area A, no 5173 links are added to the LSA, and the next interface 5174 should be examined. 5176 o If the state of the interface is Down, no links are 5177 added. 5179 o If the state of the interface is Loopback, add a Type 3 5180 link (stub network) as long as this is not an interface 5181 to an unnumbered point-to-point network. The Link ID 5182 should be set to the IP interface address, the Link Data 5183 set to the mask 0xffffffff (indicating a host route), 5184 and the cost set to 0. 5186 o Otherwise, the link descriptions added to the router-LSA 5187 depend on the OSPF interface type. Link descriptions 5188 used for point-to-point interfaces are specified in 5189 Section 12.4.1.1, for virtual links in Section 12.4.1.2, 5190 for broadcast and NBMA interfaces in 12.4.1.3, and for 5191 Point-to-MultiPoint interfaces in 12.4.1.4. 5193 After consideration of all the router interfaces, host links 5194 are added to the router-LSA by examining the list of 5195 attached hosts belonging to Area A. A host route is 5196 represented as a Type 3 link (stub network) whose Link ID is 5197 the host's IP address, Link Data is the mask of all ones 5198 (0xffffffff), and cost the host's configured cost (see 5199 Section C.7). 5201 12.4.1.1. Describing point-to-point interfaces 5203 For point-to-point interfaces, one or more link 5204 descriptions are added to the router-LSA as follows: 5206 o If the neighboring router is fully adjacent, add a 5207 Type 1 link (point-to-point). The Link ID should be 5208 set to the Router ID of the neighboring router. For 5209 numbered point-to-point networks, the Link Data 5210 should specify the IP interface address. For 5211 unnumbered point-to-point networks, the Link Data 5212 field should specify the interface's MIB-II [Ref8] 5213 ifIndex value. The cost should be set to the output 5214 cost of the point-to-point interface. 5216 o In addition, as long as the state of the interface 5217 is "Point-to-Point" (and regardless of the 5218 neighboring router state), a Type 3 link (stub 5219 network) should be added. There are two forms that 5220 this stub link can take: 5222 Option 1 5223 Assuming that the neighboring router's IP 5224 address is known, set the Link ID of the Type 3 5225 link to the neighbor's IP address, the Link Data 5226 to the mask 0xffffffff (indicating a host 5227 route), and the cost to the interface's 5228 configured output cost.[15] 5230 Option 2 5231 If a subnet has been assigned to the point-to- 5232 point link, set the Link ID of the Type 3 link 5233 to the subnet's IP address, the Link Data to the 5234 subnet's mask, and the cost to the interface's 5235 configured output cost.[16] 5237 12.4.1.2. Describing broadcast and NBMA interfaces 5239 For operational broadcast and NBMA interfaces, a single 5240 link description is added to the router-LSA as follows: 5242 o If the state of the interface is Waiting, add a Type 5243 3 link (stub network) with Link ID set to the IP 5244 network number of the attached network, Link Data 5245 set to the attached network's address mask, and cost 5246 equal to the interface's configured output cost. 5248 o Else, there has been a Designated Router elected for 5249 the attached network. If the router is fully 5250 adjacent to the Designated Router, or if the router 5251 itself is Designated Router and is fully adjacent to 5252 at least one other router, add a single Type 2 link 5253 (transit network) with Link ID set to the IP 5254 interface address of the attached network's 5255 Designated Router (which may be the router itself), 5256 Link Data set to the router's own IP interface 5257 address, and cost equal to the interface's 5258 configured output cost. Otherwise, add a link as if 5259 the interface state were Waiting (see above). 5261 12.4.1.3. Describing virtual links 5263 For virtual links, a link description is added to the 5264 router-LSA only when the virtual neighbor is fully 5265 adjacent. In this case, add a Type 4 link (virtual link) 5266 with Link ID set to the Router ID of the virtual 5267 neighbor, Link Data set to the IP interface address 5268 associated with the virtual link and cost set to the 5269 cost calculated for the virtual link during the routing 5270 table calculation (see Section 15). 5272 12.4.1.4. Describing Point-to-MultiPoint interfaces 5274 For operational Point-to-MultiPoint interfaces, one or 5275 more link descriptions are added to the router-LSA as 5276 follows: 5278 o A single Type 3 link (stub network) is added with 5279 Link ID set to the router's own IP interface 5280 address, Link Data set to the mask 0xffffffff 5281 (indicating a host route), and cost set to 0. 5283 o For each fully adjacent neighbor associated with the 5284 interface, add an additional Type 1 link (point-to- 5285 point) with Link ID set to the Router ID of the 5286 neighboring router, Link Data set to the IP 5287 interface address and cost equal to the interface's 5288 configured output cost. 5290 12.4.1.5. Examples of router-LSAs 5292 Consider the router-LSAs generated by Router RT3, as 5293 pictured in Figure 6. The area containing Router RT3 5294 (Area 1) has been redrawn, with actual network 5295 addresses, in Figure 15. Assume that the last byte of 5296 all of RT3's interface addresses is 3, giving it the 5297 interface addresses 192.1.1.3 and 192.1.4.3, and that 5298 the other routers have similar addressing schemes. In 5299 addition, assume that all links are functional, and that 5300 Router IDs are assigned as the smallest IP interface 5301 address. 5303 RT3 originates two router-LSAs, one for Area 1 and one 5304 for the backbone. Assume that Router RT4 has been 5305 selected as the Designated router for network 192.1.1.0. 5306 RT3's router-LSA for Area 1 is then shown below. It 5307 indicates that RT3 has two connections to Area 1, the 5308 first a link to the transit network 192.1.1.0 and the 5309 second a link to the stub network 192.1.4.0. Note that 5310 the transit network is identified by the IP interface of 5311 its Designated Router (i.e., the Link ID = 192.1.1.4 5312 which is the Designated Router RT4's IP interface to 5313 192.1.1.0). Note also that RT3 has indicated that it is 5314 capable of calculating separate routes based on IP TOS, 5315 through setting the T-bit in the Options field. It has 5316 also indicated that it is an area border router. 5318 ; RT3's router-LSA for Area 1 5320 LS age = 0 ;always true on origination 5321 Options = (T-bit|E-bit) ;TOS-capable 5322 LS type = 1 ;indicates router-LSA 5323 Link State ID = 192.1.1.3 ;RT3's Router ID 5324 Advertising Router = 192.1.1.3 ;RT3's Router ID 5325 bit E = 0 ;not an AS boundary router 5326 bit B = 1 ;area border router 5327 #links = 2 5328 Link ID = 192.1.1.4 ;IP address of Desig. Rtr. 5329 Link Data = 192.1.1.3 ;RT3's IP interface to net 5330 Type = 2 ;connects to transit network 5331 # other metrics = 0 5332 TOS 0 metric = 1 5334 Link ID = 192.1.4.0 ;IP Network number 5335 Link Data = 0xffffff00 ;Network mask 5336 Type = 3 ;connects to stub network 5337 # other metrics = 0 5338 TOS 0 metric = 2 5340 Next RT3's router-LSA for the backbone is shown. It 5341 indicates that RT3 has a single attachment to the 5342 backbone. This attachment is via an unnumbered point- 5343 to-point link to Router RT6. RT3 has again indicated 5344 that it is TOS-capable, and that it is an area border 5345 router. 5347 ; RT3's router-LSA for the backbone 5349 LS age = 0 ;always true on origination 5350 Options = (T-bit|E-bit) ;TOS-capable 5351 LS type = 1 ;indicates router-LSA 5352 Link State ID = 192.1.1.3 ;RT3's router ID 5353 Advertising Router = 192.1.1.3 ;RT3's router ID 5354 bit E = 0 ;not an AS boundary router 5355 bit B = 1 ;area border router 5356 #links = 1 5357 Link ID = 18.10.0.6 ;Neighbor's Router ID 5358 Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link 5359 Type = 1 ;connects to router 5360 # other metrics = 0 5361 TOS 0 metric = 8 5363 Even though Router RT3 has indicated that it is TOS- 5364 capable in the above examples, only a single metric (the 5365 TOS 0 metric) has been specified for each interface. 5366 Different metrics can be specified for each TOS. The 5367 encoding of TOS in OSPF LSAs is described in Section 5368 12.3. 5370 As an example, suppose the point-to-point link between 5371 Routers RT3 and RT6 in Figure 15 is a satellite link. 5372 The AS administrator may want to encourage the use of 5373 the line for high bandwidth traffic. This would be done 5374 by setting the metric artificially low for the 5375 appropriate TOS value. Router RT3 would then originate 5376 the following router-LSA for the backbone (TOS 8 = 5377 maximize throughput): 5379 ; RT3's router-LSA for the backbone 5381 LS age = 0 ;always true on origination 5382 Options = (T-bit|E-bit) ;TOS-capable 5383 LS type = 1 ;indicates router-LSA 5384 Link State ID = 192.1.1.3 ;RT3's Router ID 5385 Advertising Router = 192.1.1.3 5386 bit E = 0 ;not an AS boundary router 5387 bit B = 1 ;area border router 5388 #links = 1 5389 Link ID = 18.10.0.6 ;Neighbor's Router ID 5390 Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link 5391 Type = 1 ;connects to router 5392 # other metrics = 1 5393 TOS 0 metric = 8 5394 TOS = 8 ;maximize throughput 5395 metric = 1 ;traffic preferred 5397 12.4.2. Network-LSAs 5399 A network-LSA is generated for every transit broadcast or 5400 NBMA network. (A transit network is a network having two or 5401 more attached routers). The network-LSA describes all the 5402 routers that are attached to the network. 5404 The Designated Router for the network originates the LSA. 5405 The Designated Router originates the LSA only if it is fully 5406 adjacent to at least one other router on the network. The 5407 network-LSA is flooded throughout the area that contains the 5408 transit network, and no further. The network-LSA lists 5409 those routers that are fully adjacent to the Designated 5410 Router; each fully adjacent router is identified by its OSPF 5411 Router ID. The Designated Router includes itself in this 5412 list. 5414 The Link State ID for a network-LSA is the IP interface 5415 address of the Designated Router. This value, masked by the 5416 network's address mask (which is also contained in the 5417 network-LSA) yields the network's IP address. 5419 A router that has formerly been the Designated Router for a 5420 network, but is no longer, should flush the network-LSA that 5421 it had previously originated. This LSA is no longer used in 5422 the routing table calculation. It is flushed by prematurely 5423 incrementing the LSA's age to MaxAge and reflooding (see 5424 Section 14.1). In addition, in those rare cases where a 5425 router's Router ID has changed, any network-LSAs that were 5426 originated with the router's previous Router ID must be 5427 flushed. Since the router may have no idea what it's 5428 previous Router ID might have been, these network-LSAs are 5429 indicated by having their Link State ID equal to one of the 5430 router's IP interface addresses and their Advertising Router 5431 equal to some value other than the router's current Router 5432 ID (see Section 13.4 for more details). 5434 12.4.2.1. Examples of network-LSAs 5436 Again consider the area configuration in Figure 6. 5437 Network-LSAs are originated for Network N3 in Area 1, 5438 Networks N6 and N8 in Area 2, and Network N9 in Area 3. 5439 Assuming that Router RT4 has been selected as the 5440 Designated Router for Network N3, the following 5441 network-LSA is generated by RT4 on behalf of Network N3 5442 (see Figure 15 for the address assignments): 5444 ; Network-LSA for Network N3 5446 LS age = 0 ;always true on origination 5447 Options = (T-bit|E-bit) ;TOS-capable 5448 LS type = 2 ;indicates network-LSA 5449 Link State ID = 192.1.1.4 ;IP address of Desig. Rtr. 5450 Advertising Router = 192.1.1.4 ;RT4's Router ID 5451 Network Mask = 0xffffff00 5452 Attached Router = 192.1.1.4 ;Router ID 5453 Attached Router = 192.1.1.1 ;Router ID 5454 Attached Router = 192.1.1.2 ;Router ID 5455 Attached Router = 192.1.1.3 ;Router ID 5457 12.4.3. Summary-LSAs 5459 The destination described by a summary-LSA is either an IP 5460 network, an AS boundary router or a range of IP addresses. 5461 Summary-LSAs are flooded throughout a single area only. The 5462 destination described is one that is external to the area, 5463 yet still belongs to the Autonomous System. 5465 Summary-LSAs are originated by area border routers. The 5466 precise summary routes to advertise into an area are 5467 determined by examining the routing table structure (see 5468 Section 11) in accordance with the algorithm described 5469 below. Note that only intra-area routes are advertised into 5470 the backbone, while both intra-area and inter-area routes 5471 are advertised into the other areas. 5473 To determine which routes to advertise into an attached Area 5474 A, each routing table entry is processed as follows. 5475 Remember that each routing table entry describes a set of 5476 equal-cost best paths to a particular destination: 5478 o Only Destination Types of network and AS boundary router 5479 are advertised in summary-LSAs. If the routing table 5480 entry's Destination Type is area border router, examine 5481 the next routing table entry. 5483 o AS external routes are never advertised in summary-LSAs. 5484 If the routing table entry has Path-type of type 1 5485 external or type 2 external, examine the next routing 5486 table entry. 5488 o Else, if the area associated with this set of paths is 5489 the Area A itself, do not generate a summary-LSA for the 5490 route.[17] 5492 o Else, if the next hops associated with this set of paths 5493 belong to Area A itself, do not generate a summary-LSA 5494 for the route.[18] This is the logical equivalent of a 5495 Distance Vector protocol's split horizon logic. 5497 o Else, if the routing table cost equals or exceeds the 5498 value LSInfinity, a summary-LSA cannot be generated for 5499 this route. 5501 o Else, if the destination of this route is an AS boundary 5502 router, a summary-LSA should be originated if and only 5503 if the routing table entry describes the preferred path 5504 to the AS boundary router (see Step 3 of Section 16.4). 5505 If so, a Type 4 summary-LSA is originated for the 5506 destination, with Link State ID equal to the AS boundary 5507 router's Router ID and metric equal to the routing table 5508 entry's cost. Note: these LSAs should not be generated 5509 if Area A has been configured as a stub area. 5511 o Else, the Destination type is network. If this is an 5512 inter-area route, generate a Type 3 summary-LSA for the 5513 destination, with Link State ID equal to the network's 5514 address (if necessary, the Link State ID can also have 5515 one or more of the network's host bits set; see Appendix 5516 E for details) and metric equal to the routing table 5517 cost. 5519 o The one remaining case is an intra-area route to a 5520 network. This means that the network is contained in 5521 one of the router's directly attached areas. In 5522 general, this information must be condensed before 5523 appearing in summary-LSAs. Remember that an area has a 5524 configured list of address ranges, each range consisting 5525 of an [address,mask] pair and a status indication of 5526 either Advertise or DoNotAdvertise. At most a single 5527 Type 3 summary-LSA is originated for each range. When 5528 the range's status indicates Advertise, a Type 3 5529 summary-LSA is generated with Link State ID equal to the 5530 range's address (if necessary, the Link State ID can 5531 also have one or more of the range's "host" bits set; 5532 see Appendix E for details) and cost equal to the 5533 largest cost of any of the component networks. When the 5534 range's status indicates DoNotAdvertise, the Type 3 5535 summary-LSA is suppressed and the component networks 5536 remain hidden from other areas. 5538 By default, if a network is not contained in any 5539 explicitly configured address range, a Type 3 summary- 5540 LSA is generated with Link State ID equal to the 5541 network's address (if necessary, the Link State ID can 5542 also have one or more of the network's "host" bits set; 5543 see Appendix E for details) and metric equal to the 5544 network's routing table cost. 5546 If an area is capable of carrying transit traffic (i.e., 5547 its TransitCapability is set to TRUE), routing 5548 information concerning backbone networks should not be 5549 condensed before being summarized into the area. Nor 5550 should the advertisement of backbone networks into 5551 transit areas be suppressed. In other words, the 5552 backbone's configured ranges should be ignored when 5553 originating summary-LSAs into transit areas. 5555 If a router advertises a summary-LSA for a destination which 5556 then becomes unreachable, the router must then flush the LSA 5557 from the routing domain by setting its age to MaxAge and 5558 reflooding (see Section 14.1). Also, if the destination is 5559 still reachable, yet can no longer be advertised according 5560 to the above procedure (e.g., it is now an inter-area route, 5561 when it used to be an intra-area route associated with some 5562 non-backbone area; it would thus no longer be advertisable 5563 to the backbone), the LSA should also be flushed from the 5564 routing domain. 5566 For the destination described by a summary-LSA there may be 5567 separate sets of paths, and therefore separate routing table 5568 entries, for each Type of Service. All these entries must 5569 be considered when building the summary-LSA for the 5570 destination; a single LSA must specify the separate costs 5571 (if they exist) for each TOS. The encoding of TOS in OSPF 5572 LSAs is described in Section 12.3. 5574 Clearing the T-bit in the Options field of a summary-LSA 5575 indicates that there is a TOS 0 path to the destination, but 5576 no paths for non-zero TOS. This can happen when non-TOS- 5577 capable routers exist in the routing domain (see Section 5578 2.5). 5580 12.4.3.1. Originating summary-LSAs into stub areas 5582 The algorithm in Section 12.4.3 is optional when Area A 5583 is an OSPF stub area. Area border routers connecting to 5584 a stub area can originate summary-LSAs into the area 5585 according to the Section 12.4.3's algorithm, or can 5586 choose to originate only a subset of the summary-LSAs, 5587 possibly under configuration control. The fewer LSAs 5588 originated, the smaller the stub area's link state 5589 database, further reducing the demands on its routers' 5590 resources. However, omitting LSAs may also lead to sub- 5591 optimal inter-area routing, although routing will 5592 continue to function. 5594 As specified in Section 12.4.3, Type 4 summary-LSAs 5595 (ASBR-summary-LSAs) are never originated into stub 5596 areas. 5598 In a stub area, instead of importing external routes 5599 each area border router originates a "default summary- 5600 LSA" into the area. The Link State ID for the default 5601 summary-LSA is set to DefaultDestination, and the metric 5602 set to the (per-area) configurable parameter 5603 StubDefaultCost. Note that StubDefaultCost need not be 5604 configured identically in all of the stub area's area 5605 border routers. 5607 12.4.3.2. Examples of summary-LSAs 5609 Consider again the area configuration in Figure 6. 5610 Routers RT3, RT4, RT7, RT10 and RT11 are all area border 5611 routers, and therefore are originating summary-LSAs. 5612 Consider in particular Router RT4. Its routing table 5613 was calculated as the example in Section 11.3. RT4 5614 originates summary-LSAs into both the backbone and Area 5615 1. Into the backbone, Router RT4 originates separate 5616 LSAs for each of the networks N1-N4. Into Area 1, 5617 Router RT4 originates separate LSAs for networks N6-N8 5618 and the AS boundary routers RT5,RT7. It also condenses 5619 host routes Ia and Ib into a single summary-LSA. 5620 Finally, the routes to networks N9,N10,N11 and Host H1 5621 are advertised by a single summary-LSA. This 5622 condensation was originally performed by the router 5623 RT11. 5625 These LSAs are illustrated graphically in Figures 7 and 5626 8. Two of the summary-LSAs originated by Router RT4 5627 follow. The actual IP addresses for the networks and 5628 routers in question have been assigned in Figure 15. 5630 ; Summary-LSA for Network N1, 5631 ; originated by Router RT4 into the backbone 5633 LS age = 0 ;always true on origination 5634 Options = (T-bit|E-bit) ;TOS-capable 5635 LS type = 3 ;Type 3 summary-LSA 5636 Link State ID = 192.1.2.0 ;N1's IP network number 5637 Advertising Router = 192.1.1.4 ;RT4's ID 5638 TOS = 0 5639 metric = 4 5640 ; Summary-LSA for AS boundary router RT7 5641 ; originated by Router RT4 into Area 1 5643 LS age = 0 ;always true on origination 5644 Options = (T-bit|E-bit) ;TOS-capable 5645 LS type = 4 ;Type 4 summary-LSA 5646 Link State ID = Router RT7's ID 5647 Advertising Router = 192.1.1.4 ;RT4's ID 5648 TOS = 0 5649 metric = 14 5651 12.4.4. AS-external-LSAs 5653 AS-external-LSAs describe routes to destinations external to 5654 the Autonomous System. Most AS-external-LSAs describe 5655 routes to specific external destinations; in these cases the 5656 LSA's Link State ID is set to the destination network's IP 5657 address (if necessary, the Link State ID can also have one 5658 or more of the network's "host" bits set; see Appendix E for 5659 details). However, a default route for the Autonomous 5660 System can be described in an AS-external-LSA by setting the 5661 LSA's Link State ID to DefaultDestination (0.0.0.0). AS- 5662 external-LSAs are originated by AS boundary routers. An AS 5663 boundary router originates a single AS-external-LSA for each 5664 external route that it has learned, either through another 5665 routing protocol (such as BGP), or through configuration 5666 information. 5668 AS-external-LSAs are the only type of LSAs that are flooded 5669 throughout the entire Autonomous System; all other types of 5670 LSAs are specific to a single area. However, AS-external- 5671 LSAs are not flooded into/throughout stub areas (see Section 5672 3.6). This enables a reduction in link state database size 5673 for routers internal to stub areas. 5675 The metric that is advertised for an external route can be 5676 one of two types. Type 1 metrics are comparable to the link 5677 state metric. Type 2 metrics are assumed to be larger than 5678 the cost of any intra-AS path. As with summary-LSAs, if 5679 separate paths exist based on TOS, separate TOS costs can be 5680 included in the AS-external-LSA The encoding of TOS in OSPF 5681 LSAs is described in Section 12.3. If the T-bit of the 5682 LSA's Options field is clear, no non-zero TOS paths to the 5683 destination exist. 5685 If a router advertises an AS-external-LSA for a destination 5686 which then becomes unreachable, the router must then flush 5687 the LSA from the routing domain by setting its age to MaxAge 5688 and reflooding (see Section 14.1). 5690 12.4.4.1. Examples of AS-external-LSAs 5692 Consider once again the AS pictured in Figure 6. There 5693 are two AS boundary routers: RT5 and RT7. Router RT5 5694 originates three AS-external-LSAs, for networks N12-N14. 5695 Router RT7 originates two AS-external-LSAs, for networks 5696 N12 and N15. Assume that RT7 has learned its route to 5697 N12 via BGP, and that it wishes to advertise a Type 2 5698 metric to the AS. RT7 would then originate the 5699 following LSA for N12: 5701 ; AS-external-LSA for Network N12, 5702 ; originated by Router RT7 5704 LS age = 0 ;always true on origination 5705 Options = (T-bit|E-bit) ;TOS-capable 5706 LS type = 5 ;AS-external-LSA 5707 Link State ID = N12's IP network number 5708 Advertising Router = Router RT7's ID 5709 bit E = 1 ;Type 2 metric 5710 TOS = 0 5711 metric = 2 5712 Forwarding address = 0.0.0.0 5714 In the above example, the forwarding address field has 5715 been set to 0.0.0.0, indicating that packets for the 5716 external destination should be forwarded to the 5717 advertising OSPF router (RT7). This is not always 5718 desirable. Consider the example pictured in Figure 16. 5719 There are three OSPF routers (RTA, RTB and RTC) 5720 connected to a common network. Only one of these 5721 routers, RTA, is exchanging BGP information with the 5722 non-OSPF router RTX. RTA must then originate AS- 5723 external-LSAs for those destinations it has learned from 5724 RTX. By using the AS-external-LSA's forwarding address 5725 field, RTA can specify that packets for these 5726 destinations be forwarded directly to RTX. Without this 5727 feature, Routers RTB and RTC would take an extra hop to 5728 get to these destinations. 5730 Note that when the forwarding address field is non-zero, 5731 it should point to a router belonging to another 5732 Autonomous System. 5734 A forwarding address can also be specified for the 5735 default route. For example, in figure 16 RTA may want 5736 to specify that all externally-destined packets should 5737 by default be forwarded to its BGP peer RTX. The 5738 resulting AS-external-LSA is pictured below. Note that 5739 the Link State ID is set to DefaultDestination. 5741 ; Default route, originated by Router RTA 5742 ; Packets forwarded through RTX 5744 LS age = 0 ;always true on origination 5745 Options = (T-bit|E-bit) ;TOS-capable 5746 LS type = 5 ;AS-external-LSA 5747 Link State ID = DefaultDestination ; default route 5748 Advertising Router = Router RTA's ID 5749 bit E = 1 ;Type 2 metric 5750 TOS = 0 5751 metric = 1 5752 Forwarding address = RTX's IP address 5754 In figure 16, suppose instead that both RTA and RTB 5755 exchange BGP information with RTX. In this case, RTA 5756 and RTB would originate the same set of AS-external- 5757 LSAs. These LSAs, if they specify the same metric, 5758 would be functionally equivalent since they would 5759 specify the same destination and forwarding address 5760 (RTX). This leads to a clear duplication of effort. If 5761 only one of RTA or RTB originated the set of AS- 5762 external-LSAs, the routing would remain the same, and 5763 the size of the link state database would decrease. 5764 However, it must be unambiguously defined as to which 5765 router originates the LSAs (otherwise neither may, or 5766 the identity of the originator may oscillate). The 5767 following rule is thereby established: if two routers, 5768 both reachable from one another, originate functionally 5769 equivalent AS-external-LSAs (i.e., same destination, 5770 cost and non-zero forwarding address), then the LSA 5771 originated by the router having the highest OSPF Router 5772 ID is used. The router having the lower OSPF Router ID 5773 can then flush its LSA. Flushing an LSA is discussed in 5774 Section 14.1. 5776 13. The Flooding Procedure 5778 Link State Update packets provide the mechanism for flooding LSAs. 5779 A Link State Update packet may contain several distinct LSAs, and 5780 floods each LSA one hop further from its point of origination. To 5781 make the flooding procedure reliable, each LSA must be acknowledged 5783 + 5784 | 5785 +---+.....|.BGP 5786 |RTA|-----|.....+---+ 5787 +---+ |-----|RTX| 5788 | +---+ 5789 +---+ | 5790 |RTB|-----| 5791 +---+ | 5792 | 5793 +---+ | 5794 |RTC|-----| 5795 +---+ | 5796 | 5797 + 5799 Figure 16: Forwarding address example 5801 separately. Acknowledgments are transmitted in Link State 5802 Acknowledgment packets. Many separate acknowledgments can also be 5803 grouped together into a single packet. 5805 The flooding procedure starts when a Link State Update packet has 5806 been received. Many consistency checks have been made on the 5807 received packet before being handed to the flooding procedure (see 5808 Section 8.2). In particular, the Link State Update packet has been 5809 associated with a particular neighbor, and a particular area. If 5810 the neighbor is in a lesser state than Exchange, the packet should 5811 be dropped without further processing. 5813 All types of LSAs, other than AS-external-LSAs, are associated with 5814 a specific area. However, LSAs do not contain an area field. An 5815 LSA's area must be deduced from the Link State Update packet header. 5817 For each LSA contained in a Link State Update packet, the following 5818 steps are taken: 5820 (1) Validate the LSA's LS checksum. If the checksum turns out to be 5821 invalid, discard the LSA and get the next one from the Link 5822 State Update packet. 5824 (2) Examine the LSA's LS type. If the LS type is unknown, discard 5825 the LSA and get the next one from the Link State Update Packet. 5826 This specification defines LS types 1-5 (see Section 4.3). 5828 (3) Else if this is an AS-external-LSA (LS type = 5), and the area 5829 has been configured as a stub area, discard the LSA and get the 5830 next one from the Link State Update Packet. AS-external-LSAs 5831 are not flooded into/throughout stub areas (see Section 3.6). 5833 (4) Else if the LSA's LS age is equal to MaxAge, and there is 5834 currently no instance of the LSA in the router's link state 5835 database, then take the following actions: 5837 (a) Acknowledge the receipt of the LSA by sending a Link State 5838 Acknowledgment packet back to the sending neighbor (see 5839 Section 13.5). 5841 (b) Purge all outstanding requests for equal or previous 5842 instances of the LSA from the sending neighbor's Link State 5843 Request list (see Section 10). 5845 (c) If the sending neighbor is in state Exchange or in state 5846 Loading, then install the MaxAge LSA in the link state 5847 database. Otherwise, simply discard the LSA. In either 5848 case, examine the next LSA (if any) listed in the Link State 5849 Update packet. 5851 (5) Otherwise, find the instance of this LSA that is currently 5852 contained in the router's link state database. If there is no 5853 database copy, or the received LSA is more recent than the 5854 database copy (see Section 13.1 below for the determination of 5855 which LSA is more recent) the following steps must be performed: 5857 (a) If there is already a database copy, and if the database 5858 copy was installed less than MinLSArrival seconds ago, 5859 discard the new LSA (without acknowledging it) and examine 5860 the next LSA (if any) listed in the Link State Update 5861 packet. 5863 (b) Otherwise immediately flood the new LSA out some subset of 5864 the router's interfaces (see Section 13.3). In some cases 5865 (e.g., the state of the receiving interface is DR and the 5866 LSA was received from a router other than the Backup DR) the 5867 LSA will be flooded back out the receiving interface. This 5868 occurrence should be noted for later use by the 5869 acknowledgment process (Section 13.5). 5871 (c) Remove the current database copy from all neighbors' Link 5872 state retransmission lists. 5874 (d) Install the new LSA in the link state database (replacing 5875 the current database copy). This may cause the routing 5876 table calculation to be scheduled. In addition, timestamp 5877 the new LSA with the current time (i.e., the time it was 5878 received). The flooding procedure cannot overwrite the 5879 newly installed LSA until MinLSArrival seconds have elapsed. 5880 The LSA installation process is discussed further in Section 5881 13.2. 5883 (e) Possibly acknowledge the receipt of the LSA by sending a 5884 Link State Acknowledgment packet back out the receiving 5885 interface. This is explained below in Section 13.5. 5887 (f) If this new LSA indicates that it was originated by the 5888 receiving router itself (i.e., is considered a self- 5889 originated LSA), the router must take special action, either 5890 updating the LSA or in some cases flushing it from the 5891 routing domain. For a description of how self-originated 5892 LSAs are detected and subsequently handled, see Section 5893 13.4. 5895 (6) Else, if there is an instance of the LSA on the sending 5896 neighbor's Link state request list, an error has occurred in the 5897 Database Exchange process. In this case, restart the Database 5898 Exchange process by generating the neighbor event BadLSReq for 5899 the sending neighbor and stop processing the Link State Update 5900 packet. 5902 (7) Else, if the received LSA is the same instance as the database 5903 copy (i.e., neither one is more recent) the following two steps 5904 should be performed: 5906 (a) If the LSA is listed in the Link state retransmission list 5907 for the receiving adjacency, the router itself is expecting 5908 an acknowledgment for this LSA. The router should treat the 5909 received LSA as an acknowledgment by removing the LSA from 5910 the Link state retransmission list. This is termed an 5911 "implied acknowledgment". Its occurrence should be noted 5912 for later use by the acknowledgment process (Section 13.5). 5914 (b) Possibly acknowledge the receipt of the LSA by sending a 5915 Link State Acknowledgment packet back out the receiving 5916 interface. This is explained below in Section 13.5. 5918 (8) Else, the database copy is more recent. If the database copy 5919 has LS age equal to MaxAge and LS sequence number equal to 5920 MaxSequenceNumber, simply discard the received LSA without 5921 acknowledging it. (In this case, the LSA's LS sequence number is 5922 wrapping, and the MaxSequenceNumber LSA must be completely 5923 flushed before any new LSA instance can be introduced). 5925 Otherwise, send the database copy back to the sending neighbor, 5926 encapsulated within a Link State Update Packet. The Link State 5927 Update Packet should be unicast to the neighbor. In so doing, do 5928 not put the database copy of the LSA on the neighbor's link 5929 state retransmission list, and do not acknowledge the received 5930 (less recent) LSA instance. 5932 13.1. Determining which LSA is newer 5934 When a router encounters two instances of an LSA, it must 5935 determine which is more recent. This occurred above when 5936 comparing a received LSA to its database copy. This comparison 5937 must also be done during the Database Exchange procedure which 5938 occurs during adjacency bring-up. 5940 An LSA is identified by its LS type, Link State ID and 5941 Advertising Router. For two instances of the same LSA, the LS 5942 sequence number, LS age, and LS checksum fields are used to 5943 determine which instance is more recent: 5945 o The LSA having the newer LS sequence number is more recent. 5946 See Section 12.1.6 for an explanation of the LS sequence 5947 number space. If both instances have the same LS sequence 5948 number, then: 5950 o If the two instances have different LS checksums, then the 5951 instance having the larger LS checksum (when considered as a 5952 16-bit unsigned integer) is considered more recent. 5954 o Else, if only one of the instances has its LS age field set 5955 to MaxAge, the instance of age MaxAge is considered to be 5956 more recent. 5958 o Else, if the LS age fields of the two instances differ by 5959 more than MaxAgeDiff, the instance having the smaller 5960 (younger) LS age is considered to be more recent. 5962 o Else, the two instances are considered to be identical. 5964 13.2. Installing LSAs in the database 5966 Installing a new LSA in the database, either as the result of 5967 flooding or a newly self-originated LSA, may cause the OSPF 5968 routing table structure to be recalculated. The contents of the 5969 new LSA should be compared to the old instance, if present. If 5970 there is no difference, there is no need to recalculate the 5971 routing table. When comparing an LSA to its previous instance, 5972 the following are all considered to be differences in contents: 5974 o The LSA's Options field has changed. 5976 o One of the LSA instances has LS age set to MaxAge, and 5977 the other does not. 5979 o The length field in the LSA header has changed. 5981 o The body of the LSA (i.e., anything outside the 20-byte 5982 LSA header) has changed. Note that this excludes changes 5983 in LS Sequence Number and LS Checksum. 5985 If the contents are different, the following pieces of the 5986 routing table must be recalculated, depending on the new LSA's 5987 LS type field: 5989 Router-LSAs and network-LSAs 5990 The entire routing table must be recalculated, starting with 5991 the shortest path calculations for each area (not just the 5992 area whose link-state database has changed). The reason 5993 that the shortest path calculation cannot be restricted to 5994 the single changed area has to do with the fact that AS 5995 boundary routers may belong to multiple areas. A change in 5996 the area currently providing the best route may force the 5997 router to use an intra-area route provided by a different 5998 area.[19] 6000 Summary-LSAs 6001 The best route to the destination described by the summary- 6002 LSA must be recalculated (see Section 16.5). If this 6003 destination is an AS boundary router, it may also be 6004 necessary to re-examine all the AS-external-LSAs. 6006 AS-external-LSAs 6007 The best route to the destination described by the AS- 6008 external-LSA must be recalculated (see Section 16.6). 6010 Also, any old instance of the LSA must be removed from the 6011 database when the new LSA is installed. This old instance must 6012 also be removed from all neighbors' Link state retransmission 6013 lists (see Section 10). 6015 13.3. Next step in the flooding procedure 6017 When a new (and more recent) LSA has been received, it must be 6018 flooded out some set of the router's interfaces. This section 6019 describes the second part of flooding procedure (the first part 6020 being the processing that occurred in Section 13), namely, 6021 selecting the outgoing interfaces and adding the LSA to the 6022 appropriate neighbors' Link state retransmission lists. Also 6023 included in this part of the flooding procedure is the 6024 maintenance of the neighbors' Link state request lists. 6026 This section is equally applicable to the flooding of an LSA 6027 that the router itself has just originated (see Section 12.4). 6028 For these LSAs, this section provides the entirety of the 6029 flooding procedure (i.e., the processing of Section 13 is not 6030 performed, since, for example, the LSA has not been received 6031 from a neighbor and therefore does not need to be acknowledged). 6033 Depending upon the LSA's LS type, the LSA can be flooded out 6034 only certain interfaces. These interfaces, defined by the 6035 following, are called the eligible interfaces: 6037 AS-external-LSAs (LS Type = 5) 6038 AS-external-LSAs are flooded throughout the entire AS, with 6039 the exception of stub areas (see Section 3.6). The eligible 6040 interfaces are all the router's interfaces, excluding 6041 virtual links and those interfaces attaching to stub areas. 6043 All other LS types 6044 All other types are specific to a single area (Area A). The 6045 eligible interfaces are all those interfaces attaching to 6046 the Area A. If Area A is the backbone, this includes all 6047 the virtual links. 6049 Link state databases must remain synchronized over all 6050 adjacencies associated with the above eligible interfaces. This 6051 is accomplished by executing the following steps on each 6052 eligible interface. It should be noted that this procedure may 6053 decide not to flood an LSA out a particular interface, if there 6054 is a high probability that the attached neighbors have already 6055 received the LSA. However, in these cases the flooding 6056 procedure must be absolutely sure that the neighbors eventually 6057 do receive the LSA, so the LSA is still added to each 6058 adjacency's Link state retransmission list. For each eligible 6059 interface: 6061 (1) Each of the neighbors attached to this interface are 6062 examined, to determine whether they must receive the new 6063 LSA. The following steps are executed for each neighbor: 6065 (a) If the neighbor is in a lesser state than Exchange, it 6066 does not participate in flooding, and the next neighbor 6067 should be examined. 6069 (b) Else, if the adjacency is not yet full (neighbor state 6070 is Exchange or Loading), examine the Link state request 6071 list associated with this adjacency. If there is an 6072 instance of the new LSA on the list, it indicates that 6073 the neighboring router has an instance of the LSA 6074 already. Compare the new LSA to the neighbor's copy: 6076 o If the new LSA is less recent, then examine the next 6077 neighbor. 6079 o If the two copies are the same instance, then delete 6080 the LSA from the Link state request list, and 6081 examine the next neighbor.[20] 6083 o Else, the new LSA is more recent. Delete the LSA 6084 from the Link state request list. 6086 (c) If the new LSA was received from this neighbor, examine 6087 the next neighbor. 6089 (d) At this point we are not positive that the neighbor has 6090 an up-to-date instance of this new LSA. Add the new LSA 6091 to the Link state retransmission list for the adjacency. 6092 This ensures that the flooding procedure is reliable; 6093 the LSA will be retransmitted at intervals until an 6094 acknowledgment is seen from the neighbor. 6096 (2) The router must now decide whether to flood the new LSA out 6097 this interface. If in the previous step, the LSA was NOT 6098 added to any of the Link state retransmission lists, there 6099 is no need to flood the LSA out the interface and the next 6100 interface should be examined. 6102 (3) If the new LSA was received on this interface, and it was 6103 received from either the Designated Router or the Backup 6104 Designated Router, chances are that all the neighbors have 6105 received the LSA already. Therefore, examine the next 6106 interface. 6108 (4) If the new LSA was received on this interface, and the 6109 interface state is Backup (i.e., the router itself is the 6110 Backup Designated Router), examine the next interface. The 6111 Designated Router will do the flooding on this interface. 6112 However, if the Designated Router fails the router (i.e., 6113 the Backup Designated Router) will end up retransmitting the 6114 updates. 6116 (5) If this step is reached, the LSA must be flooded out the 6117 interface. Send a Link State Update packet (including the 6118 new LSA as contents) out the interface. The LSA's LS age 6119 must be incremented by InfTransDelay (which must be > 0) 6120 when it is copied into the outgoing Link State Update packet 6121 (until the LS age field reaches the maximum value of 6122 MaxAge). 6124 On broadcast networks, the Link State Update packets are 6125 multicast. The destination IP address specified for the 6126 Link State Update Packet depends on the state of the 6127 interface. If the interface state is DR or Backup, the 6128 address AllSPFRouters should be used. Otherwise, the 6129 address AllDRouters should be used. 6131 On non-broadcast networks, separate Link State Update 6132 packets must be sent, as unicasts, to each adjacent neighbor 6133 (i.e., those in state Exchange or greater). The destination 6134 IP addresses for these packets are the neighbors' IP 6135 addresses. 6137 13.4. Receiving self-originated LSAs 6139 It is a common occurrence for a router to receive self- 6140 originated LSAs via the flooding procedure. A self-originated 6141 LSA is detected when either 1) the LSA's Advertising Router is 6142 equal to the router's own Router ID or 2) the LSA is a network- 6143 LSA and its Link State ID is equal to one of the router's own IP 6144 interface addresses. 6146 However, if the received self-originated LSA is newer than the 6147 last instance that the router actually originated, the router 6148 must take special action. The reception of such an LSA 6149 indicates that there are LSAs in the routing domain that were 6150 originated by the router before the last time it was restarted. 6151 In most cases, the router must then advance the LSA's LS 6152 sequence number one past the received LS sequence number, and 6153 originate a new instance of the LSA. 6155 It may be the case the router no longer wishes to originate the 6156 received LSA. Possible examples include: 1) the LSA is a 6157 summary-LSA or AS-external-LSA and the router no longer has an 6158 (advertisable) route to the destination, 2) the LSA is a 6159 network-LSA but the router is no longer Designated Router for 6160 the network or 3) the LSA is a network-LSA whose Link State ID 6161 is one of the router's own IP interface addresses but whose 6162 Advertising Router is not equal to the router's own Router ID 6163 (this latter case should be rare, and it indicates that the 6164 router's Router ID has changed since originating the LSA). In 6165 all these cases, instead of updating the LSA, the LSA should be 6166 flushed from the routing domain by incrementing the received 6167 LSA's LS age to MaxAge and reflooding (see Section 14.1). 6169 13.5. Sending Link State Acknowledgment packets 6171 Each newly received LSA must be acknowledged. This is usually 6172 done by sending Link State Acknowledgment packets. However, 6173 acknowledgments can also be accomplished implicitly by sending 6174 Link State Update packets (see step 7a of Section 13). 6176 Many acknowledgments may be grouped together into a single Link 6177 State Acknowledgment packet. Such a packet is sent back out the 6178 interface which received the LSAs. The packet can be sent in 6179 one of two ways: delayed and sent on an interval timer, or sent 6180 directly (as a unicast) to a particular neighbor. The 6181 particular acknowledgment strategy used depends on the 6182 circumstances surrounding the receipt of the LSA. 6184 Sending delayed acknowledgments accomplishes several things: 1) 6185 it facilitates the packaging of multiple acknowledgments in a 6186 single Link State Acknowledgment packet, 2) it enables a single 6187 Link State Acknowledgment packet to indicate acknowledgments to 6188 several neighbors at once (through multicasting) and 3) it 6189 randomizes the Link State Acknowledgment packets sent by the 6190 various routers attached to a common network. The fixed 6191 interval between a router's delayed transmissions must be short 6192 (less than RxmtInterval) or needless retransmissions will ensue. 6194 Direct acknowledgments are sent to a particular neighbor in 6195 response to the receipt of duplicate LSAs. These 6196 acknowledgments are sent as unicasts, and are sent immediately 6197 when the duplicate is received. 6199 The precise procedure for sending Link State Acknowledgment 6200 packets is described in Table 19. The circumstances surrounding 6201 the receipt of the LSA are listed in the left column. The 6202 acknowledgment action then taken is listed in one of the two 6203 right columns. This action depends on the state of the 6204 concerned interface; interfaces in state Backup behave 6205 differently from interfaces in all other states. Delayed 6206 acknowledgments must be delivered to all adjacent routers 6207 associated with the interface. On broadcast networks, this is 6208 accomplished by sending the delayed Link State Acknowledgment 6209 packets as multicasts. The Destination IP address used depends 6210 on the state of the interface. If the interface state is DR or 6211 Backup, the destination AllSPFRouters is used. In all other 6212 states, the destination AllDRouters is used. On non-broadcast 6213 networks, delayed Link State Acknowledgment packets must be 6214 unicast separately over each adjacency (i.e., neighbor whose 6215 state is >= Exchange). 6217 The reasoning behind sending the above packets as multicasts is 6218 best explained by an example. Consider the network 6219 configuration depicted in Figure 15. Suppose RT4 has been 6220 elected as Designated Router, and RT3 as Backup Designated 6221 Router for the network N3. When Router RT4 floods a new LSA to 6222 Network N3, it is received by routers RT1, RT2, and RT3. These 6223 routers will not flood the LSA back onto net N3, but they still 6224 must ensure that their link-state databases remain synchronized 6225 with their adjacent neighbors. So RT1, RT2, and RT4 are waiting 6226 to see an acknowledgment from RT3. Likewise, RT4 and RT3 are 6227 both waiting to see acknowledgments from RT1 and RT2. This is 6228 best achieved by sending the acknowledgments as multicasts. 6230 The reason that the acknowledgment logic for Backup DRs is 6231 slightly different is because they perform differently during 6232 the flooding of LSAs (see Section 13.3, step 4). 6234 13.6. Retransmitting LSAs 6236 LSAs flooded out an adjacency are placed on the adjacency's Link 6237 state retransmission list. In order to ensure that flooding is 6238 reliable, these LSAs are retransmitted until they are 6239 acknowledged. The length of time between retransmissions is a 6240 configurable per-interface value, RxmtInterval. If this is set 6241 too low for an interface, needless retransmissions will ensue. 6242 If the value is set too high, the speed of the flooding, in the 6243 face of lost packets, may be affected. 6245 Several retransmitted LSAs may fit into a single Link State 6246 Update packet. When LSAs are to be retransmitted, only the 6247 number fitting in a single Link State Update packet should be 6248 Action taken in state 6249 Circumstances Backup All other states 6250 _______________________________________________________________ 6251 LSA has No acknowledgment No acknowledgment 6252 been flooded back sent. sent. 6253 out receiving in- 6254 terface (see Sec- 6255 tion 13, step 5b). 6256 _______________________________________________________________ 6257 LSA is Delayed acknowledg- Delayed ack- 6258 more recent than ment sent if adver- nowledgment sent. 6259 database copy, but tisement received 6260 was not flooded from Designated 6261 back out receiving Router, otherwise 6262 interface do nothing 6263 _______________________________________________________________ 6264 LSA is a Delayed acknowledg- No acknowledgment 6265 duplicate, and was ment sent if adver- sent. 6266 treated as an im- tisement received 6267 plied acknowledg- from Designated 6268 ment (see Section Router, otherwise 6269 13, step 7a). do nothing 6270 _______________________________________________________________ 6271 LSA is a Direct acknowledg- Direct acknowledg- 6272 duplicate, and was ment sent. ment sent. 6273 not treated as an 6274 implied ack- 6275 nowledgment. 6276 _______________________________________________________________ 6277 LSA's LS Direct acknowledg- Direct acknowledg- 6278 age is equal to ment sent. ment sent. 6279 MaxAge, and there is 6280 no current instance 6281 of the LSA 6282 in the link state 6283 database (see 6284 Section 13, step 4). 6286 Table 19: Sending link state acknowledgements. 6288 sent. Another packet of retransmissions can be sent whenever 6289 some of the LSAs are acknowledged, or on the next firing of the 6290 retransmission timer. 6292 Link State Update Packets carrying retransmissions are always 6293 sent as unicasts (directly to the physical address of the 6294 neighbor). They are never sent as multicasts. Each LSA's LS 6295 age must be incremented by InfTransDelay (which must be > 0) 6296 when it is copied into the outgoing Link State Update packet 6297 (until the LS age field reaches the maximum value of MaxAge). 6299 If an adjacent router goes down, retransmissions may occur until 6300 the adjacency is destroyed by OSPF's Hello Protocol. When the 6301 adjacency is destroyed, the Link state retransmission list is 6302 cleared. 6304 13.7. Receiving link state acknowledgments 6306 Many consistency checks have been made on a received Link State 6307 Acknowledgment packet before it is handed to the flooding 6308 procedure. In particular, it has been associated with a 6309 particular neighbor. If this neighbor is in a lesser state than 6310 Exchange, the Link State Acknowledgment packet is discarded. 6312 Otherwise, for each acknowledgment in the Link State 6313 Acknowledgment packet, the following steps are performed: 6315 o Does the LSA acknowledged have an instance on the Link state 6316 retransmission list for the neighbor? If not, examine the 6317 next acknowledgment. Otherwise: 6319 o If the acknowledgment is for the same instance that is 6320 contained on the list, remove the item from the list and 6321 examine the next acknowledgment. Otherwise: 6323 o Log the questionable acknowledgment, and examine the next 6324 one. 6326 14. Aging The Link State Database 6328 Each LSA has an LS age field. The LS age is expressed in seconds. 6329 An LSA's LS age field is incremented while it is contained in a 6330 router's database. Also, when copied into a Link State Update 6331 Packet for flooding out a particular interface, the LSA's LS age is 6332 incremented by InfTransDelay. 6334 An LSA's LS age is never incremented past the value MaxAge. LSAs 6335 having age MaxAge are not used in the routing table calculation. As 6336 a router ages its link state database, an LSA's LS age may reach 6337 MaxAge.[21] At this time, the router must attempt to flush the LSA 6338 from the routing domain. This is done simply by reflooding the 6339 MaxAge LSA just as if it was a newly originated LSA (see Section 6340 13.3). 6342 When creating a Database summary list for a newly forming adjacency, 6343 any MaxAge LSAs present in the link state database are added to the 6344 neighbor's Link state retransmission list instead of the neighbor's 6345 Database summary list. See Section 10.3 for more details. 6347 A MaxAge LSA must be removed immediately from the router's link 6348 state database as soon as both a) it is no longer contained on any 6349 neighbor Link state retransmission lists and b) none of the router's 6350 neighbors are in states Exchange or Loading. 6352 When, in the process of aging the link state database, an LSA's LS 6353 age hits a multiple of CheckAge, its LS checksum should be verified. 6354 If the LS checksum is incorrect, a program or memory error has been 6355 detected, and at the very least the router itself should be 6356 restarted. 6358 14.1. Premature aging of LSAs 6360 An LSA can be flushed from the routing domain by setting its LS 6361 age to MaxAge and reflooding the LSA. This procedure follows 6362 the same course as flushing an LSA whose LS age has naturally 6363 reached the value MaxAge (see Section 14). In particular, the 6364 MaxAge LSA is removed from the router's link state database as 6365 soon as a) it is no longer contained on any neighbor Link state 6366 retransmission lists and b) none of the router's neighbors are 6367 in states Exchange or Loading. We call the setting of an LSA's 6368 LS age to MaxAge "premature aging". 6370 Premature aging is used when it is time for a self-originated 6371 LSA's sequence number field to wrap. At this point, the current 6372 LSA instance (having LS sequence number MaxSequenceNumber) must 6373 be prematurely aged and flushed from the routing domain before a 6374 new instance with sequence number equal to InitialSequenceNumber 6375 can be originated. See Section 12.1.6 for more information. 6377 Premature aging can also be used when, for example, one of the 6378 router's previously advertised external routes is no longer 6379 reachable. In this circumstance, the router can flush its AS- 6380 external-LSA from the routing domain via premature aging. This 6381 procedure is preferable to the alternative, which is to 6382 originate a new LSA for the destination specifying a metric of 6383 LSInfinity. Premature aging is also be used when unexpectedly 6384 receiving self-originated LSAs during the flooding procedure 6385 (see Section 13.4). 6387 A router may only prematurely age its own self-originated LSAs. 6388 The router may not prematurely age LSAs that have been 6389 originated by other routers. An LSA is considered self- 6390 originated when either 1) the LSA's Advertising Router is equal 6391 to the router's own Router ID or 2) the LSA is a network-LSA and 6392 its Link State ID is equal to one of the router's own IP 6393 interface addresses. 6395 15. Virtual Links 6397 The single backbone area (Area ID = 0.0.0.0) cannot be disconnected, 6398 or some areas of the Autonomous System will become unreachable. To 6399 establish/maintain connectivity of the backbone, virtual links can 6400 be configured through non-backbone areas. Virtual links serve to 6401 connect physically separate components of the backbone. The two 6402 endpoints of a virtual link are area border routers. The virtual 6403 link must be configured in both routers. The configuration 6404 information in each router consists of the other virtual endpoint 6405 (the other area border router), and the non-backbone area the two 6406 routers have in common (called the Transit area). Virtual links 6407 cannot be configured through stub areas (see Section 3.6). 6409 The virtual link is treated as if it were an unnumbered point-to- 6410 point network belonging to the backbone and joining the two area 6411 border routers. An attempt is made to establish an adjacency over 6412 the virtual link. When this adjacency is established, the virtual 6413 link will be included in backbone router-LSAs, and OSPF packets 6414 pertaining to the backbone area will flow over the adjacency. Such 6415 an adjacency has been referred to in this document as a "virtual 6416 adjacency". 6418 In each endpoint router, the cost and viability of the virtual link 6419 is discovered by examining the routing table entry for the other 6420 endpoint router. (The entry's associated area must be the 6421 configured Transit area). Actually, there may be a separate routing 6422 table entry for each Type of Service. These are called the virtual 6423 link's corresponding routing table entries. The InterfaceUp event 6424 occurs for a virtual link when its corresponding TOS 0 routing table 6425 entry becomes reachable. Conversely, the InterfaceDown event occurs 6426 when its TOS 0 routing table entry becomes unreachable.[22] In other 6427 words, the virtual link's viability is determined by the existence 6428 of an intra-area path, through the Transit area, between the two 6429 endpoints. Note that a virtual link whose underlying path has cost 6430 greater than hexadecimal 0xffff (the maximum size of an interface 6431 cost in a router-LSA) should be considered inoperational (i.e., 6432 treated the same as if the path did not exist). 6434 The other details concerning virtual links are as follows: 6436 o AS-external-LSAs are NEVER flooded over virtual adjacencies. 6437 This would be duplication of effort, since the same AS- 6438 external-LSAs are already flooded throughout the virtual link's 6439 Transit area. For this same reason, AS-external-LSAs are not 6440 summarized over virtual adjacencies during the Database Exchange 6441 process. 6443 o The cost of a virtual link is NOT configured. It is defined to 6444 be the cost of the intra-area path between the two defining area 6445 border routers. This cost appears in the virtual link's 6446 corresponding routing table entry. When the cost of a virtual 6447 link changes, a new router-LSA should be originated for the 6448 backbone area. 6450 o Just as the virtual link's cost and viability are determined by 6451 the routing table build process (through construction of the 6452 routing table entry for the other endpoint), so are the IP 6453 interface address for the virtual interface and the virtual 6454 neighbor's IP address. These are used when sending OSPF 6455 protocol packets over the virtual link. Note that when one (or 6456 both) of the virtual link endpoints connect to the Transit area 6457 via an unnumbered point-to-point link, it may be impossible to 6458 calculate either the virtual interface's IP address and/or the 6459 virtual neighbor's IP address, thereby causing the virtual link 6460 to fail. 6462 o In each endpoint's router-LSA for the backbone, the virtual link 6463 is represented as a Type 4 link whose Link ID is set to the 6464 virtual neighbor's OSPF Router ID and whose Link Data is set to 6465 the virtual interface's IP address. See Section 12.4.1 for more 6466 information. Note that it may be the case that there is a TOS 0 6467 path, but no non-zero TOS paths, between the two endpoint 6468 routers. In this case, both routers must revert to being non- 6469 TOS-capable, clearing the T-bit in the Options field of their 6470 backbone router-LSAs. 6472 o A non-backbone area can carry transit data traffic (i.e., is 6473 considered a "transit area") if and only if it serves as the 6474 Transit area for one or more fully adjacent virtual links (see 6475 TransitCapability in Sections 6 and 16.1). Such an area requires 6476 special treatment when summarizing backbone networks into it 6477 (see Section 12.4.3), and during the routing calculation (see 6478 Section 16.3). 6480 o The time between link state retransmissions, RxmtInterval, is 6481 configured for a virtual link. This should be well over the 6482 expected round-trip delay between the two routers. This may be 6483 hard to estimate for a virtual link; it is better to err on the 6484 side of making it too large. 6486 16. Calculation of the routing table 6488 This section details the OSPF routing table calculation. Using its 6489 attached areas' link state databases as input, a router runs the 6490 following algorithm, building its routing table step by step. At 6491 each step, the router must access individual pieces of the link 6492 state databases (e.g., a router-LSA originated by a certain router). 6493 This access is performed by the lookup function discussed in Section 6494 12.2. The lookup process may return an LSA whose LS age is equal to 6495 MaxAge. Such an LSA should not be used in the routing table 6496 calculation, and is treated just as if the lookup process had 6497 failed. 6499 The OSPF routing table's organization is explained in Section 11. 6500 Two examples of the routing table build process are presented in 6501 Sections 11.2 and 11.3. This process can be broken into the 6502 following steps: 6504 (1) The present routing table is invalidated. The routing table is 6505 built again from scratch. The old routing table is saved so 6506 that changes in routing table entries can be identified. 6508 (2) The intra-area routes are calculated by building the shortest- 6509 path tree for each attached area. In particular, all routing 6510 table entries whose Destination Type is "area border router" are 6511 calculated in this step. This step is described in two parts. 6512 At first the tree is constructed by only considering those links 6513 between routers and transit networks. Then the stub networks 6514 are incorporated into the tree. During the area's shortest-path 6515 tree calculation, the area's TransitCapability is also 6516 calculated for later use in Step 4. 6518 (3) The inter-area routes are calculated, through examination of 6519 summary-LSAs. If the router is attached to multiple areas 6520 (i.e., it is an area border router), only backbone summary-LSAs 6521 are examined. 6523 (4) In area border routers connecting to one or more transit areas 6524 (i.e, non-backbone areas whose TransitCapability is found to be 6525 TRUE), the transit areas' summary-LSAs are examined to see 6526 whether better paths exist using the transit areas than were 6527 found in Steps 2-3 above. 6529 (5) Routes to external destinations are calculated, through 6530 examination of AS-external-LSAs. The locations of the AS 6531 boundary routers (which originate the AS-external-LSAs) have 6532 been determined in steps 2-4. 6534 Steps 2-5 are explained in further detail below. The explanations 6535 describe the calculations for TOS 0 only. It may also be necessary 6536 to perform each step (separately) for each of the non-zero TOS 6537 values.[23] For more information concerning the building of non-zero 6538 TOS routes see Section 16.9. 6540 Changes made to routing table entries as a result of these 6541 calculations can cause the OSPF protocol to take further actions. 6542 For example, a change to an intra-area route will cause an area 6543 border router to originate new summary-LSAs (see Section 12.4). See 6544 Section 16.7 for a complete list of the OSPF protocol actions 6545 resulting from routing table changes. 6547 16.1. Calculating the shortest-path tree for an area 6549 This calculation yields the set of intra-area routes associated 6550 with an area (called hereafter Area A). A router calculates the 6551 shortest-path tree using itself as the root.[24] The formation 6552 of the shortest path tree is done here in two stages. In the 6553 first stage, only links between routers and transit networks are 6554 considered. Using the Dijkstra algorithm, a tree is formed from 6555 this subset of the link state database. In the second stage, 6556 leaves are added to the tree by considering the links to stub 6557 networks. 6559 The procedure will be explained using the graph terminology that 6560 was introduced in Section 2. The area's link state database is 6561 represented as a directed graph. The graph's vertices are 6562 routers, transit networks and stub networks. The first stage of 6563 the procedure concerns only the transit vertices (routers and 6564 transit networks) and their connecting links. Throughout the 6565 shortest path calculation, the following data is also associated 6566 with each transit vertex: 6568 Vertex (node) ID 6569 A 32-bit number uniquely identifying the vertex. For router 6570 vertices this is the router's OSPF Router ID. For network 6571 vertices, this is the IP address of the network's Designated 6572 Router. 6574 An LSA 6575 Each transit vertex has an associated LSA. For router 6576 vertices, this is a router-LSA. For transit networks, this 6577 is a network-LSA (which is actually originated by the 6578 network's Designated Router). In any case, the LSA's Link 6579 State ID is always equal to the above Vertex ID. 6581 List of next hops 6582 The list of next hops for the current set of shortest paths 6583 from the root to this vertex. There can be multiple 6584 shortest paths due to the equal-cost multipath capability. 6585 Each next hop indicates the outgoing router interface to use 6586 when forwarding traffic to the destination. On broadcast, 6587 Point-to-MultiPoint and NBMA networks, the next hop also 6588 includes the IP address of the next router (if any) in the 6589 path towards the destination. 6591 Distance from root 6592 The link state cost of the current set of shortest paths 6593 from the root to the vertex. The link state cost of a path 6594 is calculated as the sum of the costs of the path's 6595 constituent links (as advertised in router-LSAs and 6596 network-LSAs). One path is said to be "shorter" than 6597 another if it has a smaller link state cost. 6599 The first stage of the procedure (i.e., the Dijkstra algorithm) 6600 can now be summarized as follows. At each iteration of the 6601 algorithm, there is a list of candidate vertices. Paths from 6602 the root to these vertices have been found, but not necessarily 6603 the shortest ones. However, the paths to the candidate vertex 6604 that is closest to the root are guaranteed to be shortest; this 6605 vertex is added to the shortest-path tree, removed from the 6606 candidate list, and its adjacent vertices are examined for 6607 possible addition to/modification of the candidate list. The 6608 algorithm then iterates again. It terminates when the candidate 6609 list becomes empty. 6611 The following steps describe the algorithm in detail. Remember 6612 that we are computing the shortest path tree for Area A. All 6613 references to link state database lookup below are from Area A's 6614 database. 6616 (1) Initialize the algorithm's data structures. Clear the list 6617 of candidate vertices. Initialize the shortest-path tree to 6618 only the root (which is the router doing the calculation). 6619 Set Area A's TransitCapability to FALSE. 6621 (2) Call the vertex just added to the tree vertex V. Examine 6622 the LSA associated with vertex V. This is a lookup in the 6623 Area A's link state database based on the Vertex ID. If 6624 this is a router-LSA, and bit V of the router-LSA (see 6625 Section A.4.2) is set, set Area A's TransitCapability to 6626 TRUE. In any case, each link described by the LSA gives the 6627 cost to an adjacent vertex. For each described link, (say 6628 it joins vertex V to vertex W): 6630 (a) If this is a link to a stub network, examine the next 6631 link in V's LSA. Links to stub networks will be 6632 considered in the second stage of the shortest path 6633 calculation. 6635 (b) Otherwise, W is a transit vertex (router or transit 6636 network). Look up the vertex W's LSA (router-LSA or 6637 network-LSA) in Area A's link state database. If the 6638 LSA does not exist, or its LS age is equal to MaxAge, or 6639 it does not have a link back to vertex V, examine the 6640 next link in V's LSA.[25] 6642 (c) If vertex W is already on the shortest-path tree, 6643 examine the next link in the LSA. 6645 (d) Calculate the link state cost D of the resulting path 6646 from the root to vertex W. D is equal to the sum of the 6647 link state cost of the (already calculated) shortest 6648 path to vertex V and the advertised cost of the link 6649 between vertices V and W. If D is: 6651 o Greater than the value that already appears for 6652 vertex W on the candidate list, then examine the 6653 next link. 6655 o Equal to the value that appears for vertex W on the 6656 candidate list, calculate the set of next hops that 6657 result from using the advertised link. Input to 6658 this calculation is the destination (W), and its 6659 parent (V). This calculation is shown in Section 6660 16.1.1. This set of hops should be added to the 6661 next hop values that appear for W on the candidate 6662 list. 6664 o Less than the value that appears for vertex W on the 6665 candidate list, or if W does not yet appear on the 6666 candidate list, then set the entry for W on the 6667 candidate list to indicate a distance of D from the 6668 root. Also calculate the list of next hops that 6669 result from using the advertised link, setting the 6670 next hop values for W accordingly. The next hop 6671 calculation is described in Section 16.1.1; it takes 6672 as input the destination (W) and its parent (V). 6674 (3) If at this step the candidate list is empty, the shortest- 6675 path tree (of transit vertices) has been completely built 6676 and this stage of the procedure terminates. Otherwise, 6677 choose the vertex belonging to the candidate list that is 6678 closest to the root, and add it to the shortest-path tree 6679 (removing it from the candidate list in the process). Note 6680 that when there is a choice of vertices closest to the root, 6681 network vertices must be chosen before router vertices in 6682 order to necessarily find all equal-cost paths. This is 6683 consistent with the tie-breakers that were introduced in the 6684 modified Dijkstra algorithm used by OSPF's Multicast routing 6685 extensions (MOSPF). 6687 (4) Possibly modify the routing table. For those routing table 6688 entries modified, the associated area will be set to Area A, 6689 the path type will be set to intra-area, and the cost will 6690 be set to the newly discovered shortest path's calculated 6691 distance. 6693 If the newly added vertex is an area border router or AS 6694 boundary router, a routing table entry is added whose 6695 destination type is "router". The Options field found in 6696 the associated router-LSA is copied into the routing table 6697 entry's Optional capabilities field. Call the newly added 6698 vertex Router X. If Router X is the endpoint of one of the 6699 calculating router's virtual links, and the virtual link 6700 uses Area A as Transit area: the virtual link is declared 6701 up, the IP address of the virtual interface is set to the IP 6702 address of the outgoing interface calculated above for 6703 Router X, and the virtual neighbor's IP address is set to 6704 Router X's interface address (contained in Router X's 6705 router-LSA) that points back to the root of the shortest- 6706 path tree; equivalently, this is the interface that points 6707 back to Router X's parent vertex on the shortest-path tree 6708 (similar to the calculation in Section 16.1.1). 6710 If the newly added vertex is a transit network, the routing 6711 table entry for the network is located. The entry's 6712 Destination ID is the IP network number, which can be 6713 obtained by masking the Vertex ID (Link State ID) with its 6714 associated subnet mask (found in the body of the associated 6715 network-LSA). If the routing table entry already exists 6716 (i.e., there is already an intra-area route to the 6717 destination installed in the routing table), multiple 6718 vertices have mapped to the same IP network. For example, 6719 this can occur when a new Designated Router is being 6720 established. In this case, the current routing table entry 6721 should be overwritten if and only if the newly found path is 6722 just as short and the current routing table entry's Link 6723 State Origin has a smaller Link State ID than the newly 6724 added vertex' LSA. 6726 If there is no routing table entry for the network (the 6727 usual case), a routing table entry for the IP network should 6728 be added. The routing table entry's Link State Origin 6729 should be set to the newly added vertex' LSA. 6731 (5) Iterate the algorithm by returning to Step 2. 6733 The stub networks are added to the tree in the procedure's 6734 second stage. In this stage, all router vertices are again 6735 examined. Those that have been determined to be unreachable in 6736 the above first phase are discarded. For each reachable router 6737 vertex (call it V), the associated router-LSA is found in the 6738 link state database. Each stub network link appearing in the 6739 LSA is then examined, and the following steps are executed: 6741 (1) Calculate the distance D of stub network from the root. D 6742 is equal to the distance from the root to the router vertex 6743 (calculated in stage 1), plus the stub network link's 6744 advertised cost. Compare this distance to the current best 6745 cost to the stub network. This is done by looking up the 6746 stub network's current routing table entry. If the 6747 calculated distance D is larger, go on to examine the next 6748 stub network link in the LSA. 6750 (2) If this step is reached, the stub network's routing table 6751 entry must be updated. Calculate the set of next hops that 6752 would result from using the stub network link. This 6753 calculation is shown in Section 16.1.1; input to this 6754 calculation is the destination (the stub network) and the 6755 parent vertex (the router vertex). If the distance D is the 6756 same as the current routing table cost, simply add this set 6757 of next hops to the routing table entry's list of next hops. 6759 In this case, the routing table already has a Link State 6760 Origin. If this Link State Origin is a router-LSA whose 6761 Link State ID is smaller than V's Router ID, reset the Link 6762 State Origin to V's router-LSA. 6764 Otherwise D is smaller than the routing table cost. 6765 Overwrite the current routing table entry by setting the 6766 routing table entry's cost to D, and by setting the entry's 6767 list of next hops to the newly calculated set. Set the 6768 routing table entry's Link State Origin to V's router-LSA. 6769 Then go on to examine the next stub network link. 6771 For all routing table entries added/modified in the second 6772 stage, the associated area will be set to Area A and the path 6773 type will be set to intra-area. When the list of reachable 6774 router-LSAs is exhausted, the second stage is completed. At 6775 this time, all intra-area routes associated with Area A have 6776 been determined. 6778 The specification does not require that the above two stage 6779 method be used to calculate the shortest path tree. However, if 6780 another algorithm is used, an identical tree must be produced. 6781 For this reason, it is important to note that links between 6782 transit vertices must be bidirectional in order to be included 6783 in the above tree. It should also be mentioned that more 6784 efficient algorithms exist for calculating the tree; for 6785 example, the incremental SPF algorithm described in [Ref1]. 6787 16.1.1. The next hop calculation 6789 This section explains how to calculate the current set of 6790 next hops to use for a destination. Each next hop consists 6791 of the outgoing interface to use in forwarding packets to 6792 the destination together with the IP address of the next hop 6793 router (if any). The next hop calculation is invoked each 6794 time a shorter path to the destination is discovered. This 6795 can happen in either stage of the shortest-path tree 6796 calculation (see Section 16.1). In stage 1 of the 6797 shortest-path tree calculation a shorter path is found as 6798 the destination is added to the candidate list, or when the 6799 destination's entry on the candidate list is modified (Step 6800 2d of Stage 1). In stage 2 a shorter path is discovered 6801 each time the destination's routing table entry is modified 6802 (Step 2 of Stage 2). 6804 The set of next hops to use for the destination may be 6805 recalculated several times during the shortest-path tree 6806 calculation, as shorter and shorter paths are discovered. 6807 In the end, the destination's routing table entry will 6808 always reflect the next hops resulting from the absolute 6809 shortest path(s). 6811 Input to the next hop calculation is a) the destination and 6812 b) its parent in the current shortest path between the root 6813 (the calculating router) and the destination. The parent is 6814 always a transit vertex (i.e., always a router or a transit 6815 network). 6817 If there is at least one intervening router in the current 6818 shortest path between the destination and the root, the 6819 destination simply inherits the set of next hops from the 6820 parent. Otherwise, there are two cases. In the first case, 6821 the parent vertex is the root (the calculating router 6822 itself). This means that the destination is either a 6823 directly connected network or directly connected router. 6824 The outgoing interface in this case is simply the OSPF 6825 interface connecting to the destination network/router. If 6826 the destination is a router which connects to the 6827 calculating router via a Point-to-MultiPoint network, the 6828 destination's next hop IP address(es) can be determined by 6829 examining the destination's router-LSA: each link pointing 6830 back to the calculating router and having a Link Data field 6831 belonging to the Point-to-MultiPoint network provides an IP 6832 address of the next hop router. If the destination is a 6833 directly connected network, or a router which connects to 6834 the calculating router via a point-to-point interface, no 6835 next hop IP address is required. If the destination is a 6836 router connected to the calculating router via a virtual 6837 link, the setting of the next hop should be deferred until 6838 the calculation in Section 16.3. 6840 In the second case, the parent vertex is a network that 6841 directly connects the calculating router to the destination 6842 router. The list of next hops is then determined by 6843 examining the destination's router-LSA. For each link in 6844 the router-LSA that points back to the parent network, the 6845 link's Link Data field provides the IP address of a next hop 6846 router. The outgoing interface to use can then be derived 6847 from the next hop IP address (or it can be inherited from 6848 the parent network). 6850 16.2. Calculating the inter-area routes 6852 The inter-area routes are calculated by examining summary-LSAs. 6853 If the router has active attachments to multiple areas, only 6854 backbone summary-LSAs are examined. Routers attached to a 6855 single area examine that area's summary-LSAs. In either case, 6856 the summary-LSAs examined below are all part of a single area's 6857 link state database (call it Area A). 6859 Summary-LSAs are originated by the area border routers. Each 6860 summary-LSA in Area A is considered in turn. Remember that the 6861 destination described by a summary-LSA is either a network (Type 6862 3 summary-LSAs) or an AS boundary router (Type 4 summary-LSAs). 6863 For each summary-LSA: 6865 (1) If the cost specified by the LSA is LSInfinity, or if the 6866 LSA's LS age is equal to MaxAge, then examine the the next 6867 LSA. 6869 (2) If the LSA was originated by the calculating router itself, 6870 examine the next LSA. 6872 (3) If it is a Type 3 summary-LSA, and the collection of 6873 destinations described by the summary-LSA equals one of the 6874 router's configured area address ranges (see Section 3.5), 6875 and the particular area address range is active, then the 6876 summary-LSA should be ignored. "Active" means that there 6877 are one or more reachable (by intra-area paths) networks 6878 contained in the area range. 6880 (4) Else, call the destination described by the LSA N (for Type 6881 3 summary-LSAs, N's address is obtained by masking the LSA's 6882 Link State ID with the network/subnet mask contained in the 6883 body of the LSA), and the area border originating the LSA 6884 BR. Look up the routing table entry for BR having Area A as 6885 its associated area. If no such entry exists for router BR 6886 (i.e., BR is unreachable in Area A), do nothing with this 6887 LSA and consider the next in the list. Else, this LSA 6888 describes an inter-area path to destination N, whose cost is 6889 the distance to BR plus the cost specified in the LSA. Call 6890 the cost of this inter-area path IAC. 6892 (5) Next, look up the routing table entry for the destination N. 6893 (If N is an AS boundary router, look up the "router" routing 6894 table entry associated with Area A). If no entry exists for 6895 N or if the entry's path type is "type 1 external" or "type 6896 2 external", then install the inter-area path to N, with 6897 associated area Area A, cost IAC, next hop equal to the list 6898 of next hops to router BR, and Advertising router equal to 6899 BR. 6901 (6) Else, if the paths present in the table are intra-area 6902 paths, do nothing with the LSA (intra-area paths are always 6903 preferred). 6905 (7) Else, the paths present in the routing table are also 6906 inter-area paths. Install the new path through BR if it is 6907 cheaper, overriding the paths in the routing table. 6908 Otherwise, if the new path is the same cost, add it to the 6909 list of paths that appear in the routing table entry. 6911 16.3. Examining transit areas' summary-LSAs 6913 This step is only performed by area border routers attached to 6914 one or more non-backbone areas that are capable of carrying 6915 transit traffic (i.e., "transit areas", or those areas whose 6916 TransitCapability parameter has been set to TRUE in Step 2 of 6917 the Dijkstra algorithm (see Section 16.1). 6919 The purpose of the calculation below is to examine the transit 6920 areas to see whether they provide any better (shorter) paths 6921 than the paths previously calculated in Sections 16.1 and 16.2. 6922 Any paths found that are better than or equal to previously 6923 discovered paths are installed in the routing table. 6925 The calculation proceeds as follows. All the transit areas' 6926 summary-LSAs are examined in turn. Each such summary-LSA 6927 describes a route through a transit area Area A to a Network N 6928 (N's address is obtained by masking the LSA's Link State ID with 6929 the network/subnet mask contained in the body of the LSA) or in 6930 the case of a Type 4 summary-LSA, to an AS boundary router N. 6931 Suppose also that the summary-LSA was originated by an area 6932 border router BR. 6934 (1) If the cost advertised by the summary-LSA is LSInfinity, or 6935 if the LSA's LS age is equal to MaxAge, then examine the 6936 next LSA. 6938 (2) If the summary-LSA was originated by the calculating router 6939 itself, examine the next LSA. 6941 (3) Look up the routing table entry for N. (If N is an AS 6942 boundary router, look up the "router" routing table entry 6943 associated with the backbone area). If it does not exist, or 6944 if the route type is other than intra-area or inter-area, or 6945 if the area associated with the routing table entry is not 6946 the backbone area, then examine the next LSA. In other 6947 words, this calculation only updates backbone intra-area 6948 routes found in Section 16.1 and inter-area routes found in 6949 Section 16.2. 6951 (4) Look up the routing table entry for the advertising router 6952 BR associated with the Area A. If it is unreachable, examine 6953 the next LSA. Otherwise, the cost to destination N is the 6954 sum of the cost in BR's Area A routing table entry and the 6955 cost advertised in the LSA. Call this cost IAC. 6957 (5) If this cost is less than the cost occurring in N's routing 6958 table entry, overwrite N's list of next hops with those used 6959 for BR, and set N's routing table cost to IAC. Else, if IAC 6960 is the same as N's current cost, add BR's list of next hops 6961 to N's list of next hops. In any case, the area associated 6962 with N's routing table entry must remain the backbone area, 6963 and the path type (either intra-area or inter-area) must 6964 also remain the same. 6966 It is important to note that the above calculation never makes 6967 unreachable destinations reachable, but instead just potentially 6969 ........................ 6970 . Area 1 (transit) . + 6971 . . | 6972 . +---+1 1+---+100 | 6973 . |RT2|----------|RT4|=========| 6974 . 1/+---+********* +---+ | 6975 . /******* . | 6976 . 1/*Virtual . | 6977 1+---+/* Link . Net|work 6978 =======|RT1|* . | N1 6979 +---+\ . | 6980 . \ . | 6981 . \ . | 6982 . 1\+---+1 1+---+20 | 6983 . |RT3|----------|RT5|=========| 6984 . +---+ +---+ | 6985 . . | 6986 ........................ + 6988 Figure 17: Routing through transit areas 6989 finds better paths to already reachable destinations. The 6990 calculation installs any better cost found into the routing 6991 table entry, from which it may be readvertised in summary-LSAs 6992 to other areas. 6994 As an example of the calculation, consider the Autonomous System 6995 pictured in Figure 17. There is a single non-backbone area 6996 (Area 1) that physically divides the backbone into two separate 6997 pieces. To maintain connectivity of the backbone, a virtual link 6998 has been configured between routers RT1 and RT4. On the right 6999 side of the figure, Network N1 belongs to the backbone. The 7000 dotted lines indicate that there is a much shorter intra-area 7001 backbone path between router RT5 and Network N1 (cost 20) than 7002 there is between Router RT4 and Network N1 (cost 100). Both 7003 Router RT4 and Router RT5 will inject summary-LSAs for Network 7004 N1 into Area 1. 7006 After the shortest-path tree has been calculated for the 7007 backbone in Section 16.1, Router RT1 (left end of the virtual 7008 link) will have calculated a path through Router RT4 for all 7009 data traffic destined for Network N1. However, since Router RT5 7010 is so much closer to Network N1, all routers internal to Area 1 7011 (e.g., Routers RT2 and RT3) will forward their Network N1 7012 traffic towards Router RT5, instead of RT4. And indeed, after 7013 examining Area 1's summary-LSAs by the above calculation, Router 7014 RT1 will also forward Network N1 traffic towards RT5. Note that 7015 in this example the virtual link enables transit data traffic to 7016 be forwarded through Area 1, but the actual path the transit 7017 data traffic takes does not follow the virtual link. In other 7018 words, virtual links allow transit traffic to be forwarded 7019 through an area, but do not dictate the precise path that the 7020 traffic will take. 7022 16.4. Calculating AS external routes 7024 AS external routes are calculated by examining AS-external-LSAs. 7025 Each of the AS-external-LSAs is considered in turn. Most AS- 7026 external-LSAs describe routes to specific IP destinations. An 7027 AS-external-LSA can also describe a default route for the 7028 Autonomous System (Destination ID = DefaultDestination, 7029 network/subnet mask = 0x00000000). For each AS-external-LSA: 7031 (1) If the cost specified by the LSA is LSInfinity, or if the 7032 LSA's LS age is equal to MaxAge, then examine the next LSA. 7034 (2) If the LSA was originated by the calculating router itself, 7035 examine the next LSA. 7037 (3) Call the destination described by the LSA N. N's address is 7038 obtained by masking the LSA's Link State ID with the 7039 network/subnet mask contained in the body of the LSA. Look 7040 up the routing table entries (potentially one per attached 7041 area) for the AS boundary router (ASBR) that originated the 7042 LSA. If no entries exist for router ASBR (i.e., ASBR is 7043 unreachable), do nothing with this LSA and consider the next 7044 in the list. 7046 Else, this LSA describes an AS external path to destination 7047 N. Examine the forwarding address specified in the AS- 7048 external-LSA. This indicates the IP address to which 7049 packets for the destination should be forwarded. 7051 If the forwarding address is set to 0.0.0.0, packets should 7052 be sent to the ASBR itself. Among the multiple routing table 7053 entries for the ASBR, select the preferred entry as follows. 7054 If RFC1583Compatibility is set to "disabled", prune the set 7055 of routing table entries for the ASBR as described in 7056 Section 16.4.1. In any case, among the remaining routing 7057 table entries, select the routing table entry with the least 7058 cost; when there are multiple least cost routing table 7059 entries the entry whose associated area has the largest OSPF 7060 Area ID (when considered as an unsigned 32-bit integer) is 7061 chosen. 7063 If the forwarding address is non-zero, look up the 7064 forwarding address in the routing table.[26] The matching 7065 routing table entry must specify an intra-area or inter-area 7066 path; if no such path exists, do nothing with the LSA and 7067 consider the next in the list. 7069 (4) Let X be the cost specified by the preferred routing table 7070 entry for the ASBR/forwarding address, and Y the cost 7071 specified in the LSA. X is in terms of the link state 7072 metric, and Y is a type 1 or 2 external metric. 7074 (5) Look up the routing table entry for the destination N. If 7075 no entry exists for N, install the AS external path to N, 7076 with next hop equal to the list of next hops to the 7077 forwarding address, and advertising router equal to ASBR. 7078 If the external metric type is 1, then the path-type is set 7079 to type 1 external and the cost is equal to X+Y. If the 7080 external metric type is 2, the path-type is set to type 2 7081 external, the link state component of the route's cost is X, 7082 and the type 2 cost is Y. 7084 (6) Compare the AS external path described by the LSA with the 7085 existing paths in N's routing table entry, as follows. If 7086 the new path is preferred, it replaces the present paths in 7087 N's routing table entry. If the new path is of equal 7088 preference, it is added to N's routing table entry's list of 7089 paths. 7091 (a) Intra-area and inter-area paths are always preferred 7092 over AS external paths. 7094 (b) Type 1 external paths are always preferred over type 2 7095 external paths. When all paths are type 2 external 7096 paths, the paths with the smallest advertised type 2 7097 metric are always preferred. 7099 (c) If the new AS external path is still indistinguishable 7100 from the current paths in the N's routing table entry, 7101 and RFC1583Compatibility is set to "disabled", select 7102 the preferred paths based on the intra-AS paths to the 7103 ASBR/forwarding addresses, as specified in Section 7104 16.4.1. 7106 (d) If the new AS external path is still indistinguishable 7107 from the current paths in the N's routing table entry, 7108 select the preferred path based on a least cost 7109 comparison. Type 1 external paths are compared by 7110 looking at the sum of the distance to the forwarding 7111 address and the advertised type 1 metric (X+Y). Type 2 7112 external paths advertising equal type 2 metrics are 7113 compared by looking at the distance to the forwarding 7114 addresses. 7116 16.4.1. External path preferences 7118 When multiple intra-AS paths are available to 7119 ASBRs/forwarding addresses, the following rules indicate 7120 which paths are preferred. These rules apply when the same 7121 ASBR is reachable through multiple areas, or when trying to 7122 decide which of several AS-external-LSAs should be 7123 preferred. In the former case the paths all terminate at the 7124 same ASBR, while in the latter the paths terminate at 7125 separate ASBRs/forwarding addresses. In either case, each 7126 path is represented by a separate routing table entry as 7127 defined in Section 11. 7129 This section only applies when RFC1583Compatibility is set 7130 to "disabled". 7132 The path preference rules, stated from highest to lowest 7133 preference, are as follows. Note that as a result of these 7134 rules, there may still be multiple paths of the highest 7135 preference. In this case, the path to use must be determined 7136 based on cost, as described in Section 16.4. 7138 o Intra-area paths using non-backbone areas are always the 7139 most preferred. 7141 o Otherwise, intra-area backbone paths are preferred. 7143 o Inter-area paths are the least preferred. 7145 16.5. Incremental updates -- summary-LSAs 7147 When a new summary-LSA is received, it is not necessary to 7148 recalculate the entire routing table. Call the destination 7149 described by the summary-LSA N (N's address is obtained by 7150 masking the LSA's Link State ID with the network/subnet mask 7151 contained in the body of the LSA), and let Area A be the area to 7152 which the LSA belongs. There are then two separate cases: 7154 Case 1: Area A is the backbone and/or the router is not an area 7155 border router. 7156 In this case, the following calculations must be performed. 7157 First, if there is presently an inter-area route to the 7158 destination N, N's routing table entry is invalidated, 7159 saving the entry's values for later comparisons. Then the 7160 calculation in Section 16.2 is run again for the single 7161 destination N. In this calculation, all of Area A's 7162 summary-LSAs that describe a route to N are examined. In 7163 addition, if the router is an area border router attached to 7164 one or more transit areas, the calculation in Section 16.3 7165 must be run again for the single destination. If the 7166 results of these calculations have changed the cost/path to 7167 an AS boundary router (as would be the case for a Type 4 7168 summary-LSA) or to any forwarding addresses, all AS- 7169 external-LSAs will have to be reexamined by rerunning the 7170 calculation in Section 16.4. Otherwise, if N is now newly 7171 unreachable, the calculation in Section 16.4 must be rerun 7172 for the single destination N, in case an alternate external 7173 route to N exists. 7175 Case 2: Area A is a transit area and the router is an area 7176 border router. 7177 In this case, the following calculations must be performed. 7178 First, if N's routing table entry presently contains one or 7179 more inter-area paths that utilize the transit area Area A, 7180 these paths should be removed. If this removes all paths 7181 from the routing table entry, the entry should be 7182 invalidated. The entry's old values should be saved for 7183 later comparisons. Next the calculation in Section 16.3 must 7184 be run again for the single destination N. If the results of 7185 this calculation have caused the cost to N to increase, the 7186 complete routing table calculation must be rerun starting 7187 with the Dijkstra algorithm specified in Section 16.1. 7188 Otherwise, if the cost/path to an AS boundary router (as 7189 would be the case for a Type 4 summary-LSA) or to any 7190 forwarding addresses has changed, all AS-external-LSAs will 7191 have to be reexamined by rerunning the calculation in 7192 Section 16.4. Otherwise, if N is now newly unreachable, the 7193 calculation in Section 16.4 must be rerun for the single 7194 destination N, in case an alternate external route to N 7195 exists. 7197 16.6. Incremental updates -- AS-external-LSAs 7199 When a new AS-external-LSA is received, it is not necessary to 7200 recalculate the entire routing table. Call the destination 7201 described by the AS-external-LSA N. N's address is obtained by 7202 masking the LSA's Link State ID with the network/subnet mask 7203 contained in the body of the LSA. If there is already an intra- 7204 area or inter-area route to the destination, no recalculation is 7205 necessary (internal routes take precedence). 7207 Otherwise, the procedure in Section 16.4 will have to be 7208 performed, but only for those AS-external-LSAs whose destination 7209 is N. Before this procedure is performed, the present routing 7210 table entry for N should be invalidated. 7212 16.7. Events generated as a result of routing table changes 7214 Changes to routing table entries sometimes cause the OSPF area 7215 border routers to take additional actions. These routers need 7216 to act on the following routing table changes: 7218 o The cost or path type of a routing table entry has changed. 7219 If the destination described by this entry is a Network or 7220 AS boundary router, and this is not simply a change of AS 7221 external routes, new summary-LSAs may have to be generated 7222 (potentially one for each attached area, including the 7223 backbone). See Section 12.4.3 for more information. If a 7224 previously advertised entry has been deleted, or is no 7225 longer advertisable to a particular area, the LSA must be 7226 flushed from the routing domain by setting its LS age to 7227 MaxAge and reflooding (see Section 14.1). 7229 o A routing table entry associated with a configured virtual 7230 link has changed. The destination of such a routing table 7231 entry is an area border router. The change indicates a 7232 modification to the virtual link's cost or viability. 7234 If the entry indicates that the area border router is newly 7235 reachable (via TOS 0), the corresponding virtual link is now 7236 operational. An InterfaceUp event should be generated for 7237 the virtual link, which will cause a virtual adjacency to 7238 begin to form (see Section 10.3). At this time the virtual 7239 link's IP interface address and the virtual neighbor's 7240 Neighbor IP address are also calculated. 7242 If the entry indicates that the area border router is no 7243 longer reachable (via TOS 0), the virtual link and its 7244 associated adjacency should be destroyed. This means an 7245 InterfaceDown event should be generated for the associated 7246 virtual link. 7248 If the cost of the entry has changed, and there is a fully 7249 established virtual adjacency, a new router-LSA for the 7250 backbone must be originated. This in turn may cause further 7251 routing table changes. 7253 16.8. Equal-cost multipath 7255 The OSPF protocol maintains multiple equal-cost routes to all 7256 destinations. This can be seen in the steps used above to 7257 calculate the routing table, and in the definition of the 7258 routing table structure. 7260 Each one of the multiple routes will be of the same type 7261 (intra-area, inter-area, type 1 external or type 2 external), 7262 cost, and will have the same associated area. However, each 7263 route specifies a separate next hop and Advertising router. 7265 There is no requirement that a router running OSPF keep track of 7266 all possible equal-cost routes to a destination. An 7267 implementation may choose to keep only a fixed number of routes 7268 to any given destination. This does not affect any of the 7269 algorithms presented in this specification. 7271 16.9. Building the non-zero-TOS portion of the routing table 7273 The OSPF protocol can calculate a different set of routes for 7274 each IP TOS (see Section 2.5). Support for TOS-based routing is 7275 optional. TOS-capable and non-TOS-capable routers can be mixed 7276 in an OSPF routing domain. Routers not supporting TOS calculate 7277 only the TOS 0 route to each destination. These routes are then 7278 used to forward all data traffic, regardless of the TOS 7279 indications in the data packet's IP header. A router that does 7280 not support TOS indicates this fact to the other OSPF routers by 7281 clearing the T-bit in the Options field of its router-LSA. 7283 The above sections detailing the routing table calculations 7284 handle the TOS 0 case only. In general, for routers supporting 7285 TOS-based routing, each piece of the routing table calculation 7286 must be rerun separately for the non-zero TOS values. When 7287 calculating routes for TOS X, only TOS X metrics can be used. 7288 Any LSA may specify a separate cost for each TOS (a cost for TOS 7289 0 must always be specified). The encoding of TOS in OSPF LSAs 7290 is described in Section 12.3. 7292 An LSA can specify that it is restricted to TOS 0 (i.e., non- 7293 zero TOS is not handled) by clearing the T-bit in the LSA's 7294 Option field. Such LSAs are not used when calculating routes 7295 for non-zero TOS. For this reason, it is possible that a 7296 destination is unreachable for some non-zero TOS. In this case, 7297 the TOS 0 path is used when forwarding packets (see Section 7298 11.1). 7300 The following lists the modifications needed when running the 7301 routing table calculation for a non-zero TOS value (called TOS 7302 X). In general, routers and LSAs that do not support TOS are 7303 omitted from the calculation. 7305 Calculating the shortest-path tree (Section 16.1). 7306 Routers that do not support TOS-based routing should be 7307 omitted from the shortest-path tree calculation. These 7308 routers are identified as those having the T-bit reset in 7309 the Options field of their router-LSAs. Such routers should 7310 never be added to the Dijkstra algorithm's candidate list, 7311 nor should their router-LSAs be examined when adding the 7312 stub networks to the tree. In particular, if the T-bit is 7313 reset in the calculating router's own router-LSA, it does 7314 not run the shortest-path tree calculation for non-zero TOS 7315 values. 7317 Calculating the inter-area routes (Section 16.2). 7318 Inter-area paths are the concatenation of a path to an area 7319 border router with a summary link. When calculating TOS X 7320 routes, both path components must also specify TOS X. In 7321 other words, only TOS X paths to the area border router are 7322 examined, and the area border router must be advertising a 7323 TOS X route to the destination. Note that this means that 7324 summary-LSAs having the T-bit reset in their Options field 7325 are not considered. 7327 Examining transit areas' summary-LSAs (Section 16.3). 7328 This calculation again considers the concatenation of a path 7329 to an area border router with a summary link. As with 7330 inter-area routes, only TOS X paths to the area border 7331 router are examined, and the area border router must be 7332 advertising a TOS X route to the destination. 7334 Calculating AS external routes (Section 16.4). 7335 This calculation considers the concatenation of a path to a 7336 forwarding address with an AS external link. Only TOS X 7337 paths to the forwarding address are examined, and the AS 7338 boundary router must be advertising a TOS X route to the 7339 destination. Note that this means that AS-external-LSAs 7340 having the T-bit reset in their Options field are not 7341 considered. 7343 In addition, the advertising AS boundary router must also be 7344 reachable for its LSAs to be considered (see Section 16.4). 7345 However, if the advertising router and the forwarding 7346 address are not one in the same, the advertising router need 7347 only be reachable via TOS 0. 7349 Footnotes 7351 [1]The graph's vertices represent either routers, transit networks, 7352 or stub networks. Since routers may belong to multiple areas, it is 7353 not possible to color the graph's vertices. 7355 [2]It is possible for all of a router's interfaces to be unnumbered 7356 point-to-point links. In this case, an IP address must be assigned 7357 to the router. This address will then be advertised in the router's 7358 router-LSA as a host route. 7360 [3]Note that in these cases both interfaces, the non-virtual and the 7361 virtual, would have the same IP address. 7363 [4]Note that no host route is generated for, and no IP packets can 7364 be addressed to, interfaces to unnumbered point-to-point networks. 7365 This is regardless of such an interface's state. 7367 [5]It is instructive to see what happens when the Designated Router 7368 for the network crashes. Call the Designated Router for the network 7369 RT1, and the Backup Designated Router RT2. If Router RT1 crashes 7370 (or maybe its interface to the network dies), the other routers on 7371 the network will detect RT1's absence within RouterDeadInterval 7372 seconds. All routers may not detect this at precisely the same 7373 time; the routers that detect RT1's absence before RT2 does will, 7374 for a time, select RT2 to be both Designated Router and Backup 7375 Designated Router. When RT2 detects that RT1 is gone it will move 7376 itself to Designated Router. At this time, the remaining router 7377 having highest Router Priority will be selected as Backup Designated 7378 Router. 7380 [6]On point-to-point networks, the lower level protocols indicate 7381 whether the neighbor is up and running. Likewise, existence of the 7382 neighbor on virtual links is indicated by the routing table 7383 calculation. However, in both these cases, the Hello Protocol is 7384 still used. This ensures that communication between the neighbors 7385 is bidirectional, and that each of the neighbors has a functioning 7386 routing protocol layer. 7388 [7]When the identity of the Designated Router is changing, it may be 7389 quite common for a neighbor in this state to send the router a 7390 Database Description packet; this means that there is some momentary 7391 disagreement on the Designated Router's identity. 7393 [8]Note that it is possible for a router to resynchronize any of its 7394 fully established adjacencies by setting the adjacency's state back 7395 to ExStart. This will cause the other end of the adjacency to 7396 process a SeqNumberMismatch event, and therefore to also go back to 7397 ExStart state. 7399 [9]The address space of IP networks and the address space of OSPF 7400 Router IDs may overlap. That is, a network may have an IP address 7401 which is identical (when considered as a 32-bit number) to some 7402 router's Router ID. 7404 [10]"Discard" entries are necessary to ensure that route 7405 summarization at area boundaries will not cause packet looping. 7407 [11]It is assumed that, for two different address ranges matching 7408 the destination, one range is more specific than the other. Non- 7409 contiguous subnet masks can be configured to violate this 7410 assumption. Such subnet mask configurations cannot be handled by the 7411 OSPF protocol. 7413 [12]MaxAgeDiff is an architectural constant. It indicates the 7414 maximum dispersion of ages, in seconds, that can occur for a single 7415 LSA instance as it is flooded throughout the routing domain. If two 7416 LSAs differ by more than this, they are assumed to be different 7417 instances of the same LSA. This can occur when a router restarts 7418 and loses track of the LSA's previous LS sequence number. See 7419 Section 13.4 for more details. 7421 [13]When two LSAs have different LS checksums, they are assumed to 7422 be separate instances. This can occur when a router restarts, and 7423 loses track of the LSA's previous LS sequence number. In the case 7424 where the two LSAs have the same LS sequence number, it is not 7425 possible to determine which LSA is actually newer. However, if the 7426 wrong LSA is accepted as newer, the originating router will simply 7427 originate another instance. See Section 13.4 for further details. 7429 [14]There is one instance where a lookup must be done based on 7430 partial information. This is during the routing table calculation, 7431 when a network-LSA must be found based solely on its Link State ID. 7432 The lookup in this case is still well defined, since no two 7433 network-LSAs can have the same Link State ID. 7435 [15]This is the way RFC 1583 specified point-to-point 7436 representation. It has three advantages: a) it does not require 7437 allocating a subnet to the point-to-point link, b) it tends to bias 7438 the routing so that packets destined for the point-to-point 7439 interface will actually be received over the interface (which is 7440 useful for diagnostic purposes) and c) it allows network 7441 bootstrapping of a neighbor, without requiring that the bootstrap 7442 program contain an OSPF implementation. 7444 [16]This is the more traditional point-to-point representation used 7445 by protocols such as RIP. 7447 [17]This clause covers the case: Inter-area routes are not 7448 summarized to the backbone. This is because inter-area routes are 7449 always associated with the backbone area. 7451 [18]This clause is only invoked when a non-backbone Area A supports 7452 transit data traffic (i.e., has TransitCapability set to TRUE). For 7453 example, in the area configuration of Figure 6, Area 2 can support 7454 transit traffic due to the configured virtual link between Routers 7455 RT10 and RT11. As a result, Router RT11 need only originate a single 7456 summary-LSA into Area 2 (having the collapsed destination N9- 7457 N11,H1), since all of Router RT11's other eligible routes have next 7458 hops belonging to Area 2 itself (and as such only need be advertised 7459 by other area border routers; in this case, Routers RT10 and RT7). 7461 [19]By keeping more information in the routing table, it is possible 7462 for an implementation to recalculate the shortest path tree for only 7463 a single area. In fact, there are incremental algorithms that allow 7464 an implementation to recalculate only a portion of a single area's 7465 shortest path tree [Ref1]. However, these algorithms are beyond the 7466 scope of this specification. 7468 [20]This is how the Link state request list is emptied, which 7469 eventually causes the neighbor state to transition to Full. See 7470 Section 10.9 for more details. 7472 [21]It should be a relatively rare occurrence for an LSA's LS age to 7473 reach MaxAge in this fashion. Usually, the LSA will be replaced by 7474 a more recent instance before it ages out. 7476 [22]Only the TOS 0 routes are important here because all OSPF 7477 protocol packets are sent with TOS = 0. See Appendix A. 7479 [23]It may be the case that paths to certain destinations do not 7480 vary based on TOS. For these destinations, the routing calculation 7481 need not be repeated for each TOS value. In addition, there need 7482 only be a single routing table entry for these destinations (instead 7483 of a separate entry for each TOS value). 7485 [24]Strictly speaking, because of equal-cost multipath, the 7486 algorithm does not create a tree. We continue to use the "tree" 7487 terminology because that is what occurs most often in the existing 7488 literature. 7490 [25]Note that the presence of any link back to V is sufficient; it 7491 need not be the matching half of the link under consideration from V 7492 to W. This is enough to ensure that, before data traffic flows 7493 between a pair of neighboring routers, their link state databases 7494 will be synchronized. 7496 [26]When the forwarding address is non-zero, it should point to a 7497 router belonging to another Autonomous System. See Section 12.4.4 7498 for more details. 7500 References 7502 [Ref1] McQuillan, J., I. Richer and E. Rosen, "ARPANET Routing 7503 Algorithm Improvements", BBN Technical Report 3803, April 7504 1978. 7506 [Ref2] Digital Equipment Corporation, "Information processing 7507 systems -- Data communications -- Intermediate System to 7508 Intermediate System Intra-Domain Routing Protocol", October 7509 1987. 7511 [Ref3] McQuillan, J. et.al., "The New Routing Algorithm for the 7512 ARPANET", IEEE Transactions on Communications, May 1980. 7514 [Ref4] Perlman, R., "Fault-Tolerant Broadcast of Routing 7515 Information", Computer Networks, December 1983. 7517 [Ref5] Postel, J., "Internet Protocol", STD 5, RFC 791, 7518 USC/Information Sciences Institute, September 1981. 7520 [Ref6] McKenzie, A., "ISO Transport Protocol specification ISO DP 7521 8073", RFC 905, ISO, April 1984. 7523 [Ref7] Deering, S., "Host extensions for IP multicasting", STD 5, 7524 RFC 1112, Stanford University, May 1988. 7526 [Ref8] McCloghrie, K., and M. Rose, "Management Information Base 7527 for network management of TCP/IP-based internets: MIB-II", 7528 STD 17, RFC 1213, Hughes LAN Systems, Performance Systems 7529 International, March 1991. 7531 [Ref9] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 7532 1994. 7534 [Ref10] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless 7535 Inter-Domain Routing (CIDR): an Address Assignment and 7536 Aggregation Strategy", RFC1519, BARRNet, cisco, MERIT, 7537 OARnet, September 1993. 7539 [Ref11] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 7540 1700, USC/Information Sciences Institute, October 1994. 7542 [Ref12] Almquist, P., "Type of Service in the Internet Protocol 7543 Suite", RFC 1349, July 1992. 7545 [Ref13] Leiner, B., et.al., "The DARPA Internet Protocol Suite", DDN 7546 Protocol Handbook, April 1985. 7548 [Ref14] Bradley, T., and C. Brown, "Inverse Address Resolution 7549 Protocol", RFC 1293, January 1992. 7551 [Ref15] deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF 7552 Over Frame Relay Networks", RFC 1586, March 1994. 7554 [Ref16] Bellovin, S., "Security Problems in the TCP/IP Protocol 7555 Suite", ACM Computer Communications Review, Volume 19, 7556 Number 2, pp. 32-38, April 1989. 7558 [Ref17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 7559 April 1992. 7561 [Ref18] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, 7562 Inc., March 1994. 7564 [Ref19] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, 7565 RainbowBridge Communications, Stanford University, March 7566 1994. 7568 [Ref20] Ferguson, D., "The OSPF External Attributes LSA", work in 7569 progress. 7571 [Ref21] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 7572 1793, Cascade, April 1995. 7574 [Ref22] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 7575 DECWRL, Stanford University, November 1990. 7577 [Ref23] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 7578 4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco 7579 Systems, March 1995. 7581 A. OSPF data formats 7583 This appendix describes the format of OSPF protocol packets and OSPF 7584 LSAs. The OSPF protocol runs directly over the IP network layer. 7585 Before any data formats are described, the details of the OSPF 7586 encapsulation are explained. 7588 Next the OSPF Options field is described. This field describes 7589 various capabilities that may or may not be supported by pieces of 7590 the OSPF routing domain. The OSPF Options field is contained in OSPF 7591 Hello packets, Database Description packets and in OSPF LSAs. 7593 OSPF packet formats are detailed in Section A.3. A description of 7594 OSPF LSAs appears in Section A.4. 7596 A.1 Encapsulation of OSPF packets 7598 OSPF runs directly over the Internet Protocol's network layer. OSPF 7599 packets are therefore encapsulated solely by IP and local data-link 7600 headers. 7602 OSPF does not define a way to fragment its protocol packets, and 7603 depends on IP fragmentation when transmitting packets larger than 7604 the network MTU. If necessary, the length of OSPF packets can be up 7605 to 65,535 bytes (including the IP header). The OSPF packet types 7606 that are likely to be large (Database Description Packets, Link 7607 State Request, Link State Update, and Link State Acknowledgment 7608 packets) can usually be split into several separate protocol 7609 packets, without loss of functionality. This is recommended; IP 7610 fragmentation should be avoided whenever possible. Using this 7611 reasoning, an attempt should be made to limit the sizes of OSPF 7612 packets sent over virtual links to 576 bytes unless Path MTU 7613 Discovery is being performed (see [Ref22]). 7615 The other important features of OSPF's IP encapsulation are: 7617 o Use of IP multicast. Some OSPF messages are multicast, when 7618 sent over broadcast networks. Two distinct IP multicast 7619 addresses are used. Packets sent to these multicast addresses 7620 should never be forwarded; they are meant to travel a single hop 7621 only. To ensure that these packets will not travel multiple 7622 hops, their IP TTL must be set to 1. 7624 AllSPFRouters 7625 This multicast address has been assigned the value 7626 224.0.0.5. All routers running OSPF should be prepared to 7627 receive packets sent to this address. Hello packets are 7628 always sent to this destination. Also, certain OSPF 7629 protocol packets are sent to this address during the 7630 flooding procedure. 7632 AllDRouters 7633 This multicast address has been assigned the value 7634 224.0.0.6. Both the Designated Router and Backup Designated 7635 Router must be prepared to receive packets destined to this 7636 address. Certain OSPF protocol packets are sent to this 7637 address during the flooding procedure. 7639 o OSPF is IP protocol number 89. This number has been registered 7640 with the Network Information Center. IP protocol number 7641 assignments are documented in [Ref11]. 7643 o Routing protocol packets are sent with IP TOS of 0. The OSPF 7644 protocol supports TOS-based routing. Routes to any particular 7645 destination may vary based on TOS. However, all OSPF routing 7646 protocol packets are sent using the normal service TOS value of 7647 binary 0000 defined in [Ref12]. 7649 o Routing protocol packets are sent with IP precedence set to 7650 Internetwork Control. OSPF protocol packets should be given 7651 precedence over regular IP data traffic, in both sending and 7652 receiving. Setting the IP precedence field in the IP header to 7653 Internetwork Control [Ref5] may help implement this objective. 7655 A.2 The Options field 7657 The OSPF Options field is present in OSPF Hello packets, Database 7658 Description packets and all LSAs. The Options field enables OSPF 7659 routers to support (or not support) optional capabilities, and to 7660 communicate their capability level to other OSPF routers. Through 7661 this mechanism routers of differing capabilities can be mixed within 7662 an OSPF routing domain. 7664 When used in Hello packets, the Options field allows a router to 7665 reject a neighbor because of a capability mismatch. Alternatively, 7666 when capabilities are exchanged in Database Description packets a 7667 router can choose not to forward certain LSAs to a neighbor because 7668 of its reduced functionality. Lastly, listing capabilities in LSAs 7669 allows routers to forward traffic around reduced functionality 7670 routers, by excluding them from parts of the routing table 7671 calculation. 7673 Six bits of the OSPF Options field have been assigned, although only 7674 two (the T-bit and E-bit) are described completely by this memo. 7675 Each bit is described briefly below. Routers should reset (i.e. 7676 clear) unrecognized bits in the Options field when sending Hello 7677 packets or Database Description packets and when originating LSAs. 7678 Conversely, routers encountering unrecognized Option bits in 7679 received Hello Packets, Database Description packets or LSAs should 7680 ignore the capability and process the packet/LSA normally. 7682 +------------------------------------+ 7683 | * | * | DC | EA | N/P | MC | E | T | 7684 +------------------------------------+ 7686 The Options field 7688 T-bit 7689 This bit describes the router's TOS-based routing capability, as 7690 specified in Sections 9.5, 10.8, 12.1.2 and 16.9 of this memo. 7692 E-bit 7693 This bit describes the way AS-external-LSAs are flooded, as 7694 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of this memo. 7696 MC-bit 7697 This bit describes whether IP multicast datagrams are forwarded 7698 according to the specifications in [Ref18]. 7700 N/P-bit 7701 This bit describes the handling of Type-7 LSAs, as specified in 7703 [Ref19]. 7705 EA-bit 7706 This bit describes the router's willingness to receive and 7707 forward External-Attributes-LSAs, as specified in [Ref20]. 7709 DC-bit 7710 This bit describes the router's handling of demand circuits, as 7711 specified in [Ref21]. 7713 A.3 OSPF Packet Formats 7715 There are five distinct OSPF packet types. All OSPF packet types 7716 begin with a standard 24 byte header. This header is described 7717 first. Each packet type is then described in a succeeding section. 7718 In these sections each packet's division into fields is displayed, 7719 and then the field definitions are enumerated. 7721 All OSPF packet types (other than the OSPF Hello packets) deal with 7722 lists of LSAs. For example, Link State Update packets implement the 7723 flooding of LSAs throughout the OSPF routing domain. Because of 7724 this, OSPF protocol packets cannot be parsed unless the format of 7725 LSAs is also understood. The format of LSAs is described in Section 7726 A.4. 7728 The receive processing of OSPF packets is detailed in Section 8.2. 7729 The sending of OSPF packets is explained in Section 8.1. 7731 A.3.1 The OSPF packet header 7733 Every OSPF packet starts with a standard 24 byte header. This 7734 header contains all the information necessary to determine whether 7735 the packet should be accepted for further processing. This 7736 determination is described in Section 8.2 of the specification. 7738 0 1 2 3 7739 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 7740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7741 | Version # | Type | Packet length | 7742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7743 | Router ID | 7744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7745 | Area ID | 7746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7747 | Checksum | AuType | 7748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7749 | Authentication | 7750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7751 | Authentication | 7752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7754 Version # 7755 The OSPF version number. This specification documents version 2 7756 of the protocol. 7758 Type 7759 The OSPF packet types are as follows. See Sections A.3.2 through 7760 A.3.6 for details. 7762 Type Description 7763 ________________________________ 7764 1 Hello 7765 2 Database Description 7766 3 Link State Request 7767 4 Link State Update 7768 5 Link State Acknowledgment 7769 Packet length 7770 The length of the OSPF protocol packet in bytes. This length 7771 includes the standard OSPF header. 7773 Router ID 7774 The Router ID of the packet's source. 7776 Area ID 7777 A 32 bit number identifying the area that this packet belongs 7778 to. All OSPF packets are associated with a single area. Most 7779 travel a single hop only. Packets travelling over a virtual 7780 link are labelled with the backbone Area ID of 0.0.0.0. 7782 Checksum 7783 The standard IP checksum of the entire contents of the packet, 7784 starting with the OSPF packet header but excluding the 64-bit 7785 authentication field. This checksum is calculated as the 16-bit 7786 one's complement of the one's complement sum of all the 16-bit 7787 words in the packet, excepting the authentication field. If the 7788 packet's length is not an integral number of 16-bit words, the 7789 packet is padded with a byte of zero before checksumming. The 7790 checksum is considered to be part of the packet authentication 7791 procedure; for some authentication types the checksum 7792 calculation is omitted. 7794 AuType 7795 Identifies the authentication procedure to be used for the 7796 packet. Authentication is discussed in Appendix D of the 7797 specification. Consult Appendix D for a list of the currently 7798 defined authentication types. 7800 Authentication 7801 A 64-bit field for use by the authentication scheme. See 7802 Appendix D for details. 7804 A.3.2 The Hello packet 7806 Hello packets are OSPF packet type 1. These packets are sent 7807 periodically on all interfaces (including virtual links) in order to 7808 establish and maintain neighbor relationships. In addition, Hello 7809 Packets are multicast on those physical networks having a multicast 7810 or broadcast capability, enabling dynamic discovery of neighboring 7811 routers. 7813 All routers connected to a common network must agree on certain 7814 parameters (Network mask, HelloInterval and RouterDeadInterval). 7815 These parameters are included in Hello packets, so that differences 7816 can inhibit the forming of neighbor relationships. A detailed 7817 explanation of the receive processing for Hello packets is presented 7818 in Section 10.5. The sending of Hello packets is covered in Section 7819 9.5. 7821 0 1 2 3 7822 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 7823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7824 | Version # | 1 | Packet length | 7825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7826 | Router ID | 7827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7828 | Area ID | 7829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7830 | Checksum | AuType | 7831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7832 | Authentication | 7833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7834 | Authentication | 7835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7836 | Network Mask | 7837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7838 | HelloInterval | Options | Rtr Pri | 7839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7840 | RouterDeadInterval | 7841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7842 | Designated Router | 7843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7844 | Backup Designated Router | 7845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7846 | Neighbor | 7847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7848 | ... | 7850 Network mask 7851 The network mask associated with this interface. For example, 7852 if the interface is to a class B network whose third byte is 7853 used for subnetting, the network mask is 0xffffff00. 7855 Options 7856 The optional capabilities supported by the router, as documented 7857 in Section A.2. 7859 HelloInterval 7860 The number of seconds between this router's Hello packets. 7862 Rtr Pri 7863 This router's Router Priority. Used in (Backup) Designated 7864 Router election. If set to 0, the router will be ineligible to 7865 become (Backup) Designated Router. 7867 RouterDeadInterval 7868 The number of seconds before declaring a silent router down. 7870 Designated Router 7871 The identity of the Designated Router for this network, in the 7872 view of the sending router. The Designated Router is identified 7873 here by its IP interface address on the network. Set to 0.0.0.0 7874 if there is no Designated Router. 7876 Backup Designated Router 7877 The identity of the Backup Designated Router for this network, 7878 in the view of the sending router. The Backup Designated Router 7879 is identified here by its IP interface address on the network. 7880 Set to 0.0.0.0 if there is no Backup Designated Router. 7882 Neighbor 7883 The Router IDs of each router from whom valid Hello packets have 7884 been seen recently on the network. Recently means in the last 7885 RouterDeadInterval seconds. 7887 A.3.3 The Database Description packet 7889 Database Description packets are OSPF packet type 2. These packets 7890 are exchanged when an adjacency is being initialized. They describe 7891 the contents of the link-state database. Multiple packets may be 7892 used to describe the database. For this purpose a poll-response 7893 procedure is used. One of the routers is designated to be the 7894 master, the other the slave. The master sends Database Description 7895 packets (polls) which are acknowledged by Database Description 7896 packets sent by the slave (responses). The responses are linked to 7897 the polls via the packets' DD sequence numbers. 7899 0 1 2 3 7900 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 7901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7902 | Version # | 2 | Packet length | 7903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7904 | Router ID | 7905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7906 | Area ID | 7907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7908 | Checksum | AuType | 7909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7910 | Authentication | 7911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7912 | Authentication | 7913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7914 | 0 | 0 | Options |0|0|0|0|0|I|M|MS 7915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7916 | DD sequence number | 7917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7918 | | 7919 +- -+ 7920 | | 7921 +- An LSA Header -+ 7922 | | 7923 +- -+ 7924 | | 7925 +- -+ 7926 | | 7927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7928 | ... | 7930 The format of the Database Description packet is very similar to 7931 both the Link State Request and Link State Acknowledgment packets. 7932 The main part of all three is a list of items, each item describing 7933 a piece of the link-state database. The sending of Database 7934 Description Packets is documented in Section 10.8. The reception of 7935 Database Description packets is documented in Section 10.6. 7937 0 These fields are reserved. They must be 0. 7939 Options 7940 The optional capabilities supported by the router, as documented 7941 in Section A.2. 7943 I-bit 7944 The Init bit. When set to 1, this packet is the first in the 7945 sequence of Database Description Packets. 7947 M-bit 7948 The More bit. When set to 1, it indicates that more Database 7949 Description Packets are to follow. 7951 MS-bit 7952 The Master/Slave bit. When set to 1, it indicates that the 7953 router is the master during the Database Exchange process. 7954 Otherwise, the router is the slave. 7956 DD sequence number 7957 Used to sequence the collection of Database Description Packets. 7958 The initial value (indicated by the Init bit being set) should 7959 be unique. The DD sequence number then increments until the 7960 complete database description has been sent. 7962 The rest of the packet consists of a (possibly partial) list of the 7963 link-state database's pieces. Each LSA in the database is described 7964 by its LSA header. The LSA header is documented in Section A.4.1. 7965 It contains all the information required to uniquely identify both 7966 the LSA and the LSA's current instance. 7968 A.3.4 The Link State Request packet 7970 Link State Request packets are OSPF packet type 3. After exchanging 7971 Database Description packets with a neighboring router, a router may 7972 find that parts of its link-state database are out-of-date. The 7973 Link State Request packet is used to request the pieces of the 7974 neighbor's database that are more up-to-date. Multiple Link State 7975 Request packets may need to be used. 7977 A router that sends a Link State Request packet has in mind the 7978 precise instance of the database pieces it is requesting. Each 7979 instance is defined by its LS sequence number, LS checksum, and LS 7980 age, although these fields are not specified in the Link State 7981 Request Packet itself. The router may receive even more recent 7982 instances in response. 7984 The sending of Link State Request packets is documented in Section 7985 10.9. The reception of Link State Request packets is documented in 7986 Section 10.7. 7988 0 1 2 3 7989 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 7990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7991 | Version # | 3 | Packet length | 7992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7993 | Router ID | 7994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7995 | Area ID | 7996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7997 | Checksum | AuType | 7998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7999 | Authentication | 8000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8001 | Authentication | 8002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8003 | LS type | 8004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8005 | Link State ID | 8006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8007 | Advertising Router | 8008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8009 | ... | 8011 Each LSA requested is specified by its LS type, Link State ID, and 8012 Advertising Router. This uniquely identifies the LSA, but not its 8013 instance. Link State Request packets are understood to be requests 8014 for the most recent instance (whatever that might be). 8016 A.3.5 The Link State Update packet 8018 Link State Update packets are OSPF packet type 4. These packets 8019 implement the flooding of LSAs. Each Link State Update packet 8020 carries a collection of LSAs one hop further from their origin. 8021 Several LSAs may be included in a single packet. 8023 Link State Update packets are multicast on those physical networks 8024 that support multicast/broadcast. In order to make the flooding 8025 procedure reliable, flooded LSAs are acknowledged in Link State 8026 Acknowledgment packets. If retransmission of certain LSAs is 8027 necessary, the retransmitted LSAs are always carried by unicast Link 8028 State Update packets. For more information on the reliable flooding 8029 of LSAs, consult Section 13. 8031 0 1 2 3 8032 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 8033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8034 | Version # | 4 | Packet length | 8035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8036 | Router ID | 8037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8038 | Area ID | 8039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8040 | Checksum | AuType | 8041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8042 | Authentication | 8043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8044 | Authentication | 8045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8046 | # LSAs | 8047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8048 | | 8049 +- +-+ 8050 | LSAs | 8051 +- +-+ 8052 | ... | 8054 # LSAs 8055 The number of LSAs included in this update. 8057 The body of the Link State Update packet consists of a list of LSAs. 8058 Each LSA begins with a common 20 byte header, described in Section 8059 A.4.1. Detailed formats of the different types of LSAs are described 8060 in Section A.4. 8062 A.3.6 The Link State Acknowledgment packet 8064 Link State Acknowledgment Packets are OSPF packet type 5. To make 8065 the flooding of LSAs reliable, flooded LSAs are explicitly 8066 acknowledged. This acknowledgment is accomplished through the 8067 sending and receiving of Link State Acknowledgment packets. 8068 Multiple LSAs can be acknowledged in a single Link State 8069 Acknowledgment packet. 8071 Depending on the state of the sending interface and the sender of 8072 the corresponding Link State Update packet, a Link State 8073 Acknowledgment packet is sent either to the multicast address 8074 AllSPFRouters, to the multicast address AllDRouters, or as a 8075 unicast. The sending of Link State Acknowledgement packets is 8076 documented in Section 13.5. The reception of Link State 8077 Acknowledgement packets is documented in Section 13.7. 8079 The format of this packet is similar to that of the Data Description 8080 packet. The body of both packets is simply a list of LSA headers. 8082 0 1 2 3 8083 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 8084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8085 | Version # | 5 | Packet length | 8086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8087 | Router ID | 8088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8089 | Area ID | 8090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8091 | Checksum | AuType | 8092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8093 | Authentication | 8094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8095 | Authentication | 8096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8097 | | 8098 +- -+ 8099 | | 8100 +- An LSA Header -+ 8101 | | 8102 +- -+ 8103 | | 8104 +- -+ 8105 | | 8106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8107 | ... | 8109 Each acknowledged LSA is described by its LSA header. The LSA 8110 header is documented in Section A.4.1. It contains all the 8111 information required to uniquely identify both the LSA and the LSA's 8112 current instance. 8114 A.4 LSA formats 8116 This memo defines five distinct types of LSAs. Each LSA begins with 8117 a standard 20 byte LSA header. This header is explained in Section 8118 A.4.1. Succeeding sections then diagram the separate LSA types. 8120 Each LSA describes a piece of the OSPF routing domain. Every router 8121 originates a router-LSA. In addition, whenever the router is 8122 elected Designated Router, it originates a network-LSA. Other types 8123 of LSAs may also be originated (see Section 12.4). All LSAs are 8124 then flooded throughout the OSPF routing domain. The flooding 8125 algorithm is reliable, ensuring that all routers have the same 8126 collection of LSAs. (See Section 13 for more information concerning 8127 the flooding algorithm). This collection of LSAs is called the 8128 link-state database. 8130 From the link state database, each router constructs a shortest path 8131 tree with itself as root. This yields a routing table (see Section 8132 11). For the details of the routing table build process, see 8133 Section 16. 8135 A.4.1 The LSA header 8137 All LSAs begin with a common 20 byte header. This header contains 8138 enough information to uniquely identify the LSA (LS type, Link State 8139 ID, and Advertising Router). Multiple instances of the LSA may 8140 exist in the routing domain at the same time. It is then necessary 8141 to determine which instance is more recent. This is accomplished by 8142 examining the LS age, LS sequence number and LS checksum fields that 8143 are also contained in the LSA header. 8145 0 1 2 3 8146 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 8147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8148 | LS age | Options | LS type | 8149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8150 | Link State ID | 8151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8152 | Advertising Router | 8153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8154 | LS sequence number | 8155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8156 | LS checksum | length | 8157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8159 LS age 8160 The time in seconds since the LSA was originated. 8162 Options 8163 The optional capabilities supported by the described portion of 8164 the routing domain. OSPF's optional capabilities are documented 8165 in Section A.2. 8167 LS type 8168 The type of the LSA. Each LSA type has a separate advertisement 8169 format. The LSA types defined in this memo are as follows (see 8170 Section 12.1.3 for further explanation): 8172 LS Type Description 8173 ___________________________________ 8174 1 Router-LSAs 8175 2 Network-LSAs 8176 3 Summary-LSAs (IP network) 8177 4 Summary-LSAs (ASBR) 8178 5 AS-external-LSAs 8180 Link State ID 8181 This field identifies the portion of the internet environment 8182 that is being described by the LSA. The contents of this field 8183 depend on the LSA's LS type. For example, in network-LSAs the 8184 Link State ID is set to the IP interface address of the 8185 network's Designated Router (from which the network's IP address 8186 can be derived). The Link State ID is further discussed in 8187 Section 12.1.4. 8189 Advertising Router 8190 The Router ID of the router that originated the LSA. For 8191 example, in network-LSAs this field is equal to the Router ID of 8192 the network's Designated Router. 8194 LS sequence number 8195 Detects old or duplicate LSAs. Successive instances of an LSA 8196 are given successive LS sequence numbers. See Section 12.1.6 8197 for more details. 8199 LS checksum 8200 The Fletcher checksum of the complete contents of the LSA, 8201 including the LSA header but excluding the LS age field. See 8202 Section 12.1.7 for more details. 8204 length 8205 The length in bytes of the LSA. This includes the 20 byte LSA 8206 header. 8208 A.4.2 Router-LSAs 8210 Router-LSAs are the Type 1 LSAs. Each router in an area originates 8211 a router-LSA. The LSA describes the state and cost of the router's 8212 links (i.e., interfaces) to the area. All of the router's links to 8213 the area must be described in a single router-LSA. For details 8214 concerning the construction of router-LSAs, see Section 12.4.1. 8216 0 1 2 3 8217 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 8218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8219 | LS age | Options | 1 | 8220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8221 | Link State ID | 8222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8223 | Advertising Router | 8224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8225 | LS sequence number | 8226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8227 | LS checksum | length | 8228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8229 | 0 |V|E|B| 0 | # links | 8230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8231 | Link ID | 8232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8233 | Link Data | 8234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8235 | Type | # TOS | TOS 0 metric | 8236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8237 | TOS | 0 | metric | 8238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8239 | ... | 8240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8241 | TOS | 0 | metric | 8242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8243 | Link ID | 8244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8245 | Link Data | 8246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8247 | ... | 8249 In router-LSAs, the Link State ID field is set to the router's OSPF 8250 Router ID. The T-bit is set in the LSA's Option field if and only 8251 if the router is able to calculate a separate set of routes for each 8252 IP TOS. Router-LSAs are flooded throughout a single area only. 8254 bit V 8255 When set, the router is an endpoint of one or more fully 8256 adjacent virtual links having the described area as Transit area 8257 (V is for virtual link endpoint). 8259 bit E 8260 When set, the router is an AS boundary router (E is for 8261 external). 8263 bit B 8264 When set, the router is an area border router (B is for border). 8266 # links 8267 The number of router links described in this LSA. This must be 8268 the total collection of router links (i.e., interfaces) to the 8269 area. 8271 The following fields are used to describe each router link (i.e., 8272 interface). Each router link is typed (see the below Type field). 8273 The Type field indicates the kind of link being described. It may 8274 be a link to a transit network, to another router or to a stub 8275 network. The values of all the other fields describing a router 8276 link depend on the link's Type. For example, each link has an 8277 associated 32-bit Link Data field. For links to stub networks this 8278 field specifies the network's IP address mask. For other link types 8279 the Link Data field specifies the router interface's IP address. 8281 Type 8282 A quick description of the router link. One of the following. 8283 Note that host routes are classified as links to stub networks 8284 with network mask of 0xffffffff. 8286 Type Description 8287 __________________________________________________ 8288 1 Point-to-point connection to another router 8289 2 Connection to a transit network 8290 3 Connection to a stub network 8291 4 Virtual link 8293 Link ID 8294 Identifies the object that this router link connects to. Value 8295 depends on the link's Type. When connecting to an object that 8296 also originates an LSA (i.e., another router or a transit 8297 network) the Link ID is equal to the neighboring LSA's Link 8298 State ID. This provides the key for looking up the neighboring 8299 LSA in the link state database during the routing table 8300 calculation. See Section 12.2 for more details. 8302 Type Link ID 8303 ______________________________________ 8304 1 Neighboring router's Router ID 8305 2 IP address of Designated Router 8306 3 IP network/subnet number 8307 4 Neighboring router's Router ID 8309 Link Data 8310 Value again depends on the link's Type field. For connections to 8311 stub networks, Link Data specifies the network's IP address 8312 mask. For unnumbered point-to-point connections, it specifies 8313 the interface's MIB-II [Ref8] ifIndex value. For the other link 8314 types it specifies the router interface's IP address. This 8315 latter piece of information is needed during the routing table 8316 build process, when calculating the IP address of the next hop. 8317 See Section 16.1.1 for more details. 8319 # TOS 8320 The number of different TOS metrics given for this link, not 8321 counting the required metric for TOS 0. For example, if no 8322 additional TOS metrics are given, this field is set to 0. 8324 TOS 0 metric 8325 The cost of using this router link for TOS 0. 8327 For each link, separate metrics may be specified for each Type of 8328 Service (TOS). The metric for TOS 0 must always be included, and 8329 was discussed above. Metrics for non-zero TOS are described below. 8330 The encoding of TOS in OSPF LSAs is described in Section 12.3. Note 8331 that the cost for non-zero TOS values that are not specified 8332 defaults to the TOS 0 cost. Metrics must be listed in order of 8333 increasing TOS encoding. For example, the metric for TOS 16 must 8334 always follow the metric for TOS 8 when both are specified. 8336 TOS IP Type of Service that this metric refers to. The encoding of 8337 TOS in OSPF LSAs is described in Section 12.3. 8339 metric 8340 The cost of using this outbound router link, for traffic of the 8341 specified TOS. 8343 A.4.3 Network-LSAs 8345 Network-LSAs are the Type 2 LSAs. A network-LSA is originated for 8346 each broadcast and NBMA network in the area which supports two or 8347 more routers. The network-LSA is originated by the network's 8348 Designated Router. The LSA describes all routers attached to the 8349 network, including the Designated Router itself. The LSA's Link 8350 State ID field lists the IP interface address of the Designated 8351 Router. 8353 The distance from the network to all attached routers is zero, for 8354 all Types of Service. This is why the TOS and metric fields need 8355 not be specified in the network-LSA. For details concerning the 8356 construction of network-LSAs, see Section 12.4.2. 8358 0 1 2 3 8359 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 8360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8361 | LS age | Options | 2 | 8362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8363 | Link State ID | 8364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8365 | Advertising Router | 8366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8367 | LS sequence number | 8368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8369 | LS checksum | length | 8370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8371 | Network Mask | 8372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8373 | Attached Router | 8374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8375 | ... | 8377 Network Mask 8378 The IP address mask for the network. For example, a class A 8379 network would have the mask 0xff000000. 8381 Attached Router 8382 The Router IDs of each of the routers attached to the network. 8383 Actually, only those routers that are fully adjacent to the 8384 Designated Router are listed. The Designated Router includes 8385 itself in this list. The number of routers included can be 8386 deduced from the LSA header's length field. 8388 A.4.4 Summary-LSAs 8390 Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated 8391 by area border routers. Summary-LSAs describe inter-area 8392 destinations. For details concerning the construction of summary- 8393 LSAs, see Section 12.4.3. 8395 Type 3 summary-LSAs are used when the destination is an IP network. 8396 In this case the LSA's Link State ID field is an IP network number 8397 (if necessary, the Link State ID can also have one or more of the 8398 network's "host" bits set; see Appendix E for details). When the 8399 destination is an AS boundary router, a Type 4 summary-LSA is used, 8400 and the Link State ID field is the AS boundary router's OSPF Router 8401 ID. (To see why it is necessary to advertise the location of each 8402 ASBR, consult Section 16.4.) Other than the difference in the Link 8403 State ID field, the format of Type 3 and 4 summary-LSAs is 8404 identical. 8406 0 1 2 3 8407 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 8408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8409 | LS age | Options | 3 or 4 | 8410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8411 | Link State ID | 8412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8413 | Advertising Router | 8414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8415 | LS sequence number | 8416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8417 | LS checksum | length | 8418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8419 | Network Mask | 8420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8421 | TOS | metric | 8422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8423 | ... | 8425 For stub areas, Type 3 summary-LSAs can also be used to describe a 8426 (per-area) default route. Default summary routes are used in stub 8427 areas instead of flooding a complete set of external routes. When 8428 describing a default summary route, the summary-LSA's Link State ID 8429 is always set to DefaultDestination (0.0.0.0) and the Network Mask 8430 is set to 0.0.0.0. 8432 Separate costs may be advertised for each IP Type of Service. The 8433 encoding of TOS in OSPF LSAs is described in Section 12.3. Note 8434 that the cost for TOS 0 must be included, and is always listed 8435 first. If the T-bit is reset in the LSA's Option field, only a 8436 route for TOS 0 is described by the LSA. Otherwise, routes for the 8437 other TOS values are also described; if a cost for a certain TOS is 8438 not included, its cost defaults to that specified for TOS 0. 8440 Network Mask 8441 For Type 3 summary-LSAs, this indicates the destination 8442 network's IP address mask. For example, when advertising the 8443 location of a class A network the value 0xff000000 would be 8444 used. This field is not meaningful and must be zero for Type 4 8445 summary-LSAs. 8447 For each specified Type of Service, the following fields are 8448 defined. The number of TOS routes included can be calculated from 8449 the LSA header's length field. A value for TOS 0 must be specified; 8450 it is listed first. Other values must be listed in order of 8451 increasing TOS encoding. For example, the cost for TOS 16 must 8452 always follow the cost for TOS 8 when both are specified. 8454 TOS The Type of Service that the following cost concerns. The 8455 encoding of TOS in OSPF LSAs is described in Section 12.3. 8457 metric 8458 The cost of this route. Expressed in the same units as the 8459 interface costs in the router-LSAs. 8461 A.4.5 AS-external-LSAs 8463 AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by 8464 AS boundary routers, and describe destinations external to the AS. 8465 For details concerning the construction of AS-external-LSAs, see 8466 Section 12.4.3. 8468 AS-external-LSAs usually describe a particular external destination. 8469 For these LSAs the Link State ID field specifies an IP network 8470 number (if necessary, the Link State ID can also have one or more of 8471 the network's "host" bits set; see Appendix E for details). AS- 8472 external-LSAs are also used to describe a default route. Default 8473 routes are used when no specific route exists to the destination. 8474 When describing a default route, the Link State ID is always set to 8475 DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0. 8477 0 1 2 3 8478 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 8479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8480 | LS age | Options | 5 | 8481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8482 | Link State ID | 8483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8484 | Advertising Router | 8485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8486 | LS sequence number | 8487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8488 | LS checksum | length | 8489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8490 | Network Mask | 8491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8492 |E| TOS | metric | 8493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8494 | Forwarding address | 8495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8496 | External Route Tag | 8497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8498 | ... | 8500 Separate costs may be advertised for each IP Type of Service. The 8501 encoding of TOS in OSPF LSAs is described in Section 12.3. Note 8502 that the cost for TOS 0 must be included, and is always listed 8503 first. If the T-bit is reset in the LSA's Option field, only a 8504 route for TOS 0 is described by the LSA. Otherwise, routes for the 8505 other TOS values are also described; if a cost for a certain TOS is 8506 not included, its cost defaults to that specified for TOS 0. 8508 Network Mask 8509 The IP address mask for the advertised destination. For 8510 example, when advertising a class A network the mask 0xff000000 8511 would be used. 8513 For each specified Type of Service, the following fields are 8514 defined. The number of TOS routes included can be calculated from 8515 the LSA header's length field. A value for TOS 0 must be specified; 8516 it is listed first. Other values must be listed in order of 8517 increasing TOS encoding. For example, the cost for TOS 16 must 8518 always follow the cost for TOS 8 when both are specified. 8520 TOS The Type of Service that the following fields concern. The 8521 encoding of TOS in OSPF LSAs is described in Section 12.3. 8523 bit E 8524 The type of external metric. If bit E is set, the metric 8525 specified is a Type 2 external metric. This means the metric is 8526 considered larger than any link state path. If bit E is zero, 8527 the specified metric is a Type 1 external metric. This means 8528 that it is expressed in the same units as the link state metric 8529 (i.e., the same units as interface cost). 8531 metric 8532 The cost of this route. Interpretation depends on the external 8533 type indication (bit E above). 8535 Forwarding address 8536 Data traffic for the advertised destination and TOS will be 8537 forwarded to this address. If the Forwarding address is set to 8538 0.0.0.0, data traffic will be forwarded instead to the LSA's 8539 originator (i.e., the responsible AS boundary router). 8541 External Route Tag 8542 A 32-bit field attached to each external route. This is not 8543 used by the OSPF protocol itself. It may be used to communicate 8544 information between AS boundary routers; the precise nature of 8545 such information is outside the scope of this specification. 8547 B. Architectural Constants 8549 Several OSPF protocol parameters have fixed architectural values. 8550 These parameters have been referred to in the text by names such as 8551 LSRefreshTime. The same naming convention is used for the 8552 configurable protocol parameters. They are defined in Appendix C. 8554 The name of each architectural constant follows, together with its 8555 value and a short description of its function. 8557 LSRefreshTime 8558 The maximum time between distinct originations of any particular 8559 LSA. If the LS age field of one of the router's self-originated 8560 LSAs reaches the value LSRefreshTime, a new instance of the LSA 8561 is originated, even though the contents of the LSA (apart from 8562 the LSA header) will be the same. The value of LSRefreshTime is 8563 set to 30 minutes. 8565 MinLSInterval 8566 The minimum time between distinct originations of any particular 8567 LSA. The value of MinLSInterval is set to 5 seconds. 8569 MinLSArrival 8570 For any particular LSA, the minimum time that must elapse 8571 between reception of new LSA instances during flooding. LSA 8572 instances received at higher frequencies are discarded. The 8573 value of MinLSArrival is set to 1 second. 8575 MaxAge 8576 The maximum age that an LSA can attain. When an LSA's LS age 8577 field reaches MaxAge, it is reflooded in an attempt to flush the 8578 LSA from the routing domain (See Section 14). LSAs of age MaxAge 8579 are not used in the routing table calculation. The value of 8580 MaxAge is set to 1 hour. 8582 CheckAge 8583 When the age of an LSA in the link state database hits a 8584 multiple of CheckAge, the LSA's checksum is verified. An 8585 incorrect checksum at this time indicates a serious error. The 8586 value of CheckAge is set to 5 minutes. 8588 MaxAgeDiff 8589 The maximum time dispersion that can occur, as an LSA is flooded 8590 throughout the AS. Most of this time is accounted for by the 8591 LSAs sitting on router output queues (and therefore not aging) 8592 during the flooding process. The value of MaxAgeDiff is set to 8593 15 minutes. 8595 LSInfinity 8596 The metric value indicating that the destination described by an 8597 LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as 8598 an alternative to premature aging (see Section 14.1). It is 8599 defined to be the 24-bit binary value of all ones: 0xffffff. 8601 DefaultDestination 8602 The Destination ID that indicates the default route. This route 8603 is used when no other matching routing table entry can be found. 8604 The default destination can only be advertised in AS-external- 8605 LSAs and in stub areas' type 3 summary-LSAs. Its value is the 8606 IP address 0.0.0.0. Its associated Network Mask is also always 8607 0.0.0.0. 8609 InitialSequenceNumber 8610 The value used for LS Sequence Number when originating the first 8611 instance of any LSA. Its value is the signed 32-bit integer 8612 0x80000001. 8614 MaxSequenceNumber 8615 The maximum value that LS Sequence Number can attain. Its value 8616 is the signed 32-bit integer 0x7fffffff. 8618 C. Configurable Constants 8620 The OSPF protocol has quite a few configurable parameters. These 8621 parameters are listed below. They are grouped into general 8622 functional categories (area parameters, interface parameters, etc.). 8623 Sample values are given for some of the parameters. 8625 Some parameter settings need to be consistent among groups of 8626 routers. For example, all routers in an area must agree on that 8627 area's parameters, and all routers attached to a network must agree 8628 on that network's IP network number and mask. 8630 Some parameters may be determined by router algorithms outside of 8631 this specification (e.g., the address of a host connected to the 8632 router via a SLIP line). From OSPF's point of view, these items are 8633 still configurable. 8635 C.1 Global parameters 8637 In general, a separate copy of the OSPF protocol is run for each 8638 area. Because of this, most configuration parameters are 8639 defined on a per-area basis. The few global configuration 8640 parameters are listed below. 8642 Router ID 8643 This is a 32-bit number that uniquely identifies the router 8644 in the Autonomous System. One algorithm for Router ID 8645 assignment is to choose the largest or smallest IP address 8646 assigned to the router. If a router's OSPF Router ID is 8647 changed, the router's OSPF software should be restarted 8648 before the new Router ID takes effect. Before restarting in 8649 order to change its Router ID, the router should flush its 8650 self-originated LSAs from the routing domain (see Section 8651 14.1), or they will persist for up to MaxAge minutes. 8653 TOS capability 8654 This item indicates whether the router will calculate 8655 separate routes based on TOS. For more information, see 8656 Sections 4.5 and 16.9. 8658 RFC1583Compatibility 8659 Controls the preference rules used in Section 16.4 when 8660 choosing among multiple AS-external-LSAs advertising the 8661 same destination. When set to "enabled", the preference 8662 rules remain those specified by RFC 1583 ([Ref9]). When set 8663 to "disabled", the preference rules are those stated in 8664 Section 16.4.1, which prevent routing loops when AS- 8665 external-LSAs for the same destination have been originated 8666 from different areas (see Section G.7). Set to "enabled" by 8667 default. 8669 In order to minimize the chance of routing loops, all OSPF 8670 routers in an OSPF routing domain should have 8671 RFC1583Compatibility set identically. When there are routers 8672 present that have not been updated with the functionality 8673 specified in Section 16.4.1 of this memo, all routers should 8674 have RFC1583Compatibility set to "enabled". Otherwise, all 8675 routers should have RFC1583Compatibility set to "disabled", 8676 preventing all routing loops. 8678 C.2 Area parameters 8680 All routers belonging to an area must agree on that area's 8681 configuration. Disagreements between two routers will lead to 8682 an inability for adjacencies to form between them, with a 8683 resulting hindrance to the flow of routing protocol and data 8684 traffic. The following items must be configured for an area: 8686 Area ID 8687 This is a 32-bit number that identifies the area. The Area 8688 ID of 0.0.0.0 is reserved for the backbone. If the area 8689 represents a subnetted network, the IP network number of the 8690 subnetted network may be used for the Area ID. 8692 List of address ranges 8693 An OSPF area is defined as a list of address ranges. Each 8694 address range consists of the following items: 8696 [IP address, mask] 8697 Describes the collection of IP addresses contained 8698 in the address range. Networks and hosts are 8699 assigned to an area depending on whether their 8700 addresses fall into one of the area's defining 8701 address ranges. Routers are viewed as belonging to 8702 multiple areas, depending on their attached 8703 networks' area membership. 8705 Status Set to either Advertise or DoNotAdvertise. Routing 8706 information is condensed at area boundaries. 8707 External to the area, at most a single route is 8708 advertised (via a summary-LSA) for each address 8709 range. The route is advertised if and only if the 8710 address range's Status is set to Advertise. 8711 Unadvertised ranges allow the existence of certain 8712 networks to be intentionally hidden from other 8713 areas. Status is set to Advertise by default. 8715 As an example, suppose an IP subnetted network is to be its 8716 own OSPF area. The area would be configured as a single 8717 address range, whose IP address is the address of the 8718 subnetted network, and whose mask is the natural class A, B, 8719 or C address mask. A single route would be advertised 8720 external to the area, describing the entire subnetted 8721 network. 8723 ExternalRoutingCapability 8724 Whether AS-external-LSAs will be flooded into/throughout the 8725 area. If AS-external-LSAs are excluded from the area, the 8726 area is called a "stub". Internal to stub areas, routing to 8727 external destinations will be based solely on a default 8728 summary route. The backbone cannot be configured as a stub 8729 area. Also, virtual links cannot be configured through stub 8730 areas. For more information, see Section 3.6. 8732 StubDefaultCost 8733 If the area has been configured as a stub area, and the 8734 router itself is an area border router, then the 8735 StubDefaultCost indicates the cost of the default summary- 8736 LSA that the router should advertise into the area. There 8737 can be a separate cost configured for each IP TOS. See 8738 Section 12.4.3 for more information. 8740 C.3 Router interface parameters 8742 Some of the configurable router interface parameters (such as IP 8743 interface address and subnet mask) actually imply properties of 8744 the attached networks, and therefore must be consistent across 8745 all the routers attached to that network. The parameters that 8746 must be configured for a router interface are: 8748 IP interface address 8749 The IP protocol address for this interface. This uniquely 8750 identifies the router over the entire internet. An IP 8751 address is not required on point-to-point networks. Such a 8752 point-to-point network is called "unnumbered". 8754 IP interface mask 8755 Also referred to as the subnet/network mask, this indicates 8756 the portion of the IP interface address that identifies the 8757 attached network. Masking the IP interface address with the 8758 IP interface mask yields the IP network number of the 8759 attached network. On point-to-point networks and virtual 8760 links, the IP interface mask is not defined. On these 8761 networks, the link itself is not assigned an IP network 8762 number, and so the addresses of each side of the link are 8763 assigned independently, if they are assigned at all. 8765 Area ID 8766 The OSPF area to which the attached network belongs. 8768 Interface output cost(s) 8769 The cost of sending a packet on the interface, expressed in 8770 the link state metric. This is advertised as the link cost 8771 for this interface in the router's router-LSA. There may be 8772 a separate cost for each IP Type of Service. The interface 8773 output cost(s) must always be greater than 0. 8775 RxmtInterval 8776 The number of seconds between LSA retransmissions, for 8777 adjacencies belonging to this interface. Also used when 8778 retransmitting Database Description and Link State Request 8779 Packets. This should be well over the expected round-trip 8780 delay between any two routers on the attached network. The 8781 setting of this value should be conservative or needless 8782 retransmissions will result. Sample value for a local area 8783 network: 5 seconds. 8785 InfTransDelay 8786 The estimated number of seconds it takes to transmit a Link 8787 State Update Packet over this interface. LSAs contained in 8788 the update packet must have their age incremented by this 8789 amount before transmission. This value should take into 8790 account the transmission and propagation delays of the 8791 interface. It must be greater than 0. Sample value for a 8792 local area network: 1 second. 8794 Router Priority 8795 An 8-bit unsigned integer. When two routers attached to a 8796 network both attempt to become Designated Router, the one 8797 with the highest Router Priority takes precedence. If there 8798 is still a tie, the router with the highest Router ID takes 8799 precedence. A router whose Router Priority is set to 0 is 8800 ineligible to become Designated Router on the attached 8801 network. Router Priority is only configured for interfaces 8802 to broadcast and NBMA networks. 8804 HelloInterval 8805 The length of time, in seconds, between the Hello Packets 8806 that the router sends on the interface. This value is 8807 advertised in the router's Hello Packets. It must be the 8808 same for all routers attached to a common network. The 8809 smaller the HelloInterval, the faster topological changes 8810 will be detected; however, more OSPF routing protocol 8811 traffic will ensue. Sample value for a X.25 PDN network: 30 8812 seconds. Sample value for a local area network: 10 seconds. 8814 RouterDeadInterval 8815 After ceasing to hear a router's Hello Packets, the number 8816 of seconds before its neighbors declare the router down. 8817 This is also advertised in the router's Hello Packets in 8818 their RouterDeadInterval field. This should be some 8819 multiple of the HelloInterval (say 4). This value again 8820 must be the same for all routers attached to a common 8821 network. 8823 AuType 8824 Identifies the authentication procedure to be used on the 8825 attached network. This value must be the same for all 8826 routers attached to the network. See Appendix D for a 8827 discussion of the defined authentication types. 8829 Authentication key 8830 This configured data allows the authentication procedure to 8831 verify OSPF protocol packets received over the interface. 8832 For example, if the AuType indicates simple password, the 8833 Authentication key would be a clear 64-bit password. 8834 Authentication keys associated with the other OSPF 8835 authentication types are discussed in Appendix D. 8837 C.4 Virtual link parameters 8839 Virtual links are used to restore/increase connectivity of the 8840 backbone. Virtual links may be configured between any pair of 8841 area border routers having interfaces to a common (non-backbone) 8842 area. The virtual link appears as an unnumbered point-to-point 8843 link in the graph for the backbone. The virtual link must be 8844 configured in both of the area border routers. 8846 A virtual link appears in router-LSAs (for the backbone) as if 8847 it were a separate router interface to the backbone. As such, 8848 it has all of the parameters associated with a router interface 8849 (see Section C.3). Although a virtual link acts like an 8850 unnumbered point-to-point link, it does have an associated IP 8851 interface address. This address is used as the IP source in 8852 OSPF protocol packets it sends along the virtual link, and is 8853 set dynamically during the routing table build process. 8854 Interface output cost is also set dynamically on virtual links 8855 to be the cost of the intra-area path between the two routers. 8856 The parameter RxmtInterval must be configured, and should be 8857 well over the expected round-trip delay between the two routers. 8858 This may be hard to estimate for a virtual link; it is better to 8859 err on the side of making it too large. Router Priority is not 8860 used on virtual links. 8862 A virtual link is defined by the following two configurable 8863 parameters: the Router ID of the virtual link's other endpoint, 8864 and the (non-backbone) area through which the virtual link runs 8865 (referred to as the virtual link's Transit area). Virtual links 8866 cannot be configured through stub areas. 8868 C.5 NBMA network parameters 8870 OSPF treats an NBMA network much like it treats a broadcast 8871 network. Since there may be many routers attached to the 8872 network, a Designated Router is selected for the network. This 8873 Designated Router then originates a network-LSA, which lists all 8874 routers attached to the NBMA network. 8876 However, due to the lack of broadcast capabilities, it may be 8877 necessary to use configuration parameters in the Designated 8878 Router selection. These parameters will only need to be 8879 configured in those routers that are themselves eligible to 8880 become Designated Router (i.e., those router's whose Router 8881 Priority for the network is non-zero), and then only if no 8882 automatic procedure for discovering neighbors exists: 8884 List of all other attached routers 8885 The list of all other routers attached to the NBMA network. 8886 Each router is listed by its IP interface address on the 8887 network. Also, for each router listed, that router's 8888 eligibility to become Designated Router must be defined. 8889 When an interface to a NBMA network comes up, the router 8890 sends Hello Packets only to those neighbors eligible to 8891 become Designated Router, until the identity of the 8892 Designated Router is discovered. 8894 PollInterval 8895 If a neighboring router has become inactive (Hello Packets 8896 have not been seen for RouterDeadInterval seconds), it may 8897 still be necessary to send Hello Packets to the dead 8898 neighbor. These Hello Packets will be sent at the reduced 8899 rate PollInterval, which should be much larger than 8900 HelloInterval. Sample value for a PDN X.25 network: 2 8901 minutes. 8903 C.6 Point-to-MultiPoint network parameters 8905 On Point-to-MultiPoint networks, it may be necessary to 8906 configure the set of neighbors that are directly reachable over 8907 the Point-to-MultiPoint network. Each neighbor is identified by 8908 its IP address on the Point-to-MultiPoint network. Designated 8909 Routers are not elected on Point-to-MultiPoint networks, so the 8910 Designated Router eligibility of configured neighbors is 8911 undefined. 8913 Alternatively, neighbors on Point-to-MultiPoint networks may be 8914 dynamically discovered by lower-level protocols such as Inverse 8915 ARP ([Ref14]). 8917 C.7 Host route parameters 8919 Host routes are advertised in router-LSAs as stub networks with 8920 mask 0xffffffff. They indicate either router interfaces to 8921 point-to-point networks, looped router interfaces, or IP hosts 8922 that are directly connected to the router (e.g., via a SLIP 8923 line). For each host directly connected to the router, the 8924 following items must be configured: 8926 Host IP address 8927 The IP address of the host. 8929 Cost of link to host 8930 The cost of sending a packet to the host, in terms of the 8931 link state metric. There may be multiple costs configured, 8932 one for each IP TOS. However, since the host probably has 8933 only a single connection to the internet, the actual 8934 configured cost(s) in many cases is unimportant (i.e., will 8935 have no effect on routing). 8937 Area ID 8938 The OSPF area to which the host belongs. 8940 D. Authentication 8942 All OSPF protocol exchanges are authenticated. The OSPF packet 8943 header (see Section A.3.1) includes an authentication type field, 8944 and 64-bits of data for use by the appropriate authentication scheme 8945 (determined by the type field). 8947 The authentication type is configurable on a per-interface (or 8948 equivalently, on a per-network/subnet) basis. Additional 8949 authentication data is also configurable on a per-interface basis. 8951 Authentication types 0, 1 and 2 are defined by this specification. 8952 All other authentication types are reserved for definition by the 8953 IANA (iana@ISI.EDU). The current list of authentication types is 8954 described below in Table 20. 8956 AuType Description 8957 ___________________________________________ 8958 0 Null authentication 8959 1 Simple password 8960 2 Cryptographic authentication 8961 All others Reserved for assignment by the 8962 IANA (iana@ISI.EDU) 8964 Table 20: OSPF authentication types. 8966 D.1 Null authentication 8968 Use of this authentication type means that routing exchanges 8969 over the network/subnet are not authenticated. The 64-bit 8970 authentication field in the OSPF header can contain anything; it 8971 is not examined on packet reception. When employing Null 8972 authentication, the entire contents of each OSPF packet (other 8973 than the 64-bit authentication field) are checksummed in order 8974 to detect data corruption. 8976 D.2 Simple password authentication 8978 Using this authentication type, a 64-bit field is configured on 8979 a per-network basis. All packets sent on a particular network 8980 must have this configured value in their OSPF header 64-bit 8981 authentication field. This essentially serves as a "clear" 64- 8982 bit password. In addition, the entire contents of each OSPF 8983 packet (other than the 64-bit authentication field) are 8984 checksummed in order to detect data corruption. 8986 Simple password authentication guards against routers 8987 inadvertently joining the routing domain; each router must first 8988 be configured with its attached networks' passwords before it 8989 can participate in routing. However, simple password 8990 authentication is vulnerable to passive attacks currently 8991 widespread in the Internet (see [Ref16]). Anyone with physical 8992 access to the network can learn the password and compromise the 8993 security of the OSPF routing domain. 8995 D.3 Cryptographic authentication 8997 Using this authentication type, a shared secret key is 8998 configured in all routers attached to a common network/subnet. 8999 For each OSPF protocol packet, the key is used to 9000 generate/verify a "message digest" that is appended to the end 9001 of the OSPF packet. The message digest is a one-way function of 9002 the OSPF protocol packet and the secret key. Since the secret 9003 key is never sent over the network in the clear, protection is 9004 provided against passive attacks. 9006 The algorithms used to generate and verify the message digest 9007 are specified implicitly by the secret key. This specification 9008 completely defines the use of OSPF Cryptographic authentication 9009 when the MD5 algorithm is used. 9011 In addition, a non-decreasing sequence number is included in 9012 each OSPF protocol packet to protect against replay attacks. 9013 This provides long term protection; however, it is still 9014 possible to replay an OSPF packet until the sequence number 9015 changes. To implement this feature, each neighbor data structure 9017 0 1 2 3 9018 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 9019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9020 | 0 | Key ID | Auth Data Len | 9021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9022 | Cryptographic sequence number | 9023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9025 Figure 18: Usage of the Authentication field 9026 in the OSPF packet header when Cryptographic 9027 Authentication is employed 9028 contains a new field called the "cryptographic sequence number". 9029 This field is initialized to zero, and is also set to zero 9030 whenever the neighbor's state transitions to "Down". Whenever an 9031 OSPF packet is accepted as authentic, the cryptographic sequence 9032 number is set to the received packet's sequence number. 9034 This specification does not provide a rollover procedure for the 9035 cryptographic sequence number. When the cryptographic sequence 9036 number that the router is sending hits the maximum value, the 9037 router should reset the cryptographic sequence number that it is 9038 sending back to 0. After this is done, the router's neighbors 9039 will reject the router's OSPF packets for a period of 9040 RouterDeadInterval, and then the router will be forced to 9041 reestablish all adjacencies over the interface. However, it is 9042 expected that many implementations will use "seconds since 9043 reboot" (or "seconds since 1960", etc.) as the cryptographic 9044 sequence number. Such a choice will essentially prevent 9045 rollover, since the cryptographic sequence number field is 32 9046 bits in length. 9048 The OSPF Cryptographic authentication option does not provide 9049 confidentiality. 9051 When cryptographic authentication is used, the 64-bit 9052 Authentication field in the standard OSPF packet header is 9053 redefined as shown in Figure 18. The new field definitions are 9054 as follows: 9056 Key ID 9057 This field identifies the algorithm and secret key used to 9058 create the message digest appended to the OSPF packet. Key 9059 Identifiers are unique per-interface (or equivalently, per- 9060 subnet). 9062 Auth Data Len 9063 The length in bytes of the message digest appended to the 9064 OSPF packet. 9066 Cryptographic sequence number 9067 An unsigned 32-bit non-decreasing sequence number. Used to 9068 guard against replay attacks. 9070 The message digest appended to the OSPF packet is not actually 9071 considered part of the OSPF protocol packet: the message digest 9072 is not included in the OSPF header's packet length, although it 9073 is included in the packet's IP header length field. 9075 Each key is identified by the combination of interface and Key 9076 ID. An interface may have multiple keys active at any one time. 9077 This enables smooth transition from one key to another. Each key 9078 has four time constants associated with it. These time constants 9079 can be expressed in terms of a time-of-day clock, or in terms of 9080 a router's local clock (e.g., number of seconds since last 9081 reboot): 9083 KeyStartAccept 9084 The time that the router will start accepting packets that 9085 have been created with the given key. 9087 KeyStartGenerate 9088 The time that the router will start using the key for packet 9089 generation. 9091 KeyStopGenerate 9092 The time that the router will stop using the key for packet 9093 generation. 9095 KeyStopAccept 9096 The time that the router will stop accepting packets that 9097 have been created with the given key. 9099 In order to achieve smooth key transition, KeyStartAccept should 9100 be less than KeyStartGenerate and KeyStopGenerate should be less 9101 than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are 9102 left unspecified, the key's lifetime is infinite. When a new key 9103 replaces an old, the KeyStartGenerate time for the new key must 9104 be less than or equal to the KeyStopGenerate time of the old 9105 key. 9107 Key storage should persist across a system restart, warm or 9108 cold, to avoid operational issues. In the event that the last 9109 key associated with an interface expires, it is unacceptable to 9110 revert to an unauthenticated condition, and not advisable to 9111 disrupt routing. Therefore, the router should send a "last 9112 authentication key expiration" notification to the network 9113 manager and treat the key as having an infinite lifetime until 9114 the lifetime is extended, the key is deleted by network 9115 management, or a new key is configured. 9117 D.4 Message generation 9119 After building the contents of an OSPF packet, the 9120 authentication procedure indicated by the sending interface's 9121 Autype value is called before the packet is sent. The 9122 authentication procedure modifies the OSPF packet as follows. 9124 D.4.1 Generating Null authentication 9126 When using Null authentication, the packet is modified as 9127 follows: 9129 (1) The Autype field in the standard OSPF header is set to 9130 0. 9132 (2) The checksum field in the standard OSPF header is set to 9133 the standard IP checksum of the entire contents of the 9134 packet, starting with the OSPF packet header but 9135 excluding the 64-bit authentication field. This 9136 checksum is calculated as the 16-bit one's complement of 9137 the one's complement sum of all the 16-bit words in the 9138 packet, excepting the authentication field. If the 9139 packet's length is not an integral number of 16-bit 9140 words, the packet is padded with a byte of zero before 9141 checksumming. 9143 D.4.2 Generating Simple password authentication 9145 When using Simple password authentication, the packet is 9146 modified as follows: 9148 (1) The Autype field in the standard OSPF header is set to 9149 1. 9151 (2) The checksum field in the standard OSPF header is set to 9152 the standard IP checksum of the entire contents of the 9153 packet, starting with the OSPF packet header but 9154 excluding the 64-bit authentication field. This 9155 checksum is calculated as the 16-bit one's complement of 9156 the one's complement sum of all the 16-bit words in the 9157 packet, excepting the authentication field. If the 9158 packet's length is not an integral number of 16-bit 9159 words, the packet is padded with a byte of zero before 9160 checksumming. 9162 (3) The 64-bit authentication field in the OSPF packet 9163 header is set to the 64-bit password (i.e., 9164 authentication key) that has been configured for the 9165 interface. 9167 D.4.3 Generating Cryptographic authentication 9169 When using Cryptographic authentication, there may be 9170 multiple keys configured for the interface. In this case, 9171 among the keys that are valid for message generation (i.e, 9172 that have KeyStartGenerate <= current time < 9173 KeyStopGenerate) choose the one with the most recent 9174 KeyStartGenerate time. Using this key, modify the packet as 9175 follows: 9177 (1) The Autype field in the standard OSPF header is set to 9178 2. 9180 (2) The checksum field in the standard OSPF header is not 9181 calculated, but is instead set to 0. 9183 (3) The Key ID (see Figure 18) is set to the chosen key's 9184 Key ID. 9186 (4) The Auth Data Len field is set to the length in bytes of 9187 the message digest that will be appended to the OSPF 9188 packet. When using MD5 as the authentication algorithm, 9189 Auth Data Len will be 16. 9191 (5) The 32-bit Cryptographic sequence number (see Figure 18) 9192 is set to a non-decreasing value (i.e., a value at least 9193 as large as the last value sent out the interface). The 9194 precise values to use in the cryptographic sequence 9195 number field are implementation-specific. For example, 9196 it may be based on a simple counter, or be based on the 9197 system's clock. 9199 (6) The message digest is then calculated and appended to 9200 the OSPF packet. The authentication algorithm to be 9201 used in calculating the digest is indicated by the key 9202 itself. Input to the authentication algorithm consists 9203 of the OSPF packet and the secret key. When using MD5 as 9204 the authentication algorithm, the message digest 9205 calculation proceeds as follows: 9207 (a) The 16 byte MD5 key is appended to the OSPF packet. 9209 (b) Trailing pad and length fields are added, as 9210 specified in [Ref17]. 9212 (c) The MD5 authentication algorithm is run over the 9213 concatenation of the OSPF packet, secret key, pad 9214 and length fields, producing a 16 byte message 9215 digest (see [Ref17]). 9217 (d) The MD5 digest is written over the OSPF key (i.e., 9218 appended to the original OSPF packet). The digest is 9219 not counted in the OSPF packet's length field, but 9220 is included in the packet's IP length field. Any 9221 trailing pad or length fields beyond the digest are 9222 not counted or transmitted. 9224 D.5 Message verification 9226 When an OSPF packet has been received on an interface, it must 9227 be authenticated. The authentication procedure is indicated by 9228 the setting of Autype in the standard OSPF packet header, which 9229 matches the setting of Autype for the receiving OSPF interface. 9231 If an OSPF protocol packet is accepted as authentic, processing 9232 of the packet continues as specified in Section 8.2. Packets 9233 which fail authentication are discarded. 9235 D.5.1 Verifying Null authentication 9237 When using Null authentication, the checksum field in the 9238 OSPF header must be verified. It must be set to the 16-bit 9239 one's complement of the one's complement sum of all the 16- 9240 bit words in the packet, excepting the authentication field. 9241 (If the packet's length is not an integral number of 16-bit 9242 words, the packet is padded with a byte of zero before 9243 checksumming.) 9245 D.5.2 Verifying Simple password authentication 9247 When using Simple password authentication, the received OSPF 9248 packet is authenticated as follows: 9250 (1) The checksum field in the OSPF header must be verified. 9251 It must be set to the 16-bit one's complement of the 9252 one's complement sum of all the 16-bit words in the 9253 packet, excepting the authentication field. (If the 9254 packet's length is not an integral number of 16-bit 9255 words, the packet is padded with a byte of zero before 9256 checksumming.) 9258 (2) The 64-bit authentication field in the OSPF packet 9259 header must be equal to the 64-bit password (i.e., 9260 authentication key) that has been configured for the 9261 interface. 9263 D.5.3 Verifying Cryptographic authentication 9265 When using Cryptographic authentication, the received OSPF 9266 packet is authenticated as follows: 9268 (1) Locate the receiving interface's configured key having 9269 Key ID equal to that specified in the received OSPF 9270 packet (see Figure 18). If the key is not found, or if 9271 the key is not valid for reception (i.e., current time < 9272 KeyStartAccept or current time >= KeyStopAccept), the 9273 OSPF packet is discarded. 9275 (2) If the cryptographic sequence number found in the OSPF 9276 header (see Figure 18) is less than the cryptographic 9277 sequence number recorded in the sending neighbor's data 9278 structure, the OSPF packet is discarded. 9280 (3) Verify the appended message digest in the following 9281 steps: 9283 (a) The received digest is set aside. 9285 (b) A new digest is calculated, as specified in Step 6 9286 of Section D.4.3. 9288 (c) The calculated and received digests are compared. If 9289 they do not match, the OSPF packet is discarded. If 9290 they do match, the OSPF protocol packet is accepted 9291 as authentic, and the "cryptographic sequence 9292 number" in the neighbor's data structure is set to 9293 the sequence number found in the packet's OSPF 9294 header. 9296 E. An algorithm for assigning Link State IDs 9298 The Link State ID in AS-external-LSAs and summary-LSAs is usually 9299 set to the described network's IP address. However, if necessary one 9300 or more of the network's host bits may be set in the Link State ID. 9301 This allows the router to originate separate LSAs for networks 9302 having the same address, yet different masks. Such networks can 9303 occur in the presence of supernetting and subnet 0s (see [Ref10]). 9305 This appendix gives one possible algorithm for setting the host bits 9306 in Link State IDs. The choice of such an algorithm is a local 9307 decision. Separate routers are free to use different algorithms, 9308 since the only LSAs affected are the ones that the router itself 9309 originates. The only requirement on the algorithms used is that the 9310 network's IP address should be used as the Link State ID whenever 9311 possible; this maximizes interoperability with OSPF implementations 9312 predating RFC 1583. 9314 The algorithm below is stated for AS-external-LSAs. This is only 9315 for clarity; the exact same algorithm can be used for summary-LSAs. 9316 Suppose that the router wishes to originate an AS-external-LSA for a 9317 network having address NA and mask NM1. The following steps are then 9318 used to determine the LSA's Link State ID: 9320 (1) Determine whether the router is already originating an AS- 9321 external-LSA with Link State ID equal to NA (in such an LSA the 9322 router itself will be listed as the LSA's Advertising Router). 9323 If not, the Link State ID is set equal to NA and the algorithm 9324 terminates. Otherwise, 9326 (2) Obtain the network mask from the body of the already existing 9327 AS-external-LSA. Call this mask NM2. There are then two cases: 9329 o NM1 is longer (i.e., more specific) than NM2. In this case, 9330 set the Link State ID in the new LSA to be the network 9331 [NA,NM1] with all the host bits set (i.e., equal to NA or'ed 9332 together with all the bits that are not set in NM1, which is 9333 network [NA,NM1]'s broadcast address). 9335 o NM2 is longer than NM1. In this case, change the existing 9336 LSA (having Link State ID of NA) to reference the new 9337 network [NA,NM1] by incrementing the sequence number, 9338 changing the mask in the body to NM1 and inserting the cost 9339 of the new network. Then originate a new LSA for the old 9340 network [NA,NM2], with Link State ID equal to NA or'ed 9341 together with the bits that are not set in NM2 (i.e., 9342 network [NA,NM2]'s broadcast address). 9344 The above algorithm assumes that all masks are contiguous; this 9345 ensures that when two networks have the same address, one mask is 9346 more specific than the other. The algorithm also assumes that no 9347 network exists having an address equal to another network's 9348 broadcast address. Given these two assumptions, the above algorithm 9349 always produces unique Link State IDs. The above algorithm can also 9350 be reworded as follows: When originating an AS-external-LSA, try to 9351 use the network number as the Link State ID. If that produces a 9352 conflict, examine the two networks in conflict. One will be a subset 9353 of the other. For the less specific network, use the network number 9354 as the Link State ID and for the more specific use the network's 9355 broadcast address instead (i.e., flip all the "host" bits to 1). If 9356 the most specific network was originated first, this will cause you 9357 to originate two LSAs at once. 9359 As an example of the algorithm, consider its operation when the 9360 following sequence of events occurs in a single router (Router A). 9362 (1) Router A wants to originate an AS-external-LSA for 9363 [10.0.0.0,255.255.255.0]: 9365 (a) A Link State ID of 10.0.0.0 is used. 9367 (2) Router A then wants to originate an AS-external-LSA for 9368 [10.0.0.0,255.255.0.0]: 9370 (a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a 9371 new Link State ID of 10.0.0.255. 9373 (b) A Link State ID of 10.0.0.0 is used for 9374 [10.0.0.0,255.255.0.0]. 9376 (3) Router A then wants to originate an AS-external-LSA for 9377 [10.0.0.0,255.0.0.0]: 9379 (a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a 9380 new Link State ID of 10.0.255.255. 9382 (b) A Link State ID of 10.0.0.0 is used for 9383 [10.0.0.0,255.0.0.0]. 9385 (c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID 9386 of 10.0.0.255. 9388 F. Multiple interfaces to the same network/subnet 9390 There are at least two ways to support multiple physical interfaces 9391 to the same IP subnet. Both methods will interoperate with 9392 implementations of RFC 1583 (and of course this memo). The two 9393 methods are sketched briefly below. An assumption has been made that 9394 each interface has been assigned a separate IP address (otherwise, 9395 support for multiple interfaces is more of a link-level or ARP issue 9396 than an OSPF issue). 9398 Method 1: 9399 Run the entire OSPF functionality over both interfaces, sending 9400 and receiving hellos, flooding, supporting separate interface 9401 and neighbor FSMs for each interface, etc. When doing this all 9402 other routers on the subnet will treat the two interfaces as 9403 separate neighbors, since neighbors are identified (on broadcast 9404 and NBMA networks) by their IP address. 9406 Method 1 has the following disadvantages: 9408 (1) You increase the total number of neighbors and adjacencies. 9410 (2) You lose the bidirectionality test on both interfaces, since 9411 bidirectionality is based on Router ID. 9413 (3) You have to consider both interfaces together during the 9414 Designated Router election, since if you declare both to be 9415 DR simultaneously you can confuse the tie-breaker (which is 9416 Router ID). 9418 Method 2: 9419 Run OSPF over only one interface (call it the primary 9420 interface), but include both the primary and secondary 9421 interfaces in your Router-LSA. 9423 Method 2 has the following disadvantages: 9425 (1) You lose the bidirectionality test on the secondary 9426 interface. 9428 (2) When the primary interface fails, you need to promote the 9429 secondary interface to primary status. 9431 G. Differences from RFC 1583 9433 This section documents the differences between this memo and RFC 9434 1583. All differences are backward-compatible. Implementations of 9435 this memo and of RFC 1583 will interoperate. 9437 G.1 Enhancements to OSPF authentication 9439 An additional OSPF authentication type has been added: the 9440 Cryptographic authentication type. This has been defined so that 9441 any arbitrary "Keyed Message Digest" algorithm can be used for 9442 packet authentication. Operation using the MD5 algorithm is 9443 completely specified (see Appendix D). 9445 A number of other changes were also made to OSPF packet 9446 authentication, affecting the following Sections: 9448 o The authentication type is now specified per-interface, 9449 rather than per-area (Sections 6, 9, C.2 and C.3). 9451 o The OSPF packet header checksum is now considered part of 9452 the authentication procedure, and so has been moved out of 9453 the packet send and receive logic (Sections 8.1 and 8.2) and 9454 into the description of authentication types (Appendix D). 9456 o In Appendix D, sections detailing message generation and 9457 message verification have been added. 9459 o For the OSPF Cryptographic authentication type, a discussion 9460 of key management, including the requirement for 9461 simultaneous support of multiple keys, key lifetimes and 9462 smooth key transition, has been added to Appendix D. 9464 G.2 Addition of Point-to-MultiPoint interface 9466 This memo adds an additional method for running OSPF over non- 9467 broadcast networks: the Point-to-Multipoint network. To 9468 implement this addition, the language of RFC 1583 has been 9469 altered slightly. References to "multi-access" networks have 9470 been deleted. The term "non-broadcast networks" is now used to 9471 describe networks which can connect many routers, but which do 9472 not natively support broadcast/multicast (such as a public Frame 9473 relay network). Over non-broadcast networks, there are two 9474 options for running OSPF: modelling them as "NBMA networks" or 9475 as "Point-to-MultiPoint networks". NBMA networks require full 9476 mesh connectivity between routers; when employing NBMA networks 9477 in the presence of partial mesh connectivity, multiple NBMA 9478 networks must be configured, as described in [Ref15]. In 9479 contrast, Point-to-Multipoint networks have been designed to 9480 work simply and naturally when faced with partial mesh 9481 connectivity. 9483 The addition of Point-to-MultiPoint networks has impacted the 9484 text in many places, which are briefly summarized below: 9486 o Section 2 describing the OSPF link-state database has been 9487 split into additional subsections, with one of the 9488 subsections (Section 2.1.1) describing the differing map 9489 representations of the two non-broadcast network options. 9490 This subsection also contrasts the NBMA network and Point- 9491 to-MultiPoint network options, and describes the situations 9492 when one is preferable to the other. 9494 o In contrast to NBMA networks, Point-to-MultiPoint networks 9495 have the following properties. Adjacencies are established 9496 between all neighboring routers (Sections 4, 7.1, 7.5, 9.5 9497 and 10.4). There is no Designated Router or Backup 9498 Designated Router for a Point-to-MultiPoint network 9499 (Sections 7.3 and 7.4). No network-LSA is originated for 9500 Point-to-MultiPoint networks (Sections 12.4.2 and A.4.3). 9501 Router Priority is not configured for Point-to-MultiPoint 9502 interfaces, nor for neighbors on Point-to-MultiPoint 9503 networks (Sections C.3 and C.6). 9505 o The Interface FSM for a Point-to-MultiPoint interface is 9506 identical to that used for point-to-point interfaces. Two 9507 states are possible: "Down" and "Point-to-Point" (Section 9508 9.3). 9510 o When originating a router-LSA, and Point-to-MultiPoint 9511 interface is reported as a collection of "point-to-point 9512 links" to all of the interface's adjacent neighbors, 9513 together with a single stub link advertising the interface's 9514 IP address with a cost of 0 (Section 12.4.1.4). 9516 o When flooding out a non-broadcast interface (when either in 9517 NBMA or Point-to-MultiPoint mode) the Link State Update or 9518 Link State Acknowledgment packet must be replicated in order 9519 to be sent to each of the interface's neighbors (see 9520 Sections 13.3 and 13.5). 9522 G.3 Support for overlapping area ranges 9524 RFC 1583 requires that all networks falling into a given area 9525 range actually belong to a single area. This memo relaxes that 9526 restriction. This is useful in the following example. Suppose 9527 that [10.0.0.0, 255.0.0.0] is carved up into subnets. Most of 9528 these subnets are assigned to a single OSPF area (call it Area 9529 X), while a few subnets are assigned to other areas. In order to 9530 get this configuration to work with RFC 1583, you must not 9531 summarize the subnets of Area X with the single range [10.0.0.0, 9532 255.0.0.0], because then the subnets of 10.0.0.0 belonging to 9533 other areas would become unreachable. However, with this memo 9534 you can summarize the subnets in Area X, provided that the 9535 subnets belonging to other areas are not summarized. 9537 Implementation details for this change can be found in Sections 9538 11.1 and 16.2. 9540 G.4 A modification to the flooding algorithm 9542 The OSPF flooding algorithm has been modified as follows. When a 9543 Link State Update Packet is received that contains an LSA 9544 instance which is actually less recent than the the router's 9545 current database copy, the router will now in most cases respond 9546 by flooding back its database copy. This is in contrast to the 9547 RFC 1583 behavior, which was to simply throw the received LSA 9548 away. 9550 Detailed description of the change can be found in Step 8 of 9551 Section 13. 9553 This change improves MaxAge processing. There are times when 9554 MaxAge LSAs stay in a router's database for extended intervals: 9555 1) when they are stuck in a retransmission queue on a slow link 9556 or 2) when a router is not properly flushing them from its 9557 database, due to software bugs. The prolonged existence of these 9558 MaxAge LSAs can inhibit the flooding of new instances of the 9559 LSA. New instances typically start with LS sequence number equal 9560 to InitialSequenceNumber, and are treated as less recent (and 9561 hence were discarded according to RFC 1583) by routers still 9562 holding MaxAge instances. However, with the above change to 9563 flooding, a router holding a MaxAge instance will flood back the 9564 MaxAge instance. When this flood reaches the LSA's originator, 9565 it will then pick the next highest LS sequence number and 9566 reflood, overwriting the MaxAge instance. 9568 G.5 Introduction of the MinLSArrival constant 9570 OSPF limits the frequency that new instances of any particular 9571 LSA can be accepted during flooding. This is extra protection, 9572 just in case a neighboring router is violating the mandated 9573 limit on LSA (re)originations (namely, one per LSA in any 9574 MinLSInterval). 9576 In RFC 1583, the frequency at which new LSA instances were 9577 accepted was also set equal to once every MinLSInterval seconds. 9578 However, in some circumstances this led to unwanted link state 9579 retransmissions, even when the LSA originator was obeying the 9580 MinLSInterval limit on originations. This was due to either 1) 9581 choice of clock granularity in some OSPF implementations or 2) 9582 differing clock speed in neighboring routers. 9584 To alleviate this problem, the frequency at which new LSA 9585 instances are accepted during flooding has now been increased to 9586 once every MinLSArrival seconds, whose value is set to 1. This 9587 change is reflected in Steps 5a and 5d of Section 13, and in 9588 Appendix B. 9590 G.6 Optionally advertising point-to-point links as subnets 9592 When describing a point-to-point interface in its router-LSA, a 9593 router may now advertise a stub link to the point-to-point 9594 network's subnet. This is specified as an alternative to the RFC 9595 1583 behavior, which is to advertise a stub link to the 9596 neighbor's IP address. See Sections 12.4.1 and 12.4.1.1 for 9597 details. 9599 G.7 Advertising same external route from multiple areas 9601 This document fixes routing loops which can occur in RFC 1583 9602 when the same external destination is advertised by AS boundary 9603 routers in separate areas. There are two manifestations of this 9604 problem. The first, discovered by Dennis Ferguson, occurs when 9605 an aggregated forwarding address is in use. In this case, the 9606 desirability of the forwarding address can change for the worse 9607 as a packet crosses an area aggregation boundary on the way to 9608 the forwarding address, which in turn can cause the preference 9609 of AS-external-LSAs to change, resulting in a routing loop. 9611 The second manifestation was discovered by Richard Woundy. It is 9612 caused by an incomplete application of OSPF's preference of 9613 intra-area routes over inter-area routes: paths to any given 9614 ASBR/forwarding address are selected first based on intra-area 9615 preference, while the comparison between separate 9616 ASBRs/forwarding addresses is driven only by cost, ignoring 9617 intra-area preference. His example is replicated in Figure 19. 9618 Both router A3 and router B3 are originating an AS-external-LSA 9619 for 10.0.0.0/8, with the same type 2 metric. Router A1 selects 9620 B1 as its next hop towards 10.0.0.0/8, based on shorter cost to 9621 ASBR B3 (via B1->B2->B3). However, the shorter route to B3 is 9622 not available to B1, due to B1's preference for the (higher 9623 cost) intra-area route to B3 through Area A. This leads B1 to 9624 select A1 as its next hop to 10.0.0.0/8, resulting in a routing 9625 loop. 9627 The following two changes have been made to prevent these 9628 routing loops: 9630 o When originating a type 3 summary-LSA for a configured area 9631 address range, the cost of the summary-LSA is now set to the 9632 maximum cost of the range's component networks (instead of 9633 the previous algorithm which set the cost to the minimum 9634 component cost). This change affects Sections 3.5 and 9635 12.4.3, Figures 7 and 8, and Tables 6 and 13. 9637 o The preference rules for choosing among multiple AS- 9638 external-LSAs have been changed. Where previously cost was 9639 the only determining factor, now the preference is driven 9640 first by type of path (intra-area or inter-area, through 9641 non-backbone area or through backbone) to the 9642 ASBR/forwarding address, using cost only to break ties. This 9643 change affects Sections 16.4 and 16.4.1. 9645 After implementing this change, the example in Figure 19 is 9646 modified as follows. Router A1 now chooses A3 as the next 9648 10.0.0.0/8 9649 ---------- 9650 | 9651 +----+ 9652 | XX | 9653 +----+ 9654 RIP / \ RIP 9655 --------------------- -------------------- 9656 ! ! 9657 ! ! 9658 +----+ +----+ 1 +----+......+----+.... 9659 | A3 |------| A1 |---------------| B1 |------| B3 | . 9660 +----+ 6 +----+ +----+ 8 +----+ . 9661 1| . / . 9662 OSPF backbone | . / . 9663 +----+ 2 / . 9664 | B2 |------- Area A. 9665 +----+................ 9667 Figure 19: Example routing loop when the 9668 same external route is advertised from multiple 9669 areas 9670 hop to 10.0.0.0/8, while B1 chooses B3 as next hop. The 9671 reason for both choices is that ASBRs/forwarding addresses 9672 are now chosen based first on intra-area preference, and 9673 then by cost. 9675 Unfortunately, this change is not backward compatible. While 9676 the change prevents routing loops when all routers run the 9677 new preference rules, it can actually create routing loops 9678 when some routers are running the new preference rules and 9679 other routers implement RFC 1583. For this reason, a new 9680 configuration parameter has been added: 9681 RFC1583Compatibility. Only when RFC1583Compatibility is set 9682 to "disabled" will the new preference rules take effect. See 9683 Appendix C for more details. 9685 Security Considerations 9687 All OSPF protocol exchanges are authenticated. OSPF supports 9688 multiple types of authentication; the type of authentication in use 9689 can be configured on a per network segment basis. One of OSPF's 9690 authentication types, namely the Cryptographic authentication 9691 option, is believed to be secure against passive attacks and provide 9692 significant protection against active attacks. When using the 9693 Cryptographic authentication option, each router appends a "message 9694 digest" to its transmitted OSPF packets. Receivers then use the 9695 shared secret key and received digest to verify that each received 9696 OSPF packet is authentic. 9698 The quality of the security provided by the Cryptographic 9699 authentication option depends completely on the strength of the 9700 message digest algorithm (MD5 is currently the only message digest 9701 algorithm specified), the strength of the key being used, and the 9702 correct implementation of the security mechanism in all 9703 communicating OSPF implementations. It also requires that all 9704 parties maintain the secrecy of the shared secret key. 9706 None of the OSPF authentication types provide confidentiality. Nor 9707 do they protect against traffic analysis. Key management is also not 9708 addressed by this memo. 9710 For more information, see Sections 8.1, 8.2, and Appendix D. 9712 Author's Address 9714 John Moy 9715 Cascade Communications Corp. 9716 5 Carlisle Road 9717 Westford, MA 01886 9719 Phone: 508-952-1367 9720 Fax: 508-692-9214 9721 Email: jmoy@casc.com 9723 This document expires in March 1997.